Por Tomek Mrugalski y Bernie Volz
QUIENES PARTICIPAN EN EL IETF HACE TIEMPO SABEN QUE EL GRUPO DE Trabajo sobre Con guración Dinámica de Host (DHC) viene trabajando desde hace mucho tiempo. Sin embargo, determinar su edad con precisión ha sido un desafío. Según los archivos del grupo, su primer correo electrónico se envió1 el 12 de julio de 2001. Pero esa fecha no puede ser correcta, ya que su primera solicitud de comentarios (RFC) es la RFC 1531 de octubre de 1993. El historial del Datatracker sobre DHC2 ofrece algunas pis- tas, aunque los datos parecen incompletos: las actualizaciones signi cativas se remontan a 2003, después de lo cual sigue un intervalo de trece años y hay dos entradas que indican que el grupo de trabajo fue propuesto y se formó el 1 de enero de 1991. Si esto es correcto, el grupo tendría la impresionante edad de 26 años, al menos tan antiguo como la Web, cuya fecha de creación suele ser considerada como enero (primer servidor público disponible) o agosto (Sir Tim Berners-Lee anuncia el proyecto al agrupo de discusión alt.hypertext) de1991. No obstante, hay otra pista que indica que el DHC es todavía más viejo: la lista de grupos de trabajo activos en el sitio web del IETF3. Si bien la página en sí es algo básica, las fechas que aparecen junto al nombre de cada grupo de trabajo parecen ser sus fechas de creación. En esta página, la fe- cha de creación indicada para el DHC es “1989-Apr-13”, hace casi veintiocho años.
Entonces, ¿qué ha estado haciendo el grupo sobre DHC todo este tiempo? Su ob- jetivo original no ha cambiado. Fue creado para con gurar hosts de forma dinámica y eso es lo que ha hecho. Si lo pensamos un poco, las redes modernas son totalmente diferentes a cuando se inició el trabajo. A nales de los años 80, una red “grande” probablemente incluiría alrededor de cien computadoras de escritorio. No existía ningún concepto de movilidad y el trabajo en IPv6 realmente todavía no había co- menzado. Mucho ha cambiado y el DHC ha hecho todo lo posible para seguir el ritmo de la realidad cambiante. En el proceso, el grupo de trabajo publicó 96 RFCs que de- nieron, aclararon y mejoraron diferentes aspectos de la autocon guración de los dispositivos. Dispositivos, porque hoy en día hay mucho más que solo hosts. Y esto plantea la pregunta: ¿hay algo más que el DHC todavía deba hacer?
DHCPv6bis
Al igual que la mayoría de los grupos de trabajo del IETF, el DHC pre ere no invertir su tiempo en tecnologías heredadas, como IPv4, excepto en los casos en que resulta útil par la transición a IPv6. En términos de DHC, esto signi ca que el grupo trabaja casi exclusivamente en DHCPv6. Este protocolo básico (RFC 3315) se publicó en 2003. Mucho ha cambiado desde en- tonces. Lo más notable es la capacidad de participar de los routers, no solo de los hosts. Los routers generalmente utilizan el mecanismo de delegación de pre jos (RFC 3633). Además, con los cambios re- cientes en la forma en que se organizan las redes, los supuestos originales han perdido validez. La distinción entre hosts y routers se ha vuelto borrosa (si un teléfono se usa como hotspot o ejecuta máquinas vir- tuales, ¿el teléfono sigue siendo un host?), las formas en que se percibe la con anza han cambiado (¿los usuarios confían en que el hotspot de la cafetería que visitan son legítimos?), y también han cambiado nuestras expectativas (¿demora todo un segundo conectarnos a una red?).
El Grupo de Trabajo DHC está abordando algunas de estas condiciones cambiantes mediante una iniciativa para volver a pu- blicar la especi cación DHCPv6. Hoy, esta iniciativa representa el enfoque principal del grupo. Un equipo de diseño formado en 2013 tomó la RFC original (dato curioso: estaba en formato nro ); la emprolijó; tomó todas las erratas, correcciones y cambios que se habían introducido (por ejemplo, la RFC 7550, que mejoró varios problemas relacionados con la gestión del estado); y publicó versiones actualizadas4. El trabajo se organiza en torno a un issue trackerde- dicado5. El documento tuvo un muy exitoso período de últimos comentarios en el grupo de trabajo (WGLC) en 2016, durante el cual se recibieron casi trecientos comen- tarios independientes. El equipo de diseño mantiene reuniones quincenales con una hoja de cálculo pública en Google Docs y un texto borrador intermedio en un repo- sitorio github público. Se espera que los comentarios restantes sean tratados y pre- sentados durante el IETF 98 en Chicago. La intención es publicar el documento como un borrador de RFC y avanzar hacia un estándar pleno en el futuro.
Privacidad y seguridad
El concepto de seguridad también ha cambiado radicalmente a lo largo de los años. Tanto las revelaciones de Edward Snowden como la RFC 7258 llevaron a que muchos grupos de trabajo evaluaran nuevamente ciertos mecanismos que se pueden utilizar para el monitoreo omni- presente y otros ataques a la privacidad. Además, la forma en que la gente utiliza las redes ha cambiado. Hoy en día, pa- reciera que usar Internet en una cafetería de la que no sabemos nada es mucho más común que tener nuestros dispositivos co- nectados a una red cableada cuyo admi- nistrador conocemos personalmente. El DHC invirtió mucho tiempo en revisar los mecanismos y opciones tanto de DHCPv4 como de DHCPv6 para averiguar cuáles se podían emplear para el seguimiento de dispositivos y usuarios. Como resultado, en la RFC 7844 se publicó una recomen- dación llamada per l de anonimato, que re- comienda ciertos cambios para los clientes que desean proteger su privacidad. Los clientes que implementan esta recomen- dación no revelan ninguna información personal de utilidad y no utilizan ningún tipo de identi cadores de larga duración que puedan ser usados para rastrearlos.
Al mismo tiempo, hay modelos de des- pliegue prácticamente opuestos: en ciertos despliegues los clientes desean probar su identidad a la red y veri car que la red es realmente lo que dice ser. La seguridad y la prevención de la vigilancia generalizada es una gran preocupación para todos y la falta de seguridad (cifrado y autenticación) ha sido un problema de larga data para el DHCP, ya que este protocolo se utiliza para conectarse a muchas redes. Este trabajo6 comenzó a nales de 2013 y se ha reiniciado varios veces después de su revisión por parte del Grupo Directivo de In- geniería de Internet (IESG). El documento actual considera el cifrado de las interac- ciones cliente/servidor. Se anticipa que el trabajo pronto pasará al período de últimos comentarios y esperamos que se vuelva a intentar obtener la aprobación del IESG.
El futuro
DHCPv6 es un protocolo extensible para el cual se de nen aproximadamente diez nuevas opciones por año. La mayoría de estas opciones transmiten nuevos pará- metros que se espera que el servidor en- tregue a los clientes —estos parámetros no modi can la forma en que funciona el pro- tocolo—. Como tal, cada vez más la de – nición de opciones se está llevando a cabo fuera del DHC, en grupos dedicados que comprenden expertos en la materia y que pueden veri car mejor el contenido real de esos parámetros. En mayo de 2014, el DHC publicó la RFC 7227, que contiene di- rectrices para los autores que trabajan en nuevas opciones. Sin embargo, se están discutiendo varios mecanismos de ex- tensión que son especí cos del protocolo, por lo que pertenecen dentro del DHC. La de nición de modelos YANG, proveer to- lerancia frente a fallos para DHCPv6 y ajustar cómo funcionan los agentes de re- transmisión (relays) son apenas algunos ejemplos del trabajo que se está realizando actualmente7.
Tal vez se esté preguntando si el DHC ter- minará su trabajo pronto. Cuando entregó la dirección a los actuales presidentes Bernie Volz y Tomek Mrugalski, Ted Lemon comentó que al grupo quizás le quedarían cinco años de trabajo. Luego agregó que, cuando él se hizo cargo, el presidente sa- liente había hecho el mismo comentario. ¿Quién sabe? Quizás Volz y Mrugalski transmitirán ese mismo pronóstico a sus sucesores.
Notas al pie
1. https://www.ietf.org/mail-archive/web/dhcwg/ current/mail402.html.
2. https://datatracker.ietf.org/wg/dhc/history/.
3. https://tools.ietf.org/wg/.
4. https://tools.ietf.org/html/draft-ietf-dhc- rfc3315bis.
5. http://tools.ietf.org/group/dhcpv6bis/.
6. https://tools.ietf.org/html/draft-ietf-dhc- sedhcpv6-20.
7. https://datatracker/wg/dhc/documents y https://datatracker.ietf.org/wg/dhc/charter/