Resumen

  • draft-liu-sidrops-rpki-rtr-over-quic-04 presenta recuperación «0-RTT», pero obliga a desactivar Early Data en cliente, servidor y configuración TLS.
  • Separar IPv4, IPv6, Router Key y ASPA entre streams evita un bloqueo de transporte, no demuestra por sí solo que el router recibió y comprometió una vista RPKI completa.

La revisión 04 se publicó el 7 de septiembre de 2026. Es un Internet-Draft individual con intención Standards Track, no un texto adoptado por SIDROPS, consenso del IETF ni RFC. Datatracker no registra stream RFC, AD responsable o telechat. El borrador de grupo 8210bis define el protocolo base; esa autoridad de proceso no convierte automáticamente su mapping QUIC en trabajo aprobado.

La introducción atribuye a QUIC dos ventajas. La primera es el establecimiento rápido: un cliente que ya habló con el servidor podría incluir la petición RTR en el primer paquete y alcanzar recuperación «0-RTT». La segunda es el paralelismo: una pérdida en un stream no detiene los bytes de los demás. De ahí salta a una sincronización casi instantánea y a la eliminación completa del head-of-line blocking.

La sección de establecimiento impone otra realidad. Las implementaciones RTRoQUIC MUST NOT utilizar Early Data. El cliente MUST NOT ofrecer early_data; el servidor MUST rechazarlo; la pila TLS 1.3 MUST desactivar 0-RTT. La contradicción apareció en la revisión 03 y continúa intacta en la 04.

RFC 9001 permite reanudar una sesión aun cuando 0-RTT está deshabilitado. Por eso no basta con renombrar la ventaja. La reanudación puede ahorrar negociación, mientras que 0-RTT significa enviar datos de aplicación antes de completar el handshake con estado recordado. La petición RTR del primer paquete pertenece a esa segunda categoría, precisamente la prohibida.

El motivo es el replay. Early Data no aporta las mismas garantías que el tráfico ordinario, y el borrador considera demasiado sensible la información que alimenta validación de rutas. La prudencia puede ser correcta. Lo que no es correcto es presupuestar una recuperación operativa con una característica que el contrato normativo ordena apagar. Las cifras deberán medir 1-RTT permitido, no 0-RTT imaginado.

El diseño multistream presenta una tensión distinta. En modo sencillo, todos los PDU caben en un stream bidireccional. En modo paralelo, stream 0 actúa como Control Channel para Serial Notify, Serial Query, Reset Query, Cache Reset y Error Report. Uno o más Data Channels llevan Cache Response, payload y End of Data.

Los payload pueden dividirse por IPv4 Prefix, IPv6 Prefix, Router Key y ASPA. Cada stream mantiene su orden. QUIC no crea, sin embargo, una secuencia total entre los cuatro. La llegada temprana de claves no ordena los cambios de prefijos que aún vuelan por otro canal.

Para recuperar un límite de transacción, la revisión 04 manda enviar Cache Response y End of Data a todos los Data Channels. El primer Cache Response cuenta; el último End of Data cuenta. Por tanto, el conjunto de canales esperados pasa a ser información crítica. Sin saber cuántos pertenecen a esta respuesta, «último» no es un estado observable.

Una implementación necesita resolver más que el diagrama: cómo se vincula cada stream a la consulta; qué ocurre si dos Cache Response discrepan; qué Session ID y Serial Number deben repetirse; cómo se trata un reset de stream; y si la ausencia de un End of Data invalida toda la transacción o activa el modo de un solo stream. Las respuestas locales incompatibles destruirían el beneficio de interoperabilidad.

8210bis da a End of Data un significado preciso. Serial Number representa la versión lógica de un caché. Session ID nombra su espacio de secuencias. Protocol Version completa la identidad. El caché no puede emitir datos de una actualización todavía incompleta. Cuando llega End of Data, el router puede considerar recibidos todos los datos actuales de ese caché y avanzar su serial local.

Ese commit no debe fragmentarse. Tres End of Data no prueban que el cuarto ya exista. Tampoco un Router Key válido demuestra que los ASPA correspondientes o los retiros de prefijos de la misma versión están presentes. La protección TLS autentica el canal conforme a la política configurada, no la completitud del snapshot.

Los identificadores tienen alcance limitado. Un Serial Number no se compara entre cachés ni versiones y puede reiniciarse. El borrador base advierte que reutilizar por error un Session ID puede dejar al router fuera de sincronía si el delta posterior no contradice el estado viejo. Cambiar TCP por QUIC no corrige esa colisión lógica.

Varios cachés complican aún más el recibo. Un VRP servido por cualquiera de los cachés preferidos se vuelve efectivo y permanece hasta que el último lo retira. Terminar la sesión con uno no termina la vista conjunta. El operador debe conservar un ledger por caché y otro para el resultado agregado.

Después vienen decisiones que el transporte no posee. PDU recibido no significa payload instalado. Payload instalado no significa rutas BGP reevaluadas. Reevaluación no significa mejor ruta cambiada. RIB no significa FIB, y FIB no significa entrega. Una sesión cifrada puede estar sana mientras su serial está obsoleto.

La continuidad propuesta incluye fallback. Si UDP está bloqueado, el router debería intentar RTR sobre TCP. Para medir la ventana real hay que registrar el fallo QUIC, el inicio TCP, la autenticación, la primera respuesta, el último End of Data y el commit. «Connected» es un indicador demasiado pobre.

Running-Code Primacy exige una prueba reproducible: dos implementaciones negocian la misma versión, rechazan Early Data, identifican el mismo conjunto de streams, soportan pérdida selectiva, esperan el End of Data realmente final y producen una sola versión instalada. El rendimiento solo puede evaluarse después de cerrar esa semántica.

El mínimo inicial debe ser estrecho. La cantidad de streams, la política de certificados, la selección de caché y el fallback pueden seguir siendo elecciones operativas. El recibo de transacción —versión, caché, Session ID, Serial Number, consulta, canales y cierre— debe ser común.

Por eso la decisión ejecutiva no es una votación sobre QUIC. Es una exigencia de evidencia. La migración merece aprobación si reduce el tiempo medido sin debilitar la atomicidad, conserva una ruta TCP probada y permite demostrar qué versión completa llegó, cuándo se instaló y qué rutas cambió.

Fuentes