[LACNIC/Seguridad] Fwd: Deprecating EUI-64 Based IPv6 Addresses (Fwd: New Version Notification for draft-gont-6man-deprecate-eui64-based-addresses-00.txt)

Fernando Gont fgont en si6networks.com
Vie Oct 25 15:01:33 BRST 2013


Iván,

On 10/25/2013 12:03 PM, Iván Arce wrote:
> On 10/24/13 9:05 PM, Arturo Servin wrote:
>> Ya lo lei, aun no estoy muy de acuerdo en obsoleter totalmente la 
>> generación de IDs de interfaz sin usar la MAC address, sobre todo
>> porque aun no tenemos una forma probada de hacerlo de otra forma.
> 
> ?! Que significa eso? Que actualmente la única forma en que se genera
> un IID es embebiendo la MAC? si la respuesta es no, entonces eso
> constituye un contra ejemplo que refuta la afirmación.

Para las direcciones estables, la unica manera *estandarizada* es
embebiendo la MAC address. Microsoft no usa ese esquema, sino que
utiliza RFC4941, sin cambiar la direccion en el tiempo (basicamente,
setea el IID a un numero aleatorio que mantiene durante toda la vida del
sistema).




>> Si bien no veo ninguna utilidad de la generacion por MAC, no se si
>> sea factible de que el draft diga "MUST NOT" como se ha discutido
>> en 6man. Creo que es más realista un documento intermedio que diga
>> "SHOULD NOT" o "SHOULD use another mean".
> 
> Si, es la diferencia entre prohibir una conducta que filtra
> información privada de los endpoints y simplemente sugerirla pero no
> hacer nada para evitar activamente el problema.  La segunda posición,
> que es la tradicional del IETF, ha derivado en innumerables problemas
> de seguridad durante las últimas décadas.

FWIW, lamentablemente todo indica que ambiaremos al I-D a "SHOULD NOT"
(no porque sea lo correcto, sino para tener consenso).

Lo mas ridiculo del caso es que toda esta cuestión de usar IDs
predecibles tiene un historial larguisimo. Personalmente, soy un
agradecido a la comunidad que, habiendose golpeado (y continuado
haciendo) con la misma piedra una y otra vez, han permitido un ROI
tendiente a infinito en esta materia.



> En mi opinión sería preferible que las consideraciones de seguridad
> y privacidad de IPv6 estén explícitamente contempladas en los RFC 
> respectivos o en un solo RFC en lugar de generar una proliferación de
> un montón de I-Ds para atender en cada uno detalles puntuales y muy 
> específicos de los protocolos.

El gran problema de esto es que si el I-D en cuestión apunta a updatear
especificaciones (i.e., "Std Track"), resulta imposible hacer progreso
en un I-D de ese estilo.

Sin ir mas lejos, incluso en esta materia de direccionamiento, yo ataque
el problema con un solo I-D (draft-ietf-6man-stable-privacy-addresses),
y la unica manera de conseguir progreso fue dividir el I-D en tres:

1) draft-ietf-6man-stable-privacy-addresses: Que propone un esquema
   alternativo a embeber la direccion MAC en el IID

2) draft-ietf-6man-ipv6-address-generation-privacy: Que analiza las
   implicancias de seguridad y privacidad de incluir la MAC address
   en el IID.

3) draft-gont-6man-deprecate-eui64-based-addresses: Que recomienda "1)"
   y deprecatea el esquema que pone MAC addresses en los IIDs.



> Una solución de compromiso podría ser (si es que no existe ya) un
> I-D que mapee todos los I-Ds relacionados con seguridad y privacidad
> de IPv6, algo así como un "Security and privacy considerations for
> IPv6 implementers/developers"

Esto es viable si el track es "Informational" (yo lo hice para IPv4 en
RFC6274), pero, por los motivos de arriba, resulta imposible si el
documento es "Std Track". De hecho, intenté hacer lo mismo apra TCP
(<http://tools.ietf.org/html/draft-ietf-tcpm-tcp-security-03>), pero
luego de romperme la cabeza para que el documento se adopte, el esfuerzo
termino siendo abandonado.

El gran problema con estas cosas es "social", mas que tecnico:

* Quienes asumen que esconder problemas de seguridad/privacidad es
  mejor marketing que admitirlos y repararlos.

* Quienes sienten su ego lastimado si se encuentran problemas en
  tecnologias que ellos diseñaron

* Vendors, que no quieren updatear implementaciones apra arreglar
  problemas, ya que los fixes no los venden como "features", entonces
  les cuestan dinero sin ganancia economica directa.


Como dijo uno:

    "You each name yourself king, yet the kingdom bleeds,
     and no one lifts a sword to defend it but my son.”

Eventualmente, creo que lo mas sano es publicar herramientas de
ataque/auditoria/PoC, de modo que, de uno u otro modo, cada uno decida
(asi sea implicitamente), si desea fumar los fixes, o las vulnerabilidades.

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







Más información sobre la lista de distribución Seguridad