Summary

  • In MPTCP, an MP_JOIN SYN carries the receiver's Token to locate existing MPTCP state, but the later HMAC exchange and the receiver's own policy decide whether a new TCP subflow may join it.
  • A token match, a valid HMAC, a TCP handshake and an application result are separate records. None can honestly impersonate all the others.

The second SYN is deliberately modest. It does not announce a new application session, nor does it ask the network to discover a mystical end-to-end path. It proposes a new ordinary TCP subflow between one address pair and asks that subflow to become one strand of an existing MPTCP connection. The proposal has to answer four different questions: which old connection is meant; whether the proposer is continuous with its original peer; whether this host wishes to accept another strand; and how packets on the newly established TCP flow will be demultiplexed afterward.

RFC 6182, the 2011 architectural account, made the split intelligible before the wire format arrived. The application was to keep seeing TCP's reliable, ordered byte stream. The network, by contrast, was to see ordinary-looking TCP subflows. Multiple addresses were a practical way to seek path diversity, not a warranty that the paths were physically disjoint. Compatibility mattered as much as ambition: MPTCP had to coexist with ordinary TCP, middleboxes and single-path traffic at shared bottlenecks.

That framing matters because it places the innovation in an accountable seam. MPTCP did not abolish TCP state. It added a connection-level record above several TCP records, then had to explain how a fresh five-tuple could be attached to that older record without allowing any packet that knew a convenient label to do the attaching.

The first handshake creates a history

The history begins on one normal TCP path. In RFC 8684, the first subflow carries MP_CAPABLE in the SYN, SYN/ACK and ACK. That negotiation says the two endpoints can use the specified MPTCP version on this connection and exchanges the key material from which later-subflow authentication is derived. If the necessary option is absent—perhaps because a peer does not support MPTCP or a middlebox removed it—the specified outcome is regular single-path TCP, not a half-recognised multipath connection.

This fallback rule is not a footnote. A TCP option observed on one attempt is not proof that every path will preserve it, and a host's desire to use several paths is not an instruction the rest of the Internet must obey. The initial exchange establishes a bounded protocol relationship on the first subflow. It does not establish a user's identity, an application's permission, the ownership of either IP address, or the future quality of another path.

The older RFC 6824 recorded this design as Experimental in January 2013. It was published for implementation and evaluation, not as an Internet Standard. RFC 8041 later collected dated operational experience, including middlebox and subflow-management lessons. RFC 8684, published on the Standards Track in 2020, obsoleted that v0 specification and says its v1 clarifications and modifications were driven primarily by deployment experience. That sequence supports a narrow historical statement: implementation experience altered a protocol record. It does not licence a claim about present deployment share, a particular vendor's configuration, or universal benefit.

A token is an index, not a permission slip

Once the initial connection exists, a host may try to add a subflow. The first MP_JOIN SYN contains the token of the host receiving it, a fresh random nonce from the sender, and an Address ID. With the v1 SHA-256 selection, the receiver's token is the most significant 32 bits of the SHA-256 hash of that receiver's initial key. It is compact because its immediate task is compact: it lets the receiver find which local MPTCP connection the SYN says it is joining.

That is demultiplexing. It is not a title deed.

The receiver maps token to connection state and, through that state, to the keys. RFC 8684 is explicit that a token is used for demultiplexing a subflow SYN; after a subflow is set up, ordinary TCP five-tuples demultiplex its packets. The protocol therefore changes the selector with time. At admission time, the new SYN cannot yet be distinguished by a pre-existing subflow five-tuple, so it presents the receiver's token. After admission, packets belong to the newly created TCP flow by its conventional source address, destination address, source port, destination port and protocol context.

The Address ID solves a different bookkeeping problem. It is chosen by the sender to identify a source address even when a NAT has changed the IP header seen at the other side. That makes address removal and correlation possible without pretending that the peer has a stable view of the wire address. An Address ID is neither a routable address nor evidence that the sender owns, controls or is authorised to use an address outside this connection's protocol state.

A 32-bit token also cannot do the whole security job. A collision-resistant lookup handle at this size helps the receiver choose state and limits blind state-exhaustion exposure in the specified design; it is not presented as a human secret or an application bearer credential. The protocol refuses to convert a useful index into a universal claim.

The keys must speak again

MP_JOIN adds the proof that lookup lacks. The receiver replies with its own fresh nonce and a truncated HMAC. The initiator answers with its HMAC. The HMAC inputs use the keys exchanged during MP_CAPABLE and the two fresh nonces. The nonces make a recorded prior exchange insufficient as a replay of this particular join attempt.

The consequence is carefully scoped. When the HMACs verify, RFC 8684 says both hosts have verified that they are the same MPTCP peers that existed at the start of the connection and have agreed which MPTCP connection the subflow will join. That is peer continuity within this transport construction. It is valuable precisely because it is smaller than the claims people often attach to words such as authentication.

It does not identify a human user. It does not attest to a company, establish a contract, authorize a request carried later in the byte stream, or prove that an application transaction committed. It does not prove that two address pairs provide independent physical routes. It says that the party completing this particular join possesses the connection material required by the protocol and that the two ends agree on the connection record being extended.

The negative cases keep the distinction honest. If the receiver does not know the token, it resets the attempted subflow. If the receiver knows it but local policy prohibits a new subflow, it also resets the attempt. If an expected HMAC is absent or wrong, the relevant endpoint closes the subflow. A matching token therefore precedes admission; it does not compel it. A correct cryptographic response precedes continued use; it does not decide what the application may do.

A new five-tuple has a local sponsor

This local refusal point is the part most easily lost in an architecture diagram. A diagram may show Address A2 reaching Address B1 and label the line “additional path.” RFC 8684 is stricter. The SYN proposes a TCP subflow; the receiver selects its own MPTCP state, checks the required proof, and retains a policy decision over whether that state will accept one more subflow. Only then does the new five-tuple become one of the TCP flows managed by the shared MPTCP connection.

The model preserves a useful asymmetry. The sender can offer an address, a token and evidence tied to earlier connection keys. The receiver controls its state table, resource limits and admission policy. Neither address publication nor packet arrival silently transfers that control. This is the ordinary discipline of a durable system: discovery points to a place; proof binds a claim to prior state; the operating endpoint still decides whether the new work belongs there.

It also explains why no single trace settles the fate of an application operation. A capture might show MP_CAPABLE, a token-bearing MP_JOIN, completed HMACs and a healthy TCP subflow. Those are strong transport facts. They do not show that a request was accepted by an application, that a database committed it, that a remote service had authority to perform it, or that a user received its effect. The byte stream may be continuous while meaning remains deliberately outside the transport's jurisdiction.

Sources and limits of the record

The RFC record establishes the architecture and defined protocol behaviour described here: the experimental status of RFC 6824, the dated experience collected in RFC 8041, and the normative v1 procedures in RFC 8684. It does not establish current prevalence, real-world route separation, middlebox behaviour on a named network, product conformance, performance outcomes, user identity or application results.