El regreso a la presencialidad en los encuentros del IETF (Grupo de trabajo de ingeniería de Internet) continuó durante este mes de julio pasado en Philadelphia (EEUU) con aproximadamente 1.300 participantes registrados, entre presenciales y remotos.
Fue un evento en el que sentimos el calor humano de vernos las caras, y logramos recuperar encuentros casuales que no se podían tener en los eventos en línea. Pudimos volver a compartir diseños, diagramas y charlas sobre diferentes aspectos de la arquitectura de Internet en grupos rodeando pequeñas mesas del lobby y bar del hotel, o en la sala del evento.
Novedades técnicas. De las sesiones del Internet Research Task Force (IRTF), un grupo hermano del IETF que se enfoca en investigación a largo plazo, me llamó la atención el énfasis en la aplicación de técnicas de aprendizaje automático (machine learning) a problemas de redes. Dos presentaciones de la Universidad de Stanford destacaron trabajos de investigación sobre el uso de aprendizaje automático para automatizar la gestión del tráfico en Internet.
(Acceso libre, no requiere suscripción)
Mediante estas técnicas sería posible identificar aplicaciones que están corriendo en la red, tratarlas de manera diferenciada y poderles brindar anchos de banda y otros parámetros de calidad de servicio según las características de cada una.
En relación al mundo de Internet de las Cosas, me pareció muy interesante el trabajo Performant TCP for Low-Power Wireless Networks donde muestran que implementando una serie de optimizaciones y asumiendo ciertos compromisos es posible utilizar TCP en familias de dispositivos de recursos muy limitados. Esto abre puertas a ciertas aplicaciones que no están mapeadas sobre UDP y evita el tener que “reinventar” ciertas funcionalidades de TCP como la recuperación de paquetes perdidos en cada protocolo de aplicación.
En las sesiones propiamente del IETF, me gustaría resaltar el trabajo que lleva adelante el grupo de trabajo de v6ops. El grupo v6ops desarrolla directrices para el despliegue y la operación de redes IPv6 nuevas y existentes.
Mediante estas técnicas sería posible identificar aplicaciones que están corriendo en la red, tratarlas de manera diferenciada y poderles brindar anchos de banda y otros parámetros de calidad de servicio según las características de cada una.
En relación al mundo de Internet de las Cosas, me pareció muy interesante el trabajo Performant TCP for Low-Power Wireless Networks donde muestran que implementando una serie de optimizaciones y asumiendo ciertos compromisos es posible utilizar TCP en familias de dispositivos de recursos muy limitados. Esto abre puertas a ciertas aplicaciones que no están mapeadas sobre UDP y evita el tener que “reinventar” ciertas funcionalidades de TCP como la recuperación de paquetes perdidos en cada protocolo de aplicación.
En las sesiones propiamente del IETF, me gustaría resaltar el trabajo que lleva adelante el grupo de trabajo de v6ops. El grupo v6ops desarrolla directrices para el despliegue y la operación de redes IPv6 nuevas y existentes.
Uno de los drafts presentados trata sobre cómo usar correctamente las ULAs (unique local addresses) y sobre la aplicabilidad de los encabezados opcionales de IPv6. Las ULAs son el equivalente en IPv6 a las direcciones privadas de IPv4, pero a pesar de haber sido especificadas hace mucho tiempo, ciertos aspectos de su aplicación operativa siguen abiertos a debate. El documento “Unintended Operational Issues with ULAs” discute algunos aspectos que siguen abiertos con ellas.
Existe un renovado interés por entender mejor el comportamiento de los encabezados opcionales de IPv6. Mediciones que datan de hace algunos años mostraban una tasa de descarte de paquetes con encabezados opcionales inaceptablemente alta. Ahora, otro grupo de investigadores está repitiendo estas medidas para poder comparar la realidad actual con la situación pasada. Este proyecto fue presentado bajo el nombre de JAMES. Estaré expectante para ver los resultados que logran.
Otro aspecto positivo de las sesiones del IETF resultaron ser los trabajos sobre validación de origen (Using BGP updates for Source address validation). Se trata de uno de los grandes temas no resueltos para evitar que no se inyecten paquetes y de esa manera sufrir ataques de denegación de servicios. Las técnicas existentes hoy en día no cubren todos los casos o no lo escalan.
Por eso me pareció muy innovador y prometedor un trabajo llamado BAR-SAV, sobre cómo usar RPKI para hacer validación de origen. Consiste en usar la información que está en los ROAs e introducir mensajes nuevos del protocolo BGP.
El documento divulgado en el último IETF avanza en el diseño de filtros SAV a través de un método que hace uso de mensajes de actualización BGP, Sistema Autónomo Autorización de proveedor (ASPA) y Autorización de origen de ruta (ROA). BAR-SAV puede ser utilizado por los operadores de red para derivar filtros SAV más robustos y, por lo tanto, mejorar la resiliencia de la red.
Para terminar, una reflexión. Internet a mi juicio va a ser siempre un “work in progress”. Por su propia naturaleza Internet necesita evolucionar de manera continua. Por ello me resultó reconfortante ver que después de dos años de largo alejamiento la comunidad del IETF sigue tan vibrante como siempre, y lista para tomar los desafíos de continuar construyendo Internet.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
