[LACNIC/Seguridad] Fwd: Protocol Action: 'Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6' to Proposed Standard (draft-ietf-6man-rfc4941bis-12.txt)
Guillermo Pagliero
paglierog en hotmail.com
Mar Dic 22 11:57:59 -03 2020
Nico muchas gracias, eso me aclara algunas cosas, pero entonces queda sin poder saberse si fue el cliente del ISP o alguien que estuvo en ese momento dentro de la red del cliente
saludos
Ing. Guillermo Pagliero
paglierog en hotmail.com
Cel: 353-4271899
________________________________
De: Seguridad <seguridad-bounces en lacnic.net> en nombre de Nicolas Antoniello <nantoniello en gmail.com>
Enviado: martes, 22 de diciembre de 2020 11:55
Para: Lista para discusion de seguridad en redes y sistemas informaticos de la region <seguridad en lacnic.net>
Asunto: Re: [LACNIC/Seguridad] Fwd: Protocol Action: 'Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6' to Proposed Standard (draft-ietf-6man-rfc4941bis-12.txt)
Hola Guillermo,
Supongo que eso no sucede pues el ISP es quien asigna la parte “determinada” del prefijo y eso no cambiaría.
Al igual que en IPv4, el ISP aún puede saber quien es el cliente (pero, al igual que en IPv4) no puede saber de cual de todos los dispositivos del cliente se trata. Bueno, eso es lo que interpreto de la letra del estándar.
Saludos,
Nico
El El mar, dic. 22, 2020 a la(s) 11:32, Guillermo Pagliero <paglierog en hotmail.com<mailto:paglierog en hotmail.com>> escribió:
buenos días, ante todo disculpen mi ignorancia, pero no me queda claro algo con respecto a este tema, como operador ISP, la escasez de IPv4 nos obliga a hacer NAT y con ello a perder cierta información, por ejemplo, cuando nos pidén judicialmente quien tuvo en un determinado momento una dirección IP en particular, con esta nueva configuración de direcciones IPv6 no nos estaría pasando lo mismo??
saludos
________________________________
De: Seguridad <seguridad-bounces en lacnic.net<mailto:seguridad-bounces en lacnic.net>> en nombre de Fernando Gont <fgont en si6networks.com<mailto:fgont en si6networks.com>>
Enviado: lunes, 14 de diciembre de 2020 15:43
Para: Lista para discusión de seguridad en redes y sistemas informaticos de la región <seguridad en lacnic.net<mailto:seguridad en lacnic.net>>; lactf en lac.ipv6tf.org<mailto:lactf en lac.ipv6tf.org> <lactf en lac.ipv6tf.org<mailto:lactf en lac.ipv6tf.org>>
Asunto: [LACNIC/Seguridad] Fwd: Protocol Action: 'Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6' to Proposed Standard (draft-ietf-6man-rfc4941bis-12.txt)
FYI.
La IESG finalmente aprobó nuestro IETF Internet-Draft
draft-ietf-6man-rfc4941bis
(https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis) -- una revisión
de la especificación de "Direcciones IPv6 Temporales" (RFC4941).
Fueron cuatro años de trabajo en este documento....
También hice la implementación de Linux de este documento hace algunos
meses:
https://patchwork.ozlabs.org/project/netdev/patch/20200501035147.GA1587@archlinux-current.localdomain/
Y una para FreeBSD que por algun motivo todavía no se comiteó.
Slds,
Cheers,
Fernando
-------- Forwarded Message --------
Subject: Protocol Action: 'Temporary Address Extensions for Stateless
Address Autoconfiguration in IPv6' to Proposed Standard
(draft-ietf-6man-rfc4941bis-12.txt)
Resent-Date: Mon, 14 Dec 2020 07:39:13 -0800 (PST)
Resent-From: alias-bounces en ietf.org<mailto:alias-bounces en ietf.org>
Resent-To: fgont en si6networks.com<mailto:fgont en si6networks.com>, suresh en kaloom.com<mailto:suresh en kaloom.com>, narten en cs.duke.edu<mailto:narten en cs.duke.edu>,
richdr en microsoft.com<mailto:richdr en microsoft.com>
Date: Mon, 14 Dec 2020 07:39:13 -0800
From: The IESG <iesg-secretary en ietf.org<mailto:iesg-secretary en ietf.org>>
To: IETF-Announce <ietf-announce en ietf.org<mailto:ietf-announce en ietf.org>>
CC: ek.ietf en gmail.com<mailto:ek.ietf en gmail.com>, rfc-editor en rfc-editor.org<mailto:rfc-editor en rfc-editor.org>, otroan en employees.org<mailto:otroan en employees.org>,
draft-ietf-6man-rfc4941bis en ietf.org<mailto:draft-ietf-6man-rfc4941bis en ietf.org>, The IESG <iesg en ietf.org<mailto:iesg en ietf.org>>,
ipv6 en ietf.org<mailto:ipv6 en ietf.org>, 6man-chairs en ietf.org<mailto:6man-chairs en ietf.org>
The IESG has approved the following document:
- 'Temporary Address Extensions for Stateless Address Autoconfiguration
in IPv6'
(draft-ietf-6man-rfc4941bis-12.txt) as Proposed Standard
This document is the product of the IPv6 Maintenance Working Group.
The IESG contact persons are Erik Kline and Éric Vyncke.
A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/
Technical Summary
This document describes an extension that causes nodes to generate
global scope addresses with randomized interface identifiers that
change over time. Changing global scope addresses over time limits
the window of time during which eavesdroppers and other information
collectors may trivially perform address-based network activity
correlation when the same address is employed for multiple
transactions by the same node. Additionally, it reduces the window
of exposure of a node via an addresses that becomes revealed as a
result of active communication. This document obsoletes RFC4941.
Working Group Summary
This document is an update of RFC4941. The document
shepherd has reviewed every change to the document as it
has processed as well as a thorough read through of the
whole final document.
Document Quality
There are multiple implementations of the mechanism described.
Personnel
Ole Trøan is the document shepherd.
Erik Kline is the responsible AD.
_______________________________________________
Seguridad mailing list
Seguridad en lacnic.net<mailto:Seguridad en lacnic.net>
https://mail.lacnic.net/mailman/listinfo/seguridad
_______________________________________________
Seguridad mailing list
Seguridad en lacnic.net<mailto:Seguridad en lacnic.net>
https://mail.lacnic.net/mailman/listinfo/seguridad
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20201222/14baf96a/attachment.htm>
Más información sobre la lista de distribución Seguridad