[LACNIC/Seguridad] RFC7943 sobre DHCPv6 IIDs (a Diego Maradona)

Fernando Gont fgont en si6networks.com
Mie Sep 21 07:41:50 BRT 2016


Estimados,

Se ha publicado el RFC 7943, titulado "A Method for Generating
Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)". El mismo se encuentra
disponible en: <https://www.rfc-editor.org/rfc/rfc7943.txt>

Este es el RFC #28  de Argentina. Y al igual que el resto de
los mios, ha sido inspirado por Diego Armando Maradona (*):

   "Fernando Gont would like to thank Nelida Garcia and Guillermo Gont
   for their love and support, and Diego Armando Maradona for his magic
   and inspiration." (<https://tools.ietf.org/html/rfc7943#page-10>)

Este RFC tiene un historia bastante interesante, en la que no voy a
ahondar mucho :-), pero basicamente fue adoptado y luego desadoptado por
el dhc wg, sin demasiados argumentos, o peor, con argumentos tecnicos
que creo incorrectos (mis comentarios al respecto pueden leerse en:
<https://www.ietf.org/mail-archive/web/dhcwg/current/msg16929.html>).

En consecuencia, envié este documento para que sea publicado en el
independent track del RFC-Editor. (Como en dicho "track" no se pueden
publicar estandares, el track fue cambiado a "Informational").

El RFC tiene una nota del IESG, la cual dice:

   "A predecessor to this document was earlier a working group document
    in the dhc WG. The WG decided to stop further work in this area
    because such work was not considered useful.

    The proposal described in this document has an unaddressed failure
    case that makes it unsuitable for use as the mechanism to provide
    the claimed failover features for DHCPv6 servers. Specifically,
    when a DHCPv6 client DECLINEs a provided address there is no
    recovery mechanism described that will result in the DHCPv6 client
    obtaining a working IPv6 address."


Al respecto:

 + Un par de participantes del DHC wg consideraron que como las
   direcciones son estables, entonces las mismas no son lo
   suficientemente buenas ya que permiten correlacion de actividades.
   Obviamente, con ese criterio uno deberia usar una direccion IPv6 por
   cada paquete o cada instancia de comunicacion, ya que en todo caso
   siempre seria posible (en mayor o menor medida, la correlacion de
   acividades).

   Por otro lado, un participante argumento que el mecanismo no puede
   proveer estabilidad de las direcciones en caso que el cliente se
   niega a aceptar el leas (via DECLINEs). Pero, con ese citerio, TCP
   tampoco es capaz de proveer confiabilidad si el extremo receptor
   decide descartar los paquetes recibidos. :-)
(<https://www.youtube.com/watch?v=hYVmGsRFfD8>)

+  Por otro lado, si bien es cierto el RFC no es explicito en este
   punto, la variable "Counter" de la expresion "RID = F(Prefix |
   Client_DUID | IAID | Counter | secret_key)" es justamente para
   solucionar conflictos de direcciones ("DECLINEs" siendo uo de los
   posibles).


** Epilogo: **

DHCPv6, al dia de la fecha, sigue sin tener algoritmos recomendados para
la generacion de IIDs, y es sabido que existen implementaciones que
generan direcciones predecibles con lo cual se facilita los ataques de
escaneo de direcciones (ver RFC7707). Esta problematica abarca a una
gran cantidad de protocolos, y es el topico de este I-D que hemos
escrito con Ivan Arce:
<https://tools.ietf.org/html/draft-gont-numeric-ids-history-01>


(*) <https://youtu.be/BCfGUo8uQhU?t=3m28s>

Saludos cordiales,
-- 
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