Resumen de IETF101 en Londres

La reunión IETF101 tuvo lugar en Londres, del 17 al 23 de marzo de 2018. A continuación, se resumen algunos de los temas tratados.

IPv6

En el grupo de trabajo v6ops hubo una interesante presentación sobre cómo brindar servicios IPv6-only en un datacenter, recorriendo los principales servicios de software y arquitectura que se ofrece a los usuarios, analizando cuáles de ellos están preparados para ser implementados sobre IPv6 y cuáles presentan problemas. Hay una gran cantidad de servicios y aplicaciones analizadas, por lo que vale la pena darle una mirada a esta presentación: IPv6 Only Hosting

Otro draft de interés que se presentó en este grupo es “IP Fragmentation Considered Fragile”, que analiza las problemáticas asociadas a la fragmentación de paquetes en Internet, no sólo en IPv6 sino también en IPv4. Una consideración importante es cómo afecta la fragmentación (y sus fallas) al uso de DNSSEC, debido a las respuestas de mayor tamaño que no entran en un paquete estándar. El documento analiza las posibles fallas y brinda una serie de recomendaciones tanto para desarrolladores como para operadores de red.

Finalmente, tres draft presentados por Jordi Palet que valen la pena comentar: uno con guías para la implementación de NAT64 en operadores y redes empresariales, comparando esa solución con 464XLAT y enfocado en solucionar fundamentalmente los problemas que introduce DNS64 en conjunto con DNSSEC. El segundo draft es una recopilación de las RFCs que hablan sobre numeración de los enlaces punto a punto y de las distintas opciones, tanto de numeración (/127, /64, /126, etc), como sobre el tipo de direcciones (GUA, ULA, unnumbered), junto con otras consideraciones adicionales. El tercer draft es una variante de otros documentos que tienen que ver con requisitos para los routers de cliente: “Transition Requirements for IPv6 CE Routers to support IPv4 as a Service”. La importancia de este draft radica en que especifica como requisito algunas de las tecnologías de transición mas utilizadas recientemente para los routers de cliente. De esta forma, se facilita la implementación de técnicas que permitan contar con redes WAN IPv6-only, permitiendo de todos modos la conectividad a sitios IPv4-only mediante lo que se conoce como “IPv4 as a service”. Los operadores de red pueden, mediante estas técnicas de transición, provisionar redes donde sólo utilizan IPv6 (con el consiguiente ahorro de direcciones IPv4), mientras que los usuarios aún contarán con la posibilidad de acceder a servicios IPv4.

En cuanto al grupo 6man, los draft de mayor interés tuvieron que ver con los identificadores de interfaz en IPv6 y consideraciones de privacidad/seguridad. El primero, https://tools.ietf.org/html/draft-gont-6man-non-stable-iids es análogo a la RFC8064 pero para direcciones temporarias y no estables. El segundo, https://tools.ietf.org/html/draft-gont-6man-rfc4941bis, es un cambio a la RFC4941 que define extensiones para generar direcciones de alcance global temporarias a partir de identificadores de interfaz que cambian con el tiempo. El espíritu de estos documentos va en la misma tendencia de otras RFC como la 7217 y 7721, que buscan evitar los problemas asociados a la utilización de direcciones que puedan ser rastreadas o que revelen información de los dispositivos. Vale la pena mencionar que este es uno de los cambios importantes que ha tenido IPv6 en los últimos años, sustituyendo la asignación de identificadores de interfaz basada en EUI-64 por otras técnicas que tratan de solucionar los problemas de seguridad y privacidad asociados a los identificadores basados en la dirección MAC de los dispositivos.

Ruteo

Una de las presentaciones mas interesantes en el grupo de trabajo grow y que tiene relevancia para nuestra región fue una propuesta de Job Snijders titulada “ÏRR and RPKI feature parity”. La propuesta es básicamente incorporar a RPKI algunas características que están presentes en los IRRs, tales como AS-SET. Este atributo de RPSL es muy utilizado por los operadores, al establecer una relación de peering con otro AS, para especificar el conjunto de sistemas autónomos a los cuales se brinda tránsito. La idea de la propuesta es extender los objetos firmados mediante RPKI para obtener una funcionalidad similar a la de los IRR. La propuesta tuvo buena aceptación, si bien aún no hay un draft escrito. La región de LAC es una de las que mayor adopción de RPKI tiene, por lo que contar con herramientas similares a las de un IRR podría consolidar aún más el uso de RPKI por parte de los operadores.

En el grupo sidrops uno de los drafts en discusión propone un solución con una versión “light” de RPKI para los IXPs. En esta propuesta, un route-server sería el que realiza la validación pero tiene la opción de no descartar las rutas y simplemente etiquetarlas con una comunidad que indique si el prefijo es válido, inválido o desconocido. Esta propuesta generó mucha discusión pues hubo objeciones a que un route-server dentro de un IXP propague rutas inválidas, en lugar de descartarlas.

Otra presentación de interés fue acerca de la versión 3 del validador de RIPE (el software para validación de RPKI más utilizado actualmente) por parte de Tim Bruijnzeels, describiendo sus funcionalidades y características implementadas al día de hoy. Es una buena oportunidad para probar el software y comparar con la versión actual.

Para quienes quieran tener una introducción a la gran cantidad de RFCs acerca de RPKI junto con una descripción de los componentes funcionales que constituyen un RP (Relaying Party), el draft draft-ietf-sidrops-rp puede ser de gran ayuda, ya que agrupa las RFCs según correspondan a: a) obtención y caching de los repositorios de objetos; b) procesamiento de los certificados y CRLs; c) procesamiento de los objetos firmados en el repositorio y d) envío de los caches de validación a los routers BGP.

DNS

En dnsop hubo una presentación inicial por parte de los chairs haciendo referencia a la gran cantidad de drafts en discusión que continúan abiertos y no finalizan su proceso. Esto hace que la actividad sea cada vez mayor y las tareas de los chairs se incrementen por lo que solicitaron designar un tercer chair para el WG. En cierto modo esto se relaciona con otro de los puntos que se trataron, que tiene que ver con la discusión acerca de cuántas nuevas características se pueden sumar al protocolo sin que deje de funcionar, o sea sin que se rompa. Esto ya fue mencionado en la RFC 8324, donde se analiza la gran cantidad de nuevas funcionalidades que se han incorporado o proponen para el DNS y se discute si no sería necesario pensar en otro protocolo. Una de las consecuencias de esta gran cantidad de características incorporadas es que disminuye el número de personas en condiciones de entender la totalidad de RFCs y opciones existentes, haciendo menos estables las implementaciones de software de DNS, lo que a su vez impacta sobre la estabilidad del DNS global. Hubo mucho debate en torno a este tema, que tiene cierta similitud con lo que sucede con BGP en el mundo del ruteo y la gran cantidad de cambios que se proponen.

En el grupo dprive, una vez finalizado el trabajo sobre garantizar privacidad entre el resolver y el servidor recursivo, se discutió acerca de cómo seguir. En ese sentido se propuso continuar con un trabajo similar para garantizar la privacidad entre los servidores recursivos y los autoritativos. Esto es algo que se analizará como una propuesta para un nuevo chárter del grupo.

Un interesante punto en discusión fue el draft-dickinson-bcp-op, que brinda recomendaciones para quienes quieran implementar un DNS que ofrezca servicios de privacidad. En este documento se trata entre otras cosas DNS sobre TLS y DNS sobre DTLS, así como también el manejo de la información de los usuarios en los servidores recursivos. La posibilidad de garantizar privacidad de una manera clara y definida es algo que puede ser un elemento diferenciador entre el operador de DNS y sus usuarios, sobre todo en la medida que surgen proyectos de open resolvers.

Otros temas

opsec

Uno de los principales drafts que se presentó fue “Operational Security Considerations for IPv6 Network”. Este documento se comenzó a escribir hace 6 años, en 2012 y contiene distintas secciones: consideraciones generales, específicas para empresas, para service providers y para home users. En esta ocasión se revisaron los textos sobre direcciones ULA y sobre túneles. Finalmente se pidió que el draft sea llamado a last call dado que ya ha alcanzado una madurez considerable.

maprg

En este grupo hubo una presentación sobre el despliegue y el uso de QUIC en Internet, “QUIC in the wild”, y una sobre el uso de HTTP/2, que muestran el grado de despliegue de estos nuevos protocolos.

También un análisis del uso de blackholing en BGP en Internet, que muestra que el número de ISPs que proveen este servicio está creciendo, así como el número de usuarios que lo solicitan. En la región de LAC, sin embargo, aún son pocos los ISPs que brindan esta posibilidad a sus usuarios. Sería interesante que existan más opciones en este sentido, ya que permiten evitar ataques de DDOS de una manera sencilla.

Otra presentación que vale la pena mencionar fue “Update on IPv6 Performance”, por parte de Tommy Pauly de Apple, en donde mostró datos sobre porcentajes de disponibilidad de IPv6 en redes WI-FI y en redes de celulares a nivel mundial y detallado por países. En la mayoría de los casos se muestra que las conexiones via IPv6 se establecen más rápido que en IPv4 tanto en las redes WI-FI como en las celulares, aunque en estas últimas hay mayor variación de acuerdo al proveedor. A su vez, es interesante comparar la gran penetración de IPv6 en las redes celulares de algunos países como EEUU (87%) con otros donde es prácticamente inexistente, como UK (0.12%) o Bélgica (0.05%), pero que sin embargo sí tienen grandes despliegues de IPv6 en otro tipo de redes.

Este es apenas un breve resumen de algunos de los temas que se trataron en la reunión. Se puede ver más información en los sitios de cada uno de los grupos de trabajo. Ver: https://datatracker.ietf.org/meeting/101/agenda.html