2.5. Version Numbers and Forward Compatibility (バージョン番号と前方互換)

2.5. Version Numbers and Forward Compatibility (バージョン番号と前方互換)

本書は IKE バージョン 2.0 (メジャー 2, マイナー 0) を記述する. 本書は [IKEV2] に代わる. 一部実装は 1.0 と 2.0 の両方, 将来は他バージョンもサポートしたいだろう.

パケット形式や必須動作が, 古いノードが理解しないフィールドを無視し古い仕様の動作だけを取れば新しいノードと相互運用できないほど劇的に変わった場合にのみメジャーを増やすべきである. マイナーは新能力を示し, マイナーが小さいノードは無視しなければならず, 大きいノードは情報目的で用いる. 例: 新しい Notify タイプを処理できること. マイナーが大きい側は, 相手がそのメッセージを理解できないことに気づき送らない.

エンドポイントがより高いメジャーのメッセージを受信したら, メッセージを破棄しなければならず, サポートする最高 (最も近い) バージョン番号を含む INVALID_MAJOR_VERSION の未認証 Notify を送るべきである. メジャー n と m をサポートするなら n と m の間のすべてをサポートしなければならない. サポートするメジャーのメッセージを受信したら, そのバージョン番号で応答しなければならない. 両者がサポートする最大メジャーより低いメジャーで通信するよう騙されないため, IKE にはより高いメジャーを話せることを示すフラグがある.

したがって IKE ヘッダのメジャーはメッセージのバージョンであり, 送信者がサポートする最高バージョンではない. initiator が n, n+1, n+2 を話せ, responder が n と n+1 なら n+1 で交渉し, initiator はより高いバージョン能力を示すフラグを立てる. (攻撃者のエラーなどで) 誤って n に落ちた場合, 双方は相手がより高いメジャーをサポートできることに気づき, 接続を切り n+1 で再接続しなければならない.

IKEv1 はより高いバージョンを表明する方法がないためこれらのルールに従わない. したがって攻撃者は v2 対応 2 ノードを v1 で話させうる. v2 対応ノードが v1 に落ちたらログに記録すべきである.

前方互換のため, RESERVED と印されたフィールドは 2.0 実装がゼロに設定しなければならず, 2.0 実装は内容を無視しなければならない ("送るときは保守的に, 受けるときは寛容に" [IP]). 将来の版は理解しない実装が無視することが保証された形でこれらのフィールドを使える. 同様に未定義のペイロード型は将来用に予約され, 未定義の版の実装はそれらのペイロードをスキップし内容を無視しなければならない.

IKEv2 は各ペイロードヘッダに前方互換のための "critical" フラグを追加する. critical が立ちペイロード型が未認識ならメッセージを拒否し, そのペイロードを含む IKE リクエストへのレスポンスに UNSUPPORTED_CRITICAL_PAYLOAD の Notify を含めなければならない. Notification Data は 1 オクテットのペイロード型である. critical が立たず型が未サポートならそのペイロードを無視しなければならない. IKE レスポンスで送るペイロードに critical を立ててはならない. critical はペイロード型にのみ適用され内容には適用されない. 型は認識できるが中身に未認識がある場合 (SA 内の未知変換, Notify 内の未知タイプなど), critical は無視される.

将来新しいペイロード型が本仕様のフィールドと交互に現れてもよいが, 実装は 1 節と 2 節の図の順で本仕様のペイロードを送るべきであり, 順序が異なるだけでメッセージを無効として拒否してはならない.