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

Arturo Servin aservin at lacnic.net
Mon May 21 14:59:42 BRT 2012


	El punto es que creemos en dos formas de hacer las cosas. Podemos estar en un loop infinito tratando de convencer al otro de porque sus argumentos son correctos o no.

	Hay puntos en los cuales creo que tienes razón, otros en los que creo que no y por más que haga yo (y tu de tu lado) no nos vamos a convencer.

Saludos,
as

On 21 May 2012, at 14:44, Fernando Gont wrote:

> On 05/21/2012 09:07 AM, Arturo Servin wrote:
>> 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).
> 
> Si tomas esa postura, entonces directamente deberias deshabilitar IPv6
> en todos los clientes, ya que lo cierto es que hoy en dia IPv6 no te
> aporta nada por sobre IPv4. -- y las implementaciones de IPv6 tienen un
> nivel de madurez similar al que tenian las implementaciones de IPv4 en
> los '90.... con el agregado que es muchisimo mas complejo.
> 
> Asimismo: que es, especificamente, lo que crees que habria que probar de
> la propuesta en cuestión, y que es lo que crees que podría fallar?
> 
> 
>>> 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.
> 
> Exacto. Dado que hoy en dia no se depende de manera critica de IPv6, y
> que esto es algo por mejorar, es el momento de hacerlo. Incluso si se
> implementara mal, hoy no habria impacto alguno. O preferis hacerlo en 15
> años, cuando realmente se dependa de IPv6?
> 
> 
>>> * 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. 
> 
> Nadie tiene porque ser compliant con una estandar que se creó despues de
> la propia implementación. De hecho, en tales casos, el dispositivo ya
> fue comprado, asi que... cual es el problema?
> 
> 
>> Si
>> lo que quieres es lo anterior, creando uno nuevo sin depreciar el
>> anterior me parece que es el balance justo.
> 
> Lo que me interesa es que la recomendacion sea generar direcciones no
> previsibles. -- no necesariamente "deprecatear" las direcciones
> actuales. Dicho mas propiamente, algo tipo "IPv6 implementations SHOULD
> [implementar draft-ietf-6man-stable-privacy-addresses]...".
> 
> 
> 
>>> * 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, 
> 
> Si.. Y ser tuerto es "mejor" que ser ciego :-) Pero yo siempre optaria
> por tener los dos ojos, en la emdida de lo posible...
> 
> 
>> y además esta el argumento si el scanning realmente
>> sirve de algo.
> 
> Esto es un argumento tipico de vendor, para no hacer nada. Para atacar
> un sistema, primero tenes que saber que existe. Entonces, salvo que
> sepas previamente de la existencia del sistema, el escaneo es mas que
> escencial.
> 
> 
> 
>>> * 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. 
> 
> A mi no me interesa el numero, sino el orden de magnitud. 4 horas, 1
> dia, 10 dias o un mes, me da lo mismo.
> 
> El punto es que lo de los 500,000 años fue una expresion de deseo (o
> abuso de canabis :-) ). Y de errar para algun lado, es preferir errar
> del lado seguro.
> 
> 
>> 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).
> 
> Cual es el costo? Que el vendor haga lo que tiene que hacer? Que la IETF
> mantenga las especificaciones como debe? O cual?
> 
> 
>>> * Ṕ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.
> 
> La especificacion dice que las claves se deben generar de manera
> aleatoria, y hasta se provee una referencia que explica bien claro "que
> se quiere decir con 'aleatorio'".
> 
> Si, esta claro que muchos vendors hacen muchas idioteces. Pero yo
> escribo drafts que apuntan a gente con un minimo de coherencia técnica.
> Si tengo que asumir que el tipo que va a leer mi trabajo es un idiota
> que no entiende que si la clave es conocida, el mecanismo muere,
> entonces en vez de enviar mis publicaciones a la IETF, las enviaria a
> algun simposio de psicologia.
> 
> Y no, no es que crea que nadie vaya a caer en la idiotez de claves por
> default, y esas cosas (de hecho, ni bien publicamos RFC 6528, tuve
> justamente una charla con un vendor sobre *exactamente* este tema)....
> Pero si vamos a condicionar el avance en un área en base a las idioteces
> que gente que deberia estar bien capacitada puede hacer, estamos perdidos.
> 
> 
> 
>> 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.
> 
> Y en ese punto, el argumento sería que "IPv6 esta ampliamente
> desplegado... por lo cual es peligroso hacer cambios de ese estilo".
> 
> 
> 
>>> * 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.
> 
> Bueno, pero eso no puede ser un argumento para no hacer lo que se debe
> hacer...
> 
> Tal vez podria agregar una seccion titulada "Idiocy considerations"? :-)
> 
> 
> 
>> Tampoco mucho hubo mucha objeción a favor de no depreciar el
>> estándar.
> 
> La gente con al que yo recuerdo haber hablado, apoyaba la idea de
> recomendar este approach. Pero con este I-D ya tuve varias batallas, y
> honestamente no me iba a poner a pelear yo solo esta otra.
> 
> 
> 
>>> 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 un tipo hace cosas tales como poner una clave por defecto en el
> algoritmo, el tipo es un idiota, y no hay remedio a eso.
> 
> 
> 
>> 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.
> 
> Que resultado da tu analisis de riesgo cuando evaluas tener IPv6
> habilitado por defecto en un sistema operativo de proposito general?
> 
> Cual es la magnitud del mismo en comparación con el riesgo de
> implementar mi propuesta?
> 
> 
>>> 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.
> 
> Dios esta por sobre todos nosotros ;-)
> 
> 
> 
>> 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.
> 
> Ese es el problema. Es muy triste que hacer las cosas de manera
> colaborativa requiera x2 de esfuerzo.
> 
> Un abrazo,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont at si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 




More information about the LACTF mailing list