Summary

  • RFC 5128 describes deployed peer-to-peer NAT traversal techniques; its Informational status and text do not endorse a particular implementation.
  • A rendezvous service may distribute private and public endpoint claims but cannot validate a registrant's claimed private address from the public registration exchange alone.
  • The same private address can designate different hosts in different homes, offices or downstream NAT realms.
  • A traversal probe aimed at a peer's private-address claim can therefore reach an unrelated machine on the sender's local network, even without malicious intent.
  • A malicious registrant can name a victim address and cause many peers to direct connection attempts toward it.
  • Applications should limit packets, bytes, retries, fan-out, processing and stored state before authenticated two-way communication succeeds.
  • A responsive endpoint proves that something answered on a path; it does not prove the expected person, account, organization or entitlement.
  • Source-IP authentication is insufficient for NAT-friendly signaling because address rewriting is part of the mechanism and an on-path party can try to substitute an address.
  • Higher-level identity and authenticated application content must bind the peer to the selected path; encryption may protect content while traffic analysis can remain possible.
  • Endpoint-independent mapping and endpoint-independent filtering are different properties: reusable mappings do not imply an open inbound policy.
  • ICE connectivity checks and TURN relay allocations provide later path machinery, not a universal receipt for user identity, authorization or application outcome.
  • Leaders should preserve separate receipts for registration, discovery, probe budget, path creation, peer authentication, authorization, resource commitment and delivered outcome.

The address was valid syntax and wrong reality

Suppose a participant tells a rendezvous server that it can be reached at 192.168.1.100. The server can authenticate the participant's account and store the string exactly. It may also observe a public source tuple created by a NAT. Neither fact lets the server look inside every peer's private network and determine which machine 192.168.1.100 names there.

The address is not globally unique. In one home it may be the participant's laptop. In another it may be a printer, camera, storage appliance or an entirely unrelated workstation. If the rendezvous response gives both private and public endpoints, a peer can try the private one because it appears to offer a short path. The packet then enters the peer's own address realm. Its destination is resolved by that realm, not by the registrant's intention.

RFC 5128 treats this as more than a configuration nuisance. Overlapping private address spaces create an identity ambiguity. The wrong local machine may answer, remain silent, log the attempt or process enough of the protocol to consume resources. No attacker is required: two ordinary networks can reuse the same address. Malice changes the scale and choice of target, not the underlying ambiguity.

This is a useful reality-layer test. Registration proves that a value was declared. Discovery proves that the value was disclosed. Routing and NAT behavior determine where a packet actually went. An authenticated application exchange proves which higher-level peer possessed the required credential. The application result proves whether useful work happened. Combining those receipts into the word “connected” destroys the information needed to govern the system.

Rendezvous distributes claims; it does not consecrate them

A rendezvous service is valuable because peers otherwise do not know the translated endpoints created by their NATs. It can observe a public tuple, associate candidates with a session and help both sides begin traversal. That coordination role is narrow and operationally powerful.

Narrow coordination becomes dangerous when its output is treated as authority. A signed response from the service may prove that the service emitted a candidate set for a session. It does not prove that every candidate belongs to the claimed peer, that every private candidate has the same meaning in the recipient's address realm, or that the eventual responder holds the account identity used at registration.

RFC 5128 therefore advises applications to regard newly learned addresses as suspect until authenticated two-way communication has taken place. The exact authentication protocol belongs to the application. The boundary does not: before the peer has been authenticated, an endpoint is a destination to test under a strict budget, not an entitlement to trigger expensive work.

The server should retain provenance for each candidate. Was it asserted by the participant, observed as a source tuple, learned reflexively during a check, allocated by a relay or derived from local interfaces? Those paths have different evidentiary value. Provenance does not make a candidate safe by itself, but without provenance an investigator cannot reconstruct why the system trusted or prioritized it.

The pre-authentication budget is a security control

Traversal requires sending something before a path is known. The security question is not whether all pre-authentication traffic can be eliminated. It is how much an unverified claim can cause other parties to send, compute, reserve or remember.

RFC 5128 warns applications to minimize the size and rate of traffic directed to a newly discovered address. A malicious registrant can supply a victim's address, and a popular or repeatedly discovered registration can concentrate many peers' connection attempts on that victim. The attacker does not have to originate every packet. The coordination system recruits peers to do so.

Bytes are only one budget. Each probe may create a timer, retransmission schedule, candidate-pair record, cryptographic context, log entry, queue item or relay decision. A small wire message can be coupled to substantial server or client work. Rate limiting only outbound packets while leaving unbounded stored state does not close the resource path.

A defensible control records at least the number of candidate destinations, packet and byte ceiling, retry cadence, expiration time, concurrent state and processing allowance before authentication. It also prevents one account, one rendezvous object or one target prefix from multiplying the aggregate beyond the intended bound. Per-session compliance is not enough if thousands of sessions can name the same victim.

After peer authentication, authorization remains separate. A verified peer may be allowed to exchange a small control message but not allocate a high-bandwidth relay, request a large object or start a costly computation. Identity answers who participated; authorization answers what that identity may cause; the resource receipt records what the system actually committed.

A reply is path evidence, not person evidence

Wrong-host delivery is especially treacherous when the unintended device responds. Operators may be tempted to promote responsiveness into success: a socket opened, a STUN transaction completed or a connectivity check returned. Those are observations about a protocol exchange over a path.

They do not automatically establish the human or organizational identity expected by the application. Even credentialed checks have a defined scope. An ICE check can show that the remote party possesses the short-term credentials used for that ICE session and that a candidate pair works under the protocol. The application still needs to bind that transport result to its higher-level peer identity and its authorization decision.

The binding must survive path change deliberately. A later nomination, mobility event, NAT rebinding or move from a direct candidate to a relay changes the transport path. The application protocol should specify whether the existing authenticated session remains valid, requires channel binding, or must be reauthenticated. A dashboard that keeps showing the original green identity beside a new path without recording this decision creates symbolic continuity rather than operational proof.

TURN demonstrates the same boundary from the other direction. A relay can be the most controlled and reliable path when direct traversal fails. An authenticated TURN allocation proves a relationship between the client and the relay service under TURN's rules. It does not by itself identify the far-end application peer or prove that useful application data arrived. Relay is not a synonym for weak trust, and direct is not a synonym for strong trust.

NAT behavior is not one personality type

RFC 5128 explains why hole punching depends on particular NAT behavior. Endpoint-independent mapping allows an internal endpoint's mapping to be reused when it sends to different remote destinations. Endpoint-dependent mapping may create a different external tuple for each destination and defeat that assumption.

Mapping is not filtering. A NAT can reuse one mapping across destinations while accepting return traffic only from an endpoint to which the internal host previously sent. Calling such a device “open” because its mapping is endpoint-independent confuses address allocation with inbound permission. RFC 4787's separate vocabulary matters because the two properties produce different paths and different attack surfaces.

Hairpinning is another independent fact. Two peers can sit behind different downstream NATs while sharing a larger upstream NAT. They may learn the upstream public endpoints and attempt to reach each other through them. Without hairpin support at the shared NAT, packets may not loop back into the internal side. The public candidates can be syntactically correct, the mappings can exist, and the direct path can still fail.

Connection reversal covers only the topology in which one endpoint is public and the other is behind a NAT. Relaying works whenever both clients can reach the relay, at the cost of relay processing, bandwidth and often extra latency. Hole punching may reduce those costs, but only when the relevant mapping, filtering, timing and topology conditions hold. An implementation needs failure reasons, not a single “NAT traversal failed” counter.

Endpoint-independent mappings can also make relationships among sessions more predictable. RFC 5128 identifies a possible information channel; it does not measure a universal exploit or establish a current incidence rate. The responsible conclusion is to keep session-linkability and address predictability in the threat model, then measure the particular implementation rather than announce a population-wide result.

Address rewriting defeats source-IP certainty

NAT-friendly signaling necessarily tolerates changes between the address a participant believes it has and the address another party observes. That tolerance creates room for an on-path actor to substitute a source address or attempt to register a modified one, steering later traffic through itself.

Authenticating only the source IP address cannot solve this cleanly. The protocol was designed precisely because source and destination tuples can be rewritten. Treating the rewritten tuple as the identity would give the path mechanism the authority the application needs to retain.

RFC 5128 points toward authentication of the actual application content under a higher-level identity, with encryption where confidentiality is required. The content exchange should bind the identities, session and relevant transport context so that a substituted path cannot silently become a substituted peer. Encryption can prevent an intermediary from reading or modifying protected content, but observable packet timing and volume may still reveal relationships.

This layered defense is compatible with narrow infrastructure roles. The rendezvous service need not become a global identity oracle. It must make the limits of its observation explicit, protect registrations under its own authorization model, preserve candidate provenance and keep amplification bounded. The application owns peer identity and the decision to release meaningful resources.

Later protocols improve machinery, not the category boundary

RFC 5389 refocused STUN as a protocol utility rather than a method for classifying a NAT into a durable personality. RFC 8445's ICE procedures gather candidates, form pairs, perform connectivity checks and nominate a selected pair. RFC 8656 specifies TURN allocations, permissions, channels, authentication and expiry. RFC 8835 places ICE, STUN and TURN in the WebRTC transport stack.

These developments make traversal more explicit and interoperable. They do not collapse the evidence ladder. A host candidate is not a server-reflexive candidate. A candidate pair is not yet a working pair. A successful check is not necessarily the final nominated path. A nominated path is not the application peer's durable identity. A relay permission is not an authorization for arbitrary application work. Media packets on a path do not by themselves prove the intended business outcome.

The distinction also prevents a misleading hierarchy. A direct route can reach the wrong local host. A relay route can be correctly authenticated, bounded and observable. Leaders should compare paths by verified identity, policy, cost, latency, resilience and outcome—not by an aesthetic preference for fewer intermediaries.

What this record proves

The RFC Editor and Datatracker records establish the publication and lifecycle of RFC 5128. The document describes techniques in use at its publication and explicitly avoids endorsing them. The surrounding RFCs establish terminology and later protocol evolution for NAT behavior, STUN, ICE, TURN, UDP usage and WebRTC transport.

The record does not establish how often a current product accepts arbitrary private candidates, how many networks provide hairpinning, how often a wrong host answers, the amplification factor of a named service, or the success rate of direct versus relayed paths. It contains no present vendor census, incident trace or measured user result. Those claims require implementation evidence.

That limit is not a weakness in the analysis. It locates the decision correctly. Standards define mechanisms and anticipated risks. Running systems must supply configuration, telemetry, authenticated transcripts, resource ledgers and outcomes. Leadership fails when a standards citation is used to fill an empty operational cell.

Sources