Summary

  • RFC 9897 is an IETF Standards Track extension that lets one DCCP connection establish and use multiple subflows across different paths.
  • MP_ADDADDR advertises an address as authenticated soft state. It does not establish reachability, and it may be discarded.
  • A later subflow uses MP_JOIN after the first subflow was established with MP_KEY. The join carries the peer connection identifier, a sender-generated Address ID and a fresh 32-bit nonce; the exchange then proves reachability at the advertised address.
  • MP_HMAC protects MP_JOIN, MP_ADDADDR and MP_REMOVEADDR with HMAC-SHA256 truncated to the leftmost 160 bits. Each protected option requires its own immediately following MP_HMAC.

The admission boundary

The first subflow establishes the cryptographic context with MP_KEY. The connection identifier carried into a later MP_JOIN provides continuity with that original connection; it is not a substitute for the join exchange. The joining peer also supplies a fresh, single-use 32-bit nonce. Randomness should meet the security guidance in RFC 4086, because nonce reuse weakens replay resistance.

An Address ID must uniquely map to the sender’s source address within the connection. It lets the receiver correlate MP_JOIN with MP_ADDADDR, and it survives address rewriting by middleboxes. An ID cannot be reassigned while either endpoint still uses it. This is useful NAT correlation, but it is not proof that the address is benign, globally reachable or owned by the peer.

The receiver should therefore separate three states: advertised, cryptographically acceptable control information; join attempted; and path admitted after the reachability exchange succeeds. A valid HMAC authenticates the relevant option under the connection’s keying context. It does not encrypt application data or provide complete end-to-end security. Applications needing confidentiality, integrity, authentication or access control need an end-to-end protection such as IPsec or DTLS, according to their own requirements.

Failure behavior is deliberately asymmetric. An invalid HMAC on MP_ADDADDR or MP_REMOVEADDR is silently ignored. An invalid MP_JOIN closes the attempted subflow. MP_ADDADDR is soft state: broadcast and multicast addresses must be ignored, and a failed address/port combination should not trigger repeated connection attempts unless the advertisement is refreshed. The specification does not turn that guidance into a universal retry timer or budget.

Private addresses create a distinct misdirection risk. A malicious participant can induce handshake traffic toward other hosts by advertising private addresses. Sender- and receiver-side heuristics can reduce denial-of-service impact, but RFC 9897 does not prescribe one heuristic, telemetry threshold or rejection algorithm. Nor does it define a universal scheduler, coupled congestion-control method or reordering method for concurrent multipath use on the general Internet; those topics are outside its scope.

Verification fixtures

  1. Capture the first MP_KEY exchange and record the connection identifier; verify that a later MP_JOIN carries that identifier rather than creating an unrelated association.
  2. For each advertised address, record Address ID, source address before and after NAT rewriting, and lifecycle state. Reject an ID reuse while either endpoint still uses it.
  3. Generate a fresh 32-bit nonce for each join and test that replaying the same nonce does not count as a new reachability proof.
  4. Inspect bytes on the wire: every protected option must be followed immediately by its own MP_HMAC; verify HMAC-SHA256 and leftmost-160-bit truncation.
  5. Inject an invalid MP_HMAC separately into MP_ADDADDR, MP_REMOVEADDR and MP_JOIN; confirm silent ignore for the first two and closure of the attempted subflow for the third.
  6. Test broadcast, multicast and private-address advertisements without treating successful authentication as proof of benign ownership.

Operator decision path

First confirm identity continuity through MP_KEY and the connection identifier. Then validate Address ID uniqueness and NAT correlation. Next check nonce freshness, exact HMAC adjacency and the option-specific failure result. Admit traffic only after the MP_JOIN reachability exchange completes. Keep an advertised path in soft state otherwise; refresh rather than blindly retrying a failed address/port combination. Apply local heuristics to suspicious private-address behavior, document the choice, and use IPsec or DTLS where the application needs stronger end-to-end properties.

The RFC does not report deployment prevalence, performance gains or incident rates. It also does not specify a universal retry budget, scheduler, telemetry threshold or suspicious-address heuristic. Key Type 0 is required for interoperability testing but exchanges key material in plain text; stronger-security deployments must make their own key-type and end-to-end protection decisions.

Sources