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

[Arturo Servin]

	We agree to disagree.

	En pocas palabras no creo que después de hacer una análisis de riesgo sea conveniente cambiar un estándar sin probar la alternativa (en ese caso en específico).

	Algo más de texto abajo.

On 21 May 2012, at 02:35, Fernando Gont wrote:

> 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*.

	No importa si lo usan o no, los tienes que cambiar.

> 
> 
>> 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.

	No si deprecias el estandar anterior, porque entonces fuerzas a los otros productos a hacer el update o quedarse fuera del estándar. Si lo que quieres es lo anterior, creando uno nuevo sin depreciar el anterior me parece que es el balance justo.

> 	
> * 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.

	Hay niveles de mal. IMHO no esta tan mal. Al final sigue siendo mejor 2^24 que 2^8, y además esta el argumento si el scanning realmente sirve de algo.

> 
> * 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*.

	Es lo bueno de los números, uno los maquilla dependiendo a donde quieres llegar. Te puede dar hasta minutos o años si nos esforzamos lo suficiente.

	La viabilidad puede estar, no lo dudo. Lo que discuto es querer cambiar un estandar por algo que "puede ser" viable. El costo al final del cambio es muy alto comparado con el riesgo (que creo es bajo).


> 
> 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.

	Claro, el estandar no asegura como lo vas a implementar. Ya veo al fabricante X usando una clave "default", una función mal programada, o una generación mala de números aleatorias. Con el resultado que ahora en lugar de 2^24 va a ser trivial saber la dirección.

	Otro punto a favor de esperar a ver como resulta, y entonces cambiar el estándar.

> 
> * 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*).

	Si, la solución es buena. El problema si lo hay, no va a ser el algoritmo, sino la forma de implementarlo.

	Tampoco mucho hubo mucha objeción a favor de no depreciar el estándar. 

> 
> 
> 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.


	De regreso, la viabilidad aunque posible creo que es baja comparada con el costo. 

	Si haces un análisis de riesgo e incluyes factores como la posibilidad del ataque, el resultado del ataque, costo de cambio de estándar, etc. te vas a dar cuenta que hacerlo poco a poco tiene mas sentido.

> 
> 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.

	No creo que sea Dios. Va a ser una decisión de negocio como siempre.

	En cuanto tengas las herramientas, hagas real la viabilidad y le aumentes el riesgo al problema el estándar va a caminar por si mismo, eso tenlo por seguro. Pero al día de hoy no.

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

	Y como decía Cantinflas:

"No sospecho de nadie, pero desconfío de todos".

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

Saludos,
as