Del 14 al 18 de noviembre se llevó a cabo la reunión de IETF97. Durante la semana tuvieron lugar gran cantidad de actividades, no sólo de los grupos de trabajo, sino también otras reuniones en paralelo. El siguiente es un resumen de algunas de ellas.

IPv6

Los dos principales grupos que están trabajando en temas de IPv6, v6ops y 6man, tuvieron reuniones en Seúl.

En v6ops se presentó una nueva versión del documento sobre diseño de redes IPv6. Para mayor clarificación se cambió el título del documento a “Routing-Related Design Choices for IPv6 Networks”, a fin de especificar más claramente que este documento es sólo sobre temas de routing. Este documento está bastante maduro, por lo que está próximo a ser aprobado por el WG. Es importante que desde nuestra región, en base a la experiencia en operación de redes IPv6, aportemos al documento.

Otro documento que se presentó fue “Enterprise Multihoming using Provider-Assigned Addresses”, que intenta dar una solución al caso de multihoming en organizaciones que no tienen direcciones PI, sin usar NAT-NPT.

Sobre el final se mencionó el interés en contar con un documento que describa casos de uso / ventajas de IPv6 sobre IPv4 que surgen a partir de la experiencia en el uso de IPv6. Se analizará si es este el grupo adecuado para ello.

En 6man uno de los principales temas continuó siendo el análisis de los documentos de IPv6 para que pasen a ser estándares. Una discusión importante surgió por la posibilidad de cambiar el texto original de la RFC 2460 para describir los problemas de insertar Extension Headers en el camino, en lugar de no permitirlo como en la versión original. Este cambio deja abierta la puerta a modificaciones del modelo end to end y por eso generó un gran debate.

Ruteo

En Seúl se reunieron los grupos idr, grow y sidr.

En grow se presentaron varios documentos de interés para la comunidad de operadores. Uno de los principales tiene que ver con el comportamiento por default de BGP cuando una sesión no tiene ninguna política aplicada. Este documento propone filtrar todos los anuncios en caso de que no haya política configurada. Es importante considerar las implicancias que puede tener este cambio sobre las implementaciones existentes, si bien se puede considerar una medida sana a fin de tener un mayor control sobre los anuncios de BGP.

Otras presentaciones de interés fueron un documento sobre utilización de las “Large Communities” (el documento sobre large communities se prevé que sea aprobado próximamente), propuestas de mejoras a los mecanismos de uRPF y un debate sobre los requerimientos operativos a tener en cuenta en los futuros cambios en los protocolos.

En idr se comentaron los problemas que tuvieron al solicitar codepoint 30 a IANA para el atributo large communities. Este codepoint  ya estaba siendo utilizado por una compañía sin registrar. Hubo algunas propuestas para poder contar con atributos experimentales y no depender de la asignación de codepoints.

Varias presentaciones trataron sobre flowspec, una tecnología que puede ser utilizada para prevenir ataques de DDoS. Al respecto, dado que es un tema muy activo en este WG, sería interesante saber si hay casos de uso en LAC. Respecto a los debates sobre route leaks,  existe una propuesta de implementar “roles” en las sesiones BGP a fin de evitar propagar incorrectamente los anuncios que se reciben. Finalmente volvió a presentarse un draft para incorporar SPF (Dijkstra) a BGP: en este caso, uno de los Area Directors sugirió que no se trate en idr sino en rtgwg o en otro contexto, ya que se trataría de un nuevo protocolo y no un cambio a BGP.

Finalmente en sidr se trataron temas relacionados a la finalización del trabajo de este grupo y la continuación de algunas propuestas en el marco del nuevo grupo sidrops. Para este último grupo, ya se ha propuesto un chárter definiendo sus objetivos. Se presentó un documento que describe la implementación del software de validación de RIPE a fin de obtener una revisión independiente. También se debatieron cuestiones de interoperabilidad entre las implementaciones de RPKI y se propuso realizar algunos tests durante 2017, involucrando a los RIRs.

IoT

El WG LPWAN fue finalmente creado, por lo que se presentó el chárter del grupo que se enfoca en tecnologías de capa 2 mucho más restringidas que las que se usan en 6lowpan/6lo/6tisch. Existen un par de documentos que describen estas tecnologías y los desafíos para implementar el stack IP sobre ellas: https://www.ietf.org/id/draft-farrell-lpwan-overview-04.txty https://datatracker.ietf.org/doc/draft-minaburo-lpwan-gap-analysis/

En el WG se presentaron las principales características de cada una de ellas y propuestas de compresión de headers IP, UDP, etc, hasta 0 bytes, aprovechando la característica de topología en estrella que ellas tienen.

Otro grupo relacionado con IoT que se reunió en Seúl fue lwig, que recoge experiencias de la implementación de stacks IP sobre dispositivos restringidos. En este caso se presentó una propuesta de implementar TCP sobre redes de nodos restringidos (la preferencia actual es usar UDP en este tipo de redes) que será parte de RIOT próximamente. Una presentación sobre comparación de algoritmos de criptografía pública en microcontroladores de 8 bits mostró que algunos de ellos se comportan de forma aceptable, siendo posible utilizarlos, mientras que otros como por ejemplo RSA no podrán ser utilizados por problemas de performance. Finalmente, se realizó una presentación sobre los problemas en redes donde la densidad de nodos es tan grande que supera las capacidades que los cache de memoria pueden manejar.

Se realizó también un panel llamado “La I en IoT”, en el cual se debatió acerca de los desafíos para la Internet con la masividad de dispositivos conectados y la necesidad de tomar acciones a fin de proteger la red de ataques. En ese sentido, se debatió acerca de los recientes ataques de DDoS utilizando dispositivos vulnerables y cómo esto puede incrementarse en el futuro. Se hizo una analogía con las regulaciones vigentes para los automóviles y los permisos para circular para analizar la posibilidad de que existan regulaciones en ese sentido para los dispositivos de IoT. Finalmente, se hizo una apelación a que los fabricantes de dispositivos tengan mayor responsabilidad en estos temas.

Seguridad y DNS

Un tema recurrente en IETF97 fueron los ataques de DDoS ocurridos en los días previos,  ligados tanto al abuso de dispositivos conectados a la red, como a consultas a los servidores de DNS. En ese sentido hubo una presentación de Geoff Huston sobre DDoS en DNS y la forma de evitar consultas innecesarias mediante el uso de DNSSEC y NSEC. Un artículo al respecto se puede ver aquí: https://blog.apnic.net/2016/10/27/speculating-dns-ddos/

Una presentación sobre nuevos cripto algoritmos en DNSSEC y las consideraciones a tener en cuenta para su adopción fue realizada en dnsop, analizando cómo mejorar este proceso a fin de acelerar los tiempos de adopción.

Otras propuestas tuvieron que ver con requerimientos para delegaciones de DNS y los tests que podrían hacerse, procedimientos para transferir gTLDs, formato de captura de paquetes de DNS entre otras.

Se llevó a cabo un BoF llamado dnsbundled, en el cual se trató el tema de mapear una porción del árbol de DNS en otra. Este es un problema que surge con los nuevos TLDs y se presentaron algunos casos de uso. Hubo discusión acerca de si éste es un problema a resolver en el DNS o no.

Nuevos grupos

Además de LPWAN, un nuevo grupo que se reunió en IETF97 es QUIC. Este grupo intenta estandarizar el protocolo QUIC desarrollado por Google y tener una alternativa a TCP+TLS+HTTP2, con un protocolo basado en UDP, con múltiples “streams” y con TLS1.3 por default.

Uno de los desafíos de este trabajo de estandarización tiene que ver con el uso de formatos big-endian (IETF) vs little-endian (QUIC): hubo consenso en utilizar el formato habitual de IETF para la estandarización. Otros temas pasan por la diferencia entre números de secuencia de TCP y la numeración de paquetes. También los mecanismos de control de congestión. La implementación de TLS es  parte de la especificación del protocolo. Se debatieron también las alternativas de mapear HTTP/2 sobre QUIC.

Otro nuevo grupo en IETF97 es ipwave, que va a trabajar en las comunicaciones v2i (vehicles to infrastructure) y v2v (vehicles to vehicles) y desarrollar una solución basada en IPv6 para una comunicación segura y directa entre vehículos. Se espera reutilizar parte del trabajo desarrollado por otros grupos de IoT.

Otros temas

IETF @ Regions

Como es habitual, se desarrolló la reunión promovida por ISOC a fin de coordinar acciones para involucrar mayor cantidad de gente en IETF en regiones que hoy tienen baja participación. La experiencia de LAC es relevante en este sentido y si bien se ven casos de mayor actividad, un punto en debate fue cómo medir esa participación. Se propone tener algún tipo de indicadores de involucramiento de las regiones, a fin de poder evaluar el trabajo que se viene realizando.

IRTF

La IRTF realizó una sesión acerca de Machine Learning en la cual se debatió sobre cómo aplicar las técnicas de machine learning a la información que tenemos sobre nuestras redes. Entre ellas, hacer mining de datos de logs de servers y routers a fin de determinar correlación y causalidad. También la evolución y control de la red en base a lo aprendido. La intención de este trabajo es llenar un vacío entre la ingeniería de red y la ciencia de datos.

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 cada uno de los grupos de trabajo. Ver: https://datatracker.ietf.org/meeting/97/agenda.html