Del 17 al 22 de Julio se llevó a cabo la reunion de IETF96. El siguiente es un resumen parcial de la gran cantidad de actividades que tuvieron lugar en la semana.

Cryptech

El viernes 15 y sábado 16 se realizó un workshop de Cryptech en el que se presentó una versión alfa del dispositivo HSM en el cual se encuentran trabajando. El proyecto tiene como objetivo crear una especificación open-source para un hardware de criptografía, que sea independiente de cualquier vendedor. Es un proyecto financiado por diversas entidades no gubernamentales y abierto a la participación de otras organizaciones.

Durante el workshop se pudo utilizar la versión “alfa rev 03” con openDNSSEC como referencia y, si bien hubo algunas dificultades por no ser todavía una placa en producción, se pudo firmar zonas de DNS con las claves almacenadas en el dispositivo. El proyecto es interesante por sus características abiertas y auditables y espera continuar obteniendo financiamiento para la mejora del producto. Por otro lado, quien quiera fabricar un dispositivo de este tipo podrá utilizar las especificaciones open-source provistas sin cargos de ninguna índole.

IETF @Regions

En base a la experiencia desarrollada en Latinoamérica y la promoción de participación de la región en IETF, que culminó en la organización del IETF95 en Buenos Aires, se realizó una reunión con interesados en llevar la IETF a otras regiones como África, India, etc. Este tipo de reuniones, coordinadas por ISOC, se venían realizando fundamentalmente con los participantes de LAC en IETF, extendiéndose ahora a otras regiones.

En esta ocasión se discutió sobre las principales acciones exitosas que se llevaron adelante en LAC, tales como los “hubs” remotos de participación o la lista de discusión ietf-lac. Esta última iniciativa intenta vencer la barrera idiomática abordando temas de IETF en idiomaS español y portugués. También se marcaron las diferencias entre la realidad de África y Latinoamérica, ya que no todas las iniciativas pueden trasladarse a otras regiones.

Una de las discusiones a tener en cuenta es la que está llevando adelante el WG mtgvenue que está revisando la política que se utilizará para las próximas reuniones de IETF. En este análisis se están teniendo en cuenta los requerimientos, la participación de las regiones y la distribución geográfica de los encuentros.

Ruteo

En la IETF96 no hubo reunión de grupo grow, pero sí se reunieron idr y sidr.

En idr se presentaron actualizaciones de varios drafts,  una propuesta de llevar geo-coordenadas en BGP y una de extender con opciones los mensajes de route-refresh. De particular interés resulta la propuesta “Large BGP Communities” que intenta reemplazar las comunidades definidas por la RFC1997 por comunidades más grandes, que puedan ser utilizadas con ASNs de 32 bits. Se espera que este documento entre en last-call pronto: draft-heitz-idr-large-community-00. Una particular propuesta se presentó sobre incorporar el algoritmo SPF (Shortest Past First – Dijkstra) a BGP  como alternativa al actual algoritmo de selección del mejor camino. Hubo mucha discusión al respecto y no parece que esta propuesta prospere por ahora. Ver draft-keyupate-idr-bgp-spf-00.

En sidr las principales presentaciones estuvieron a cargo de los RIRs: Tim Bruijnzeelshizo una actualización de su propuesta “Validation Reconsidered” que está en camino de ser aceptada por el grupo. También realizó una presentación sobre estadísticas de adopción de RPKI por países, con diversas medidas que permiten obtener conclusiones sobre el estado de despliegue. Ver: https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html

Por otro lado, Carlos Martínez realizó una actualización de “Trust Anchors Applicability statement” que se puede ver aquí: https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-01; trata sobre un cambio propuesto por los RIRs en los TA a fin de minimizar los riesgos operativos.

Uno de los temas en debate tiene que ver con la continuidad de este grupo de trabajo, ya que se considera que ha cumplido con los objetivos definidos en el chárter. Una de las propuestas debatidas fue la posibilidad de continuar con un WG de tipo operativo.

IPv6

En v6ops la principal presentación estuvo relacionada con una propuesta para hacer multihoming con direcciones PA (Provider Assigned) sin realizar traducción (NAT). Cabe mencionar que hoy la forma de hacer multihoming más extendida es utilizar direcciones PI (Provider Independent). Esta propuesta, que pretende dar una solución cuando no se cuente con este tipo de direcciones, se basa en source-address routing y mecanismos para influir la selección de source-address en los hosts. Es un draft que requiere todavía mucho trabajo para ser llevado a la práctica.

Con respecto a 6man, las propuestas giraron en torno a la actualización del mecanismo de asignación de direcciones a fin de no utilizar direcciones basadas en la dirección MAC, cambiando el texto de la RFC4941. Por otro lado, continuó el debate sobre la posibilidad de pasar las especificaciones de IPv6 a estándares, ver presentaciones https://www.ietf.org/proceedings/96/slides/slides-96-6man-3.pdf y https://www.ietf.org/proceedings/96/slides/slides-96-6man-6.pdf

IoT

Hubo mucha actividad de los grupos de Internet of Things en IETF96, ver documento por separado en LACNIC Labs: http://www.labs.lacnic.net/site/IoT-ietf96

Otros temas

Cambios en la zona raíz del DNS

La zona raíz del DNS tendrá dos cambios importantes en los próximos meses: la ampliación de la ZSK y la rotación de la KSK.

Se presentaron los roadmap de cambio en la ZSK de la zona raíz de 1024 a 2048 bits y los planes de contingencia. La clave se ampliaría para Octubre de 2016.

También se dieron a conocer los documentos sobre el rollover de la KSK de la zona raíz que se pueden encontrar en www.icann.org/kskroll. Se espera que la nueva KSK esté operativa en Julio de 2017.

En este sitio se pueden hacer chequeos de que nuestro resolver funcione correctamente con claves de 2048 bits: http://keysizetest.verisignlabs.com

ROA Signing Party

En Berlín se realizó un evento de creación de ROAs inspirado en una actividad similar que se llevó adelante en la IETF95 de Buenos Aires. En esta ocasión estuvieron presentes unos 20 participantes y 3 de ellos pudieron crear sus ROAs. Esto no siempre es posible debido a que no están presentes quienes tienen la autorización sobre los recursos de la organización.

Plenario

Uno de los temas que se mencionó en el plenario fue la excesiva cantidad de estándares que se están aprobando por parte de la IETF, muchas veces incompatibles entre sí. Esto resulta contradictorio con la misión de lograr soluciones interoperables y presenta un riesgo a la tarea futura de IETF.

Como hecho anecdótico, cabe mencionar que en Berlín se optó por mantener el esquema horario de reuniones que se había utilizado en Buenos Aires, empezando a las 10:00 AM y finalizando alrededor de las 19:00hs. Uno de los argumentos a favor de mantener estos horarios es que permite mayor cantidad de actividades por la mañana previas a las reuniones (desayunos de trabajo por ejemplo). La semana de la IETF es importante no sólo por las reuniones formales de los WG, sino por los espacios de encuentro privados y reuniones paralelas. Cómo se vería este cambio de horario en las reuniones de LACNIC y LACNOG en la región?