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

[Fernando Gont]

Hola, Arturo,

El bottom-line de mi argumento es que hay que separar lo técnico de lo
"social" (por ponerle a esto último un nombre).

La "gracia" de trabajar en un area técnica es que en gral se puede
evaluar de manera concreta que es efectivo, y que no lo es. Y que se
puede establecer ciertas bases para comparar las "bondades" de distintas
approaches para lograr un determinado fin.

Cuando uno empieza a hablar de "percepciones", se acaba cualquier
esperanza de avanzar en un area técnica. Si con "percepción" tenemos que
tener en cuenta, por ejemplo, el potencial "miedo" que puede tener la
gente a desplegar una tecnología, o cosas de ese estilo, estamos perdidos.

De hecho, hasta te diría que la gran mayoría de "impedimentos" que
personalmente encuentro en lo cotidiano tienen que ver con cosas
humanas. Desde un vendor que quiere frenar una propuesta para no tener
que poner gente a implementarla, a un tipo que se opone a un update de
un standard que él escribió (por cuestiones de ego), o percepciones de
relevancia propia en las que un tipo condiciona su apoyo a una propuesta
a figurar como co-autor de la misma.

En la medida que quienes trabajamos en el area técnica nos focalicemos
en mejorar la calidad *tecnica* de nuestro trabajo *tecnico*, creo que
el campo va a mejorar.

Respecto de IPv6, personalmente creo que en lineas generales los
protocolos no presentan un avance por sobre IPv4, ni una posibilidad
concreta de hacer mas dinero.

Entonces se termina cayendo en la negación, y caemos en cosas como:

- "Las empresas no entienden que con IPv6 se pierden de hacer dinero!"
(primera vez en la historia de la humanidad(?) que la gente se preocupa
por que *otros* se llenen de dinero :-))

- "El 40% de mi trafico es IPv6" (aseveración post-canabis :-)
correspondiente a escenarios tipo "la medicion se hizo sobre un rele 6to4")

- "La gente no despliega IPv6 porque X" (donde X es algo distinto a
"cuesta dinero, y no queda en claro como se puede hacer dinero con el")

- "Que bueno que el vendor X va a particpar en el World [blahblah] IPv6
day" (en vez de pensar "Esto es de no creer! Los tipos estos se vienen
llenando la boca desde hace 10 años que apoyan IPv6, y recien en el 2012
van a habilitarlo en su sitio web!?!?")


Fijate, sin ir mas lejos, cuan controversial es llamar a las cosas por
su nombre, y decir "IPv6 nos aporta las direcciones que necesitamos, y
punto", y siempre caemos, en un punto u otro, en cosas tales como
"potenciales beneficios", "{seguridad, QoS, whatever} mejorada","en
teoria...", etc.

Si yo tuviera que preocuparme por las percepciones que tiene la misma
gente que "acepta" el mismo tipo de cosa que menciono arriba, en vez de
escribir drafts, me internaría en un neuro-psiquiatrico. :-)

Volviendo a cuestiones de "percepcion", lo cierto es que tanto los
estandares como las propias implementaciones de IPv6 son inmaduras. Así
que si alguien percibe inmadurez, puede sentirse tranquilo de que su
psiquis está funcionando correctamente. :-) -- Yo mismo he encontrado en
distintas implementaciones de IPv6 errores del mismo tipo que cometía yo
a los 10 años de edad en mis programas de Talen MSX. Y lo que es peor,
en muchos casos pasan años sin que los fabricantes los parcheen, y en
ocasiones hasta dan motivos estupidos para no parchearlos.

La unica manera de cambiar la realidad es asumir qué es lo que está mal,
y qué es lo que debe mejorarse. Y que la comunidad haga lo propio para
que tanto los vendors como la IETF hagan lo que se supone que tienen que
hacer. -- Y si.. tal vez eso implique mucho trabajo, updates de
estandares, o lo que sea. Pero es lo unico que nos va a llevar a una mejora.

Creo que por sobre todas las cosas, es importante que el area avance y
mejore... al menos con pequeños pasos. Personalmente que esto es mas
importante que IPv3, IPv4, IPv6, o IPv7.

En lo que al "ambiente IPv6" (por llamarlo de algun modo) respecta, a
veces me hace recordar a una escena de la pelicula Titanic, en donde el
barco se está hudiendo, pero los musicos siguen tocando -- pretendiendo
que "está todo bien" -- en vez de ser algo mas prágmaticos, e intentar
sacar el agua, o agarrar un bote. ;-)

De cualquier modo, aclaro:
Tal como comentaba en otro mail, en materia de "updates a estandares", y
cosas similares, algo como mi propuesta es lo que menos deberia publicarnos.

Sin ir mas lejos, personalmente me preocupa mas estar en el año *2012*
todavia definiendo que tiene que tener un CPE adentro (rfc6204bis), como
elegir las direcciones de origen para no meterse en problemas (address
selection), etc.

Un abrazo,
Fernando




On 05/21/2012 02:59 PM, Arturo Servin wrote:
> 
> 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
>> 
>> 
> 
> 


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