要約

  • draft-nir-ipsecme-big-payloadの改訂08は2026年9月10日に公開された。改訂07との差分は日付、失効日、一語の訂正、Classic McEliece参照の更新であり、設計変更ではない。
  • 提案は予約済みの1ビットをLとして使い、IKE_SA_INITでLARGE_PAYLOAD_SUPPORTEDを通知した相手に対して、ペイロード長を16ビットから32ビットへ広げる。
  • 通知は真偽だけで、最大サイズ、対象交換、ペイロード種別、メモリー、処理コスト、同時実行枠を示さない。草案は実装上の妥当な上限も認めている。
  • Datatracker上はIPSECMEのアクティブな候補で、状態は「Call For Adoption By WG Issued」。shepherdもIESG承認もなく、要求中の値は現在のIANA登録簿にない。

32ビットで表せることと、受け入れられること

RFC 7296では、IKEメッセージ全体のLengthは4オクテットなのに、個々のGeneric Payload HeaderのPayload Lengthは2オクテットである。そのため、外側のメッセージは大きな総量を記述できても、一つのペイロードは65,536オクテット未満に抑えられる。

候補草案は、予約ビットだった場所にLを置く。ゼロなら従来どおり、1なら長さフィールドを4オクテットとして読む。相手がどちらの構文を理解するかを誤らせないために、データを持たないステータス通知LARGE_PAYLOAD_SUPPORTEDを使う。

ここまではワイヤ形式の合意である。通知には数量がない。何バイトまで保持するか、どの交換やペイロードなら大きくしてよいか、再構成に使うメモリー、検証に費やす時間、同時に何件を処理するかは書かれていない。「対応」を32ビットの全範囲に対する受入保証と読めば、受信側が発していない約束を送信側が作ることになる。

片方向だけでも成立する能力

通知はIKE_SA_INITで送るが、大きなペイロードそのものを同じ初期交換に入れることは禁止される。初期の鍵交換材料が大きい場合は、RFC 9242のIKE Intermediate Exchangeを使うことが推奨されている。

また、能力は非対称でもよい。通知を送った側は拡張形式を処理できる。相手から同じ通知を受け取っていなければ、自分からその形式を送り返すことはできない。双方が同じ大きさの処理枠を予約する交渉ではなく、方向ごとに利用可能なパーサーを確定する仕組みだ。

受信時には、宣言された長さがIKEメッセージ内の残りのオクテットに収まるかを確認する。不足していればINVALID_SYNTAX、十分なら通常のペイロードとして処理する。短い形式でも表せたという理由だけで、正しく符号化された拡張形式を拒んではならない。

この規則は構文の一貫性を守る。一方で、整形式のオブジェクトがローカルな資源上限を越えたときまで無条件に処理するとは述べていない。

DELETEの最大例が教えるもの

草案はIPsec SAを削除するDELETEペイロードを例にする。4オクテットのSPIを最大65,535個並べると、ペイロードは262,150オクテットになる。従来の2オクテット長では、一つのペイロードに全件を収められない。

この計算は長い形式の用途を示すが、262,150オクテットを全実装の最低受入量にはしない。本文は、実装がDELETE内のSPI数に妥当性上限を設けられると明記している。ヘッダーを読めることと、巨大な一覧のために資源を確保することは別の適合判断である。

上限が観測も記録もできなければ、送信側はタイムアウトや一般的なエラーで境界を探すしかない。運用側も、意図した防御、パーサー未対応、単なる不具合を切り分けにくい。能力ビットの意味を広げすぎるほど、相互運用の説明はかえって曖昧になる。

フラグメントとTCPは輸送手段である

RFC 7383は暗号化されたIKEメッセージを分割し、単一のIPパケットでは通れない経路に対応する。RFC 9329はUDPが遮断または阻害される環境で、IKEv2とIPsecをTCP上で運ぶ方法を定める。どちらも到達の問題を改善するが、受信側のアプリケーション資源を予約しない。

フラグメントは最終的に受信、再構成、検証される。TCPが確実に届けても、処理待ちを無制限に置けるわけではない。長さの表現、経路上の運び方、受信時の資源判断は、別々の制御面として扱わなければならない。

改訂08と採用状況を混ぜない

公式の改訂07対08差分で確認できるのは、日付と失効日の更新、thanからthatへの訂正、Classic McEliece参照の更新である。資源量を交渉するフィールドも、新しい拒否方式も加わっていない。9月10日の更新は保守であって、制度上の転換ではない。

プロセスの記録には複数の表現がある。DatatrackerはIPSECMEとの関係を示し、WG stateを「Call For Adoption By WG Issued」としている。履歴では7月22日にWorking GroupとIETF streamが設定され、採用呼びかけが発行された。メーリングリストでは意見期限が8月15日とされた。さらに改訂08の自動I-D告知は、IPSECMEの“work item”だと書く。

しかし現在の文書ページはCandidateのままで、shepherdはおらず、IESG stateは「I-D Exists」、担当Area Directorとtelechatもない。draft-nirというファイル名は個人名形式と整合するが、採用を決める記録ではない。どちらか一文だけを採用判定に使わず、これらを併記するのが妥当だ。

本文はStandards Trackを意図し、承認されればRFC 7296を更新すると述べる一方、Datatrackerのintended statusは現在「(None)」である。これはメタデータ差であり、承認の証拠ではない。IANAのIKEv2 Notify Message Status TypesにもLARGE_PAYLOAD_SUPPORTEDは未掲載だ。割当要求と登録は違う。確認した資料には、IETF合意、IESG承認、RFC化、実装、相互接続試験、展開、障害の証拠はない。

情報源