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