[LAC-TF] Revisión de IETF I-D: draft-ietf-6man-stable-privacy-addresses-00.txt

[Fernando Gont]

Hola, Arturo,

Mis respuestas van entre lineas...

On 05/20/2012 11:17 AM, Arturo Servin wrote:
[....]
> Al menos el 40% de los dispositivos finales en el Internet soportan
> IPv6 (Vista, Win7, OSx, Linux, y hasta XP -que no se si entren en la
> estadistica- ).

*Soportan*, no *usan*. Justamente este detalle hace que sea
particularmente interesante hacer los cambios *ahora*.


> Me estas diciendo que quieres cambiar el stack de
> IPv6 de todos esos dispositivos (sin contar servidores, equipos de
> red, firewalls, etc.) para depreciar un estandar que es vulnerable a
> un escaneo que en el mejor de los casos tarda 11 dias y cambiarlo por
> otro estandar que aun no sabemos si va a resolver el problema (por
> ejemplo que el nivel de aleatoriedad generada por el algoritmo no
> resulte la adecuada)?

Personalmente, discrepo en varios aspectos de este parrafo :-). Voy por
partes:

* Lo que yo quiero es cambiar el *standard* -- léase, la recomendación
de lo que los stacks deben hacer. Esto no necesariamente debe afectar a
stacks existentes (lease, productos que ya se encuentren
vendidos/desplegados), sino principalmente a productos que se
fabriquen/vendan de aca en adelante.

* Windows no genera los identificadores de interfaz de acuerdo a lo
"recomendado" por la IETF (ellos implementan un algoritmo suboptimo que
mitiga los ataques de escaneo, pero que todavia permite ataques de tipo
"host tracking"). Dicho de otro modo, en lo que a Windows respecta,
ellos ya estan implementando algo no-standard, y suboptimo. Cambiar
formalmente el standard podria ser una motivación a que implementen algo
mejor, y documentado.

* Por otro lado, lo que está mal, está mal. :-) Incluso si vos me
dijeras "el 80% de los sistemas hace X cosa", mi lectura simplemente
seria "que pena que el 80% de los sistemas hagan las cosas mal" :-). Un
monton de gente o dispositivos haciendo algo mal no hacen que ese "algo"
pase a ser bueno.

* Tus numeros de "11 dias" (que no coinciden con los mios), asumen que
el atacante está realizando el escaneo desde un unico sistema. Hoy en
dia, no es para nada inusual que el atacante controle varios sistemas.
De cualquier modo, el bottom-line es que pasamos de considerar algo
inviable (500,000 años), a discutir sobre si el ataque dura 10 dias, o
unas pocas horas. Mi presentación en LACSEC, mas que intentar arrojar un
valor numérico respecto a cuanto puede tardar un ataque de escaneo,
apuntó a señalar que los mismos son *viables*.

De hecho, Microsoft hizo lo que hizo por considerar a los ataques de
escaneo en IPv6 como viables (esto fue mencionado en la ultima reunion
del 6man wg, aunque no figura en las minutas... sin embargo, los
interesados pueden chequear la grabación en audio de la reunion en:
http://www.ietf.org/audio/ietf83/ietf83-hallmaillot-20120327-0855-am.mp3 ()

* Ṕor otro lado, las propiedades del algoritmo especificado en
draft-ietf-6man-stable-privacy-addresses-00 dependen basicamente de las
propiedades de la funcion criptografica F(). Funciones tales como MD5 y
SHA han sido estudiadas, analizadas, y probadas con mas detenimiento y
detalle que casi cualquier aspecto del protocolo IPv6.

* Por ultimo, nadie hizo objeción alguna a las propiedades *técnicas* de
lo propuesto en draft-ietf-6man-stable-privacy-addresses-00 (ni siquiera
quienes de algun modo se opusieron al update formal de otros estandares,
por motivos *politicos*).


Lo que personalmente me parece curioso (aunque honestamente no me
sorprende) es que ante indicadores concretos sobre la viabilidad de
determinados ataques, y una propuesta bien concreta (simple, y
entendible) para solucionarlos, la comunidad opte por objeciones
politicas ante un problema técnico.

Dios dirá como evoluciona la cosa por parte de los fabricantes. Pero me
atrevo a decir que en materia de herramientas de escaneo tendremos
avances este año -- tanto propios, como de otros miembros de la comunidad.

En palabras de Michael Stipe, "Offer me solutions, offer me alternatives
and I decline" (http://youtu.be/_eyFiClAzq8) ;-)

Un abrazo,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492