Summary

  • draft-ietf-quic-address-discovery-01 lets a QUIC peer report the source IP address and port it observed for each path, but the draft explicitly warns that a peer cannot generally be trusted to report the correct address.
  • Leaders should separate connection-authenticated testimony, per-connection ordering, independent corroboration, path validation and service outcome before allowing an observation to change routing, exposure or security policy.

The operations console received a protected QUIC frame. It came from the expected peer, inside the expected connection, on the expected path. Its sequence number was newer than the previous report. The console therefore displayed the enclosed address as “verified.”

Only the messenger had been verified.

The address could be accurate. It could also be an honest observation made from a different network boundary, a transient NAT mapping, a load-balancer view, stale operational context or an intentional lie from the authenticated peer. Encryption answers who carried the statement and whether the statement was altered on the way. It does not turn the statement into a measurement made by an independent authority.

That narrow distinction is the value of revision 01 of QUIC Address Discovery. The active QUIC Working Group Internet-Draft, dated 15 August 2026, proposes a useful mechanism for carrying a reflexive address inside QUIC. It is not an RFC, a deployment report, an interoperability result or evidence of adoption. Its security section also refuses to pretend that a protected channel makes the reporter truthful.

An endpoint does not see itself from outside

A local application knows the address and port of its socket. That is not necessarily the transport address seen beyond a NAT, carrier gateway, load balancer or policy boundary. STUN has long addressed this gap by asking a remote server to report the source address it observed. The new draft moves the observation into QUIC itself.

The advantages are practical. QUIC already uses TLS 1.3 protection, so the observation can remain inside the encrypted connection. It does not expose the characteristic STUN packet format to passive observers. A deployment routing packets by QUIC connection ID may avoid separate STUN handling. If STUN multiplexing is no longer needed, the QUIC bit can be greased more freely.

None of these advantages changes the epistemic object. The peer reports what it claims to have seen. The requester learns a reflexive transport address relative to that peer and path. It does not learn a globally canonical identity for itself.

Direction is negotiated before an address is reported

The draft defines an address_discovery transport parameter. Value zero means the endpoint is willing to provide observations but does not want to receive them. Value one reverses those choices. Value two permits both. An understood value outside that set causes a transport-parameter error.

This is a disciplined consent and capability exchange. A peer that did not request observations must not receive an OBSERVED_ADDRESS frame and closes the connection for a protocol violation if one arrives. A responder that cannot safely observe the reflexive address, or would reveal internal-network detail by trying, should not offer the service.

Yet negotiation proves only that the endpoints agreed to exchange the frame. “Willing to provide” is not “authoritative for topology.” “Interested in receiving” is not consent to publish the address, make it a firewall rule or advertise it to third parties.

The distinction becomes sharper with 0-RTT. Endpoints remember the transport-parameter value, and a server that accepts 0-RTT cannot disable the extension or change its value on the resumed connection. That preserves the conditions under which early data was sent. It does not preserve the truth of a prior address observation. Capability state can be resumable while network state has already changed.

The sequence orders claims, not reality

OBSERVED_ADDRESS carries an IPv4 or IPv6 address, a port and a monotonically increasing sequence number. Reports can arrive out of order. For the same path, a receiver should ignore a frame when it has already accepted one with an equal or higher sequence.

That rule solves a transport problem: an older retransmission should not overwrite a newer report. It does not create a clock. Sequence 18 says that the peer emitted it after sequence 17 within this connection. It does not say when the external mapping changed, how long it will remain valid, whether the peer missed an intermediate change, or how its observation compares with a report from another connection.

The frame is probing and acknowledgement-eliciting. If it is lost, it should be retransmitted on the same path. A provider sends one on every new path, including the handshake path, and can send another when it detects a changed remote address. These rules give the observation useful path context. They still do not make it a path-validation response.

QUIC path validation uses unpredictable PATH_CHALLENGE data and a corresponding PATH_RESPONSE on the tested path. Even that proves reachability only under the tested conditions. An address report is weaker: it names what the peer says it observed. Receiving the report does not prove that some other endpoint can reach that address, that inbound traffic will survive a filter, or that an application is listening there.

Three honest peers can disagree

An endpoint can be visible through different mappings to different destinations. NAT behavior, address family, routing, anycast, load balancing and policy can make multiple observations simultaneously honest. A mobile transition can also make a report true for only a short interval.

The draft suggests comparing reports from multiple untrusted peers when trusted peers are unavailable, while leaving validation logic out of scope. Agreement can raise confidence, but only if the witnesses are sufficiently independent. Three peers behind the same front door, using the same implementation and route, are not three independent measurements. Disagreement is not automatically corruption; it may be the first evidence that the address is observer-relative.

Store the set rather than crushing it into one field. Each record needs the reporting peer, connection and path, address family, IP and port, sequence number, local receive time, trust class and corroboration set. If the system chooses a preferred interpretation, it should retain the alternatives and the rule that selected one.

A changed address is a symptom, not a cause

The draft says a changed remote address could indicate NAT rebinding. The modal verb carries operational discipline. A change can also follow migration, a load-balancer decision, interface movement, path manipulation or a faulty report.

Worse, an on-path attacker can capture requester packets and resend them from spoofed source addresses. That can induce many OBSERVED_ADDRESS frames and spurious rebinding signals. Sending a report only on the path where the address was observed means the genuine requester will not receive a frame sent toward an invalid spoofed address. But the responder may still emit traffic and its state machine may still see apparent changes. Rate limiting and QUIC's protections against spurious rebinding therefore remain necessary.

A monitoring system that turns every changed address into “NAT rebinding confirmed” has deleted the uncertainty that the specification preserved. It should record an address-change observation, then test competing explanations.

Discovery, reachability and permission are separate

ICE does not stop after gathering an address candidate. It performs connectivity checks. Consent freshness separately tests whether a peer continues to consent to receiving traffic. Those mechanisms are adjacent reminders that an address, a working path and continuing authority are different facts.

The same separation should govern automation. A new observation may safely trigger a reversible probe. It should not by itself publish a public endpoint, replace an allowlist, fail over production traffic, infer the absence of NAT or declare a security incident. The higher the impact, the more independent evidence the action requires.

The useful operational claim is narrow: this authenticated QUIC peer, on this connection and path, reported this address and port with this sequence number; these other witnesses agreed or disagreed; this independent probe then produced this reachability result; and this service outcome followed. Any shorter statement may be convenient, but it spends evidence the protocol did not provide.

Sources and limits

The source set includes revision 01 and its Datatracker history, the QUIC Working Group repository, RFC 8489 on STUN, RFCs 9000–9002 on QUIC, RFC 9287 on QUIC-bit greasing, RFC 4787 on NAT behavior, RFC 8445 on ICE, RFC 7675 on consent freshness and RFC 8085 on UDP usage. These sources define mechanisms and limits. They do not establish implementation share, interoperability, current deployment, performance or the honesty of any operational peer.

Sources