Resumo

  • draft-liu-sidrops-rpki-rtr-over-quic-04 vende recuperação “0-RTT”, mas suas regras normativas obrigam cliente, servidor e TLS a não usar Early Data.
  • QUIC reduz bloqueio entre streams, porém a conclusão de uma visão RPKI exige versão, Session ID, Serial Number, todos os canais esperados e o último End of Data, não apenas conexão protegida.

A revisão 04 saiu em 7 de setembro de 2026. É Internet-Draft individual com intenção Standards Track, sem adoção de WG, consenso IETF ou RFC. O Datatracker não mostra RFC stream, AD responsável ou telechat. O 8210bis é trabalho do SIDROPS para o protocolo base; seu status não deve ser emprestado ao mapping QUIC individual.

A introdução atribui ao QUIC retomada rápida e transporte multistream. Para um servidor já conhecido, diz que o cliente pode colocar a solicitação RTR no primeiro pacote e obter recuperação “0-RTT”, retomando quase instantaneamente a sincronização. Também afirma eliminar completamente head-of-line blocking.

A seção 3.1 retira a primeira vantagem. Implementações RTRoQUIC MUST NOT usar Early Data. O cliente MUST NOT enviar early_data; o servidor MUST rejeitá-lo; a pilha TLS 1.3 MUST desabilitar 0-RTT. A contradição aparece nas revisões 03 e 04.

RFC 9001 separa session resumption de 0-RTT. A retomada pode continuar disponível sem dados antecipados. O 0-RTT específico permite application data antes do handshake completo usando parâmetros guardados. A solicitação no primeiro pacote pertence a esse caminho, justamente o caminho proibido.

Há uma razão: Early Data tem exposição a replay e propriedades diferentes de forward secrecy. O draft prefere segurança porque a carga alimenta decisões de routing. A escolha pode ser prudente, mas impede usar 0-RTT na justificativa econômica. O benchmark deve medir o fluxo permitido.

O multistream traz outro contrato. No mapping simples, todos os PDUs seguem um stream bidirecional. No alternativo, o Control Channel leva Serial Notify, Serial Query, Reset Query, Cache Reset e Error Report. Data Channels levam Cache Response, payload e End of Data.

Os payloads podem ocupar quatro streams: IPv4 Prefix, IPv6 Prefix, Router Key e ASPA. Uma perda num stream não trava os outros. Ainda assim, três streams terminados não completam a transação se o quarto permanece aberto.

Revision 04 exige Cache Response e End of Data em todos os Data Channels. O primeiro Cache Response é válido; o último End of Data é válido. Logo, o conjunto esperado de streams passa a integrar o estado. Sem conhecer o conjunto, o receptor não identifica “último”.

QUIC preserva ordem dentro de cada stream, não uma ordem total entre eles. Se o roteador cometer os três primeiros canais, poderá criar snapshot parcial. Se esperar o último, precisa saber como criação, associação à consulta, reset, fechamento e erro são representados.

8210bis mostra a autoridade do fechamento. Serial Number é a versão lógica de um cache. Session ID identifica o espaço de sequência. Protocol Version completa a identidade. O cache não envia novos dados antes de validar sua atualização. End of Data autoriza o roteador a considerar recebida a visão corrente daquele cache e avançar seu serial.

Dividir a carga não pode diluir essa atomicidade. Router Key recebida não prova que ASPA e withdrawals da mesma versão chegaram. TLS autentica o endpoint conforme a política configurada, mas não prova que o snapshot é inteiro.

O escopo dos números é local. Serial Number não se compara entre caches ou versões e pode mudar num reset. 8210bis alerta que Session ID reutilizado por engano pode manter o roteador fora de sincronia se o delta não contradisser o estado antigo. QUIC não conserta epoch lógico errado.

Com vários caches preferidos, uma sessão completa é apenas uma parte. Um VRP torna-se efetivo quando o primeiro cache preferido o serve e persiste até o último retirar. É preciso um ledger por cache e outro para a união.

Depois do transporte vêm outros recibos. PDU recebido, payload instalado, rota reavaliada, best path, RIB, FIB e packet outcome são fatos diferentes. Um canal criptografado e rápido não decide nenhum deles.

O fallback também conta. Se UDP estiver bloqueado, o draft recomenda tentar RTR sobre TCP. O monitoramento deve separar falha QUIC, início TCP, autenticação, primeira resposta, último End of Data, instalação e reavaliação. “Connected” não mede a janela sem dados atuais.

Running-Code Primacy exige interoperabilidade observável: duas implementações negociam versão, autenticam os endpoints certos, rejeitam 0-RTT, concordam com os streams, sobrevivem a perda seletiva e fazem um único commit no End of Data final. Setas paralelas não bastam.

O contrato mínimo pode deixar quantidade de streams, política de certificados, preferência de cache e fallback ao operador. Não pode deixar a identidade da transação implícita. Versão, cache, Session ID, Serial Number, consulta, canais e fechamento precisam estar vinculados.

A direção não deve aprovar “QUIC” como rótulo. Deve aprovar uma redução medida com o protocolo permitido, commit sem visão parcial, fallback testado, diversidade de caches e evidência até a consequência no routing.

Fontes