Summary

  • draft-liu-sidrops-rpki-rtr-over-quic-04 says a previously connected router could achieve “0-RTT” recovery, but its normative connection rules require clients and servers to disable and reject Early Data.
  • QUIC can still protect and parallelize transport, yet one complete RPKI cache view depends on Protocol Version, Session ID, Serial Number, declared stream membership and the last expected End of Data—not merely on a fast handshake or one finished stream.

Revision 04 was published on 7 September 2026. It is an individual Internet-Draft whose header says Standards Track. Datatracker gives it no RFC stream, Working Group adoption, responsible Area Director or telechat. That boundary matters. The draft is a current technical proposal named RTRoQUIC, not an IETF decision, implementation inventory, deployment report or performance result.

Its sales pitch is unusually concrete. QUIC integrates TLS 1.3, offers encrypted connection establishment and multiplexes independent streams. For a server contacted before, the introduction says, a client can carry an RTR session request in its first packet and achieve “0-RTT” recovery. It then says routers or caches can resume synchronization with the RPKI verification database “almost instantly”, shrinking a blank interval in routing-security information.

The normative mechanism does not permit that application-data path. Section 3.1 says RTRoQUIC implementations MUST NOT use Early Data. A client MUST NOT put the early_data extension in ClientHello. A server MUST reject it. Implementations MUST configure TLS 1.3 to disable 0-RTT. The same contradiction appears in revisions 03 and 04.

This is not a semantic quibble about two names for resumption. RFC 9001 says TLS session resumption can be used when 0-RTT is disabled. Resumption can save work and still require the handshake boundary before protected application data. QUIC 0-RTT specifically lets a client send application data before that handshake finishes, using parameters remembered from a previous connection. That early-data benefit is the one the draft's introduction invokes and its normative rule removes.

The security reason is also explicit. Early Data does not have the same replay and forward-secrecy properties as ordinary TLS application data. The authors judge RPKI transport too consequential for that trade and prohibit the feature. That may be a defensible decision. But an operator cannot budget restoration time using the prohibited path. A design review must price the protocol that the requirements actually allow, not the latency headline left in the introduction.

The second gap appears when the draft turns one ordered RTR stream into several QUIC streams. In the simple mapping, every PDU can travel on one client-initiated bidirectional stream. Order remains easy to reason about. The optional mapping separates a Control Channel from one or more Data Channels. The control side carries Serial Notify, Serial Query, Reset Query, Cache Reset and Error Report. The data side carries Cache Response, payload records and End of Data.

The payload can be divided into four classes: IPv4 prefixes, IPv6 prefixes, Router Keys and ASPA records. The draft illustrates one stream for each. Packet loss on one QUIC stream no longer blocks bytes on another stream. That is a useful transport property. It does not eliminate the application-level need to know when the cache transaction is whole.

To rebuild that boundary, revision 04 says Cache Response and End of Data must be placed on every Data Channel. The first Cache Response received across the channels counts as valid. The last End of Data received counts as valid. Those two rules turn the set of participating streams into part of the transaction definition. “Last” has no operational meaning unless both sides know which streams belong to this response and when no further stream is expected.

QUIC supplies order inside each stream, not one total order across the connection. Suppose the IPv4, IPv6 and Router Key streams reach End of Data quickly while the ASPA stream is stalled behind loss. Three green stream indicators do not make the view complete. Treating the first End of Data as the commit point would install a mixed snapshot. Waiting for the last expected End of Data can work, but only if channel creation, membership, closure, error handling and session association are unambiguous.

The WG-owned base draft, 8210bis, explains why this completion marker carries authority. A Serial Number denotes the logical version of one cache. A Session ID identifies the sequence-number space. Protocol Version, Session ID and Serial Number together determine whether two values correspond. A cache with new input must not send that data until its validated update is complete. When the router receives End of Data in the ordinary exchange, it may conclude that it has received all current data from that cache and move its current Serial Number to the value in that PDU.

Moving payloads onto four streams cannot casually weaken that atomic meaning. A Router Key arriving before its matching ASPA records may be cryptographically well formed, but the router has not yet received the complete cache transaction. Likewise, a prefix withdrawal on one stream and an announcement on another must be applied under the ordering and transaction rules of the negotiated RTR version, not simply in wall-clock arrival order.

The identifiers are narrower than they look. A Serial Number has no correspondence across caches or protocol versions. It need not survive a cache reset. The base draft warns that erroneous Session ID reuse can leave a router out of sync when the subsequent changes happen not to contradict its stale data. QUIC encryption cannot repair a false cache epoch. A successful handshake proves that the configured transport peer met the authentication policy; it does not prove that the Session ID has been generated safely or that the resulting dataset is current.

Multiple caches add another boundary. In 8210bis, a VRP is effective if it appears in any currently preferred cache. It starts to affect the router when the first preferred cache supplies it and remains until the last withdraws it. Completion of one RTRoQUIC session is therefore not completion of the router's global RPKI view. The operator still needs a cache-by-cache ledger and an explicit rule for combining them.

The same separation applies downstream. RPKI-to-Router delivers validated payload data. Receiving an IPv4 Prefix PDU is not the same as reevaluating every affected BGP route. A locally installed VRP is not proof that a particular route became Valid, Invalid or NotFound. A routing-policy decision is not proof that the selected RIB changed. A RIB change is not proof of FIB programming or packet delivery. Transport speed can reduce one interval without becoming authority over all later stages.

Fallback is part of the actual proposal. If UDP blocking prevents the QUIC connection, revision 04 says the router should attempt a TCP-based RTR session. That choice protects continuity, but it complicates measurement. A dashboard that labels both paths “RTR connected” can hide whether QUIC succeeded, whether TCP fallback was used, how long the handshake took, and whether the data transaction completed. A real latency claim needs all four timestamps.

Running-Code Primacy offers the correct test. The proposal should be judged by the narrow receipts its executable mechanism can produce. Can two independent implementations negotiate the same RTR version, authenticate the intended endpoints, agree on the data-channel set, reject 0-RTT as required, survive loss on one stream, identify the last expected End of Data and commit exactly one cache version? That is more important than whether a diagram contains four parallel arrows.

The minimum interoperable contract should not absorb every local optimization. Operators may choose stream count, certificate policy, cache preference, retry timing and TCP fallback. But transaction identity cannot be local folklore. The mapping needs a testable answer for how one query binds to every Data Channel, how duplicate Cache Responses are checked, how conflicting End of Data fields are handled, what happens when a stream resets, and which evidence authorizes the router to advance its cache Serial Number.

Until that answer is demonstrated, “head-of-line blocking eliminated” is too broad. QUIC prevents loss on one stream from blocking delivery on another. The application can still wait for the slowest required stream, run out of stream credit, lose a connection, reject a version, reset on corrupt data or delay local installation. Parallel delivery changes the shape of the wait; it does not abolish the commit barrier.

The leadership question is therefore not “QUIC or TCP?” It is “which receipt closes the stale-view interval?” A fast protected connection is valuable. So is independent stream progress. Neither is the final fact. The final fact is a router that can name the cache, protocol version, session, serial, complete participating channel set and committed payload—and then show what routing policy did with it.

Sources