[LAC-TF] Fwd: RFC 7217 on A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)

[Erick Lobo Marín]

Fernando:

>Para poder hacer correlación en tales escenarios, necesitarías algo
>como: <http://www.si6networks.com/tools/ipv6mon/>, que en IPv4
>generalmente NO es necesario.

En relación con tu comentario se me ocurre que en IPv4 no eran necesarios
los mecanismos comentados (RFC4941 y RFC7217), porque en general en la
Enterprise se manejaba el NAT en combinación con políticas de Firewall, y
de alguna forma se deba el ocultamiento de la dirección final y el tracking
era más difícil de hacer.  Con IPv6, por sus características (tales como:
autoconfiguración stateless y suficiente direccionamiento) ya no aplica el
NAT (o por lo menos no tienen mucho sentido el usarlo) lo cual produce que
no se disponga el ocultamiento y el tracking, requiriendo considerar estas
opciones.

Agradecería sus observaciones a lo indicado.

Atentamente,
Costa Rica
Erick Lobo

lgD


El 13 de mayo de 2014, 12:37, Fernando Gont <fgont at si6networks.com>escribió:

> Erick,
>
> Se deshabilita porque las direcciones de prvacidad hacen que cada
> sistema tenga varias direcciones IPv6 al mismo tiempo, y cambiantes... O
> cual, en materia de correlación, es lo que en mi barrio natal (Haedo,
> Argnetina) se llama "un dolor de huevos" :-), y en el mundo en general
> "dificultoso".
>
> Para poder hacer correlación en tales escenarios, necesitarías algo
> como: <http://www.si6networks.com/tools/ipv6mon/>, que en IPv4
> generalmente NO es necesario.
>
> Saludos,
> Fernando
>
>
>
>
> On 05/12/2014 09:53 AM, Erick Lobo Marín wrote:
> > Buenos días, ¿por qué se deshabilita en la Enterprise?, será para que
> > los sistemas perimetrales (firewall, ids...) de seguridad tengan más
> > "certeza" al aplicar las políticas de seguridad sobre éstas?
> >
> > Atentamente,
> > Costa Rica
> > Erick Lobo
> >
> > lgD
> >
> >
> > El 11 de mayo de 2014, 13:19, Cristian F. Perez Monte <cdlt23 at gmail.com
> > <mailto:cdlt23 at gmail.com>> escribió:
> >
> >
> >
> >
> >     2014-05-11 1:35 GMT-03:00 Fernando Gont <fernando at gont.com.ar
> >     <mailto:fernando at gont.com.ar>>:
> >
> >         Hola, Erick,
> >
> >         On 05/09/2014 05:01 PM, Erick Lobo Marín wrote:
> >         > Fernando: ¿Qué tan aceptado es el método que ha implementado
> >         Microsoft
> >         > en sus sistemas operativos Windows de generación aleatoria de
> la
> >         > dirección IPv6 sobre el tiempo?
> >
> >         Supongo que te referis a lo especificado en RFC 4941. En tal
> >         caso, te
> >         diría que con el correr del tiempo ha sido mas y mas aceptado por
> >         distintas plataformas -- aunque no todas ellas habilitan dichas
> >         direcciones por defecto. Las que recuerdo (de memoria) que
> >         implementan
> >         RFC 4941 son:
> >
> >         * Windows
> >         * FreeBSD
> >         * OpenBSD
> >         * Linux
> >
> >
> >         Windows las habilita por defecto. FreeBSD no. Y el resto no
> >         recuerdo...
> >
> >
> >     En linux dependiendo de distribución y versión de kernel, he visto
> >     con y sin habilitación de lo especificado en el RFC 4941.
> >     En el caso de NetBSD no estaría tan seguro que no lo implementa,
> >     creería que si, sucede que por defecto viene todo desactivado.
> >
> >
> >         Mas alla de la habilitacion por defecto, es de notar que al
> menos en
> >         ambientes tipo Enterprise, este feature suele ser deshabilitado.
> >
> >
> >
> >         > Considerando entre las razones de su uso el evitar el tracking
> >         de la
> >         > dirección IP.
> >
> >         RFC 4941 no evita, per se, el tracking, sino que lo ahce mas
> >         dificil.
> >
> >         Cuando RFC4941 esta habilitado, se utilizan direcciones
> >         aleatorias para
> >         las conexiones salientes... pero las direcciones "tradicionales"
> >         (no-temporales) siguen ahí... por lo cual el tracking sigue
> siendo
> >         posible (ni hablar del escaneo, etc.).
> >
> >         Saludos, y gracias!
> >         --
> >         Fernando Gont
> >         e-mail: fernando at gont.com.ar <mailto:fernando at gont.com.ar> ||
> >         fgont at si6networks.com <mailto:fgont at si6networks.com>
> >         PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076
> FFF1
> >
> >
> >
> >         _______________________________________________
> >         LACTF mailing list
> >         LACTF at lacnic.net <mailto:LACTF at lacnic.net>
> >         https://mail.lacnic.net/mailman/listinfo/lactf
> >         Cancelar suscripcion: lactf-unsubscribe at lacnic.net
> >         <mailto:lactf-unsubscribe at lacnic.net>
> >
> >
> >
> >
> >
> >     _______________________________________________
> >     LACTF mailing list
> >     LACTF at lacnic.net <mailto:LACTF at lacnic.net>
> >     https://mail.lacnic.net/mailman/listinfo/lactf
> >     Cancelar suscripcion: lactf-unsubscribe at lacnic.net
> >     <mailto:lactf-unsubscribe at lacnic.net>
> >
> >
> >
> >
> > _______________________________________________
> > LACTF mailing list
> > LACTF at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/lactf
> > Cancelar suscripcion: lactf-unsubscribe at lacnic.net
> >
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont at si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20140514/2bd7af4b/attachment.html>