要約

  • MP_JOIN の SYN にある受信側 Token は既存の MPTCP 接続状態を探すためのものだ。追加サブフローを受け入れるかは、nonce、HMAC、そして受信側のローカル方針で別に決まる。
  • Token の一致、HMAC の検証、TCP の確立、アプリケーションの完了は、それぞれ別の記録である。

RFC 6182 は、アプリケーションには TCP と同じ順序付き信頼性バイト列を見せ、ネットワークには複数の通常 TCP サブフローを見せるという二重の見取り図を示した。複数アドレスは経路候補を探す実用的な手掛かりであって、物理的に独立した経路の証明ではない。既存 TCP、中間装置、共有ボトルネック上の他の利用者と共存することも、設計の条件だった。

だから追加の SYN は古い接続を当然に引き継がない。最初のサブフローは MP_CAPABLE を SYN、SYN/ACK、ACK に載せる。RFC 8684 では、この交換が MPTCP の使用を協議し、後から加えるサブフローの認証に使う鍵材料を交換する。必要な交換が欠ければ、結果は単一経路の通常 TCP である。オプションが一度見えたことは、別経路でも保存されること、利用者の身元、アプリの権限、アドレスの所有を意味しない。

この仕様の履歴にも同じ節度がある。RFC 6824 は 2013 年の Experimental な v0 で、実装と評価の対象だった。RFC 8041 は 2017 年時点の運用経験を記録した。2020 年の Standards Track RFC 8684 は v0 を廃止し、展開経験からの明確化と修正を取り入れた。これは経験が仕様を変えた証拠であり、現在の普及率や特定製品の設定を示す証拠ではない。

Token は状態の索引である

追加サブフローの最初の MP_JOIN SYN は、受信側の Token、送信側の新しい nonce、Address ID を運ぶ。v1 の SHA-256 選択では、Token は受信側の初期鍵の SHA-256 ハッシュ上位 32 ビットである。受信側はこれを使い、この SYN が加わろうとするローカル MPTCP 接続を見つける。

これは状態の多重化解除であり、入場券ではない。SYN の時点では新しいサブフローに既知の五つ組はまだないため Token が必要になる。確立後のパケットは、通常 TCP と同じく五つ組で多重化解除される。Token はすべてのパケットに付く恒久的な身分票ではない。

Address ID も別の仕事をする。NAT が相手に見える IP ヘッダを書き換えても、送信側のアドレスを相関させ、削除処理を可能にする。その値は IP の所有証明でも、経路広告の権限でも、接続外の許可でもない。

HMAC は連続性を確認し、方針は受入れを決める

Token による検索だけでは足りない。受信側は nonce と切り詰めた HMAC を返し、開始側も HMAC を返す。MP_CAPABLE で交換した鍵と二つの新しい nonce が計算に使われるため、古い交換をそのまま再生して今回の参加にすることはできない。

HMAC が正しい場合、RFC 8684 が言うのは、両端が接続開始時と同じ MPTCP peer であり、このサブフローがどの接続に属するかで合意した、という範囲だけである。人の身元、企業の権限、後続リクエストの許可、永続的な業務結果まで確認したことにはならない。

しかも受信者の拒否権は残る。Token が未知なら RST、Token が既知でもローカル方針が追加サブフローを禁じれば RST、HMAC が欠けるか誤れば閉鎖である。検索は受入れを命令しない。暗号的な継続性もアプリケーションの裁量を奪わない。

確立後の五つ組が健全でも、言えることは伝送層の事実に限られる。初期協議、Token による状態選択、HMAC の確認、特定サブフローの確立は記録できる。しかし、アプリケーションが要求を承認したか、データを永続化したか、利用者が結果を得たかは別の証拠を要する。バイト列の連続性と意味の連続性は同じではない。

情報源と証拠の限界

これらの RFC は仕様化された構造とその改訂記録を支える。現在の利用規模、実経路の分離、NAT の実装、性能、製品適合、人の身元、アプリケーションの完了を立証するものではない。