メインコンテンツまでスキップ

2.5. バージョン番号と前方互換性

2.5. バージョン番号と前方互換性​

この文書は IKE のバージョン 2.0 を記述しており, メジャーバージョン番号が 2, マイナーバージョン番号が 0 であることを意味します。この文書は [IKEV2] の置き換えです。一部の実装はバージョン 1.0 とバージョン 2.0 をサポートしたいと考える可能性が高く, 将来は他のバージョンもサポートしたいと考えるでしょう。

メジャーバージョン番号は, パケット形式または必要なアクションが, 単に理解できないフィールドを無視して古い仕様で指定されたアクションを実行しても, 古いバージョンのノードが新しいバージョンのノードと相互運用できないほど劇的に変更された場合にのみ, 増分されるべきです。マイナーバージョン番号は新しい機能を示し, より小さいマイナーバージョン番号を持つノードによって無視されなければなりません (MUST) が, より大きいマイナーバージョン番号を持つノードによって情報提供の目的で使用されます。たとえば, 新しく定義された通知メッセージタイプを処理する能力を示す可能性があります。より大きいマイナーバージョン番号を持つノードは, 自分の通信相手がそのメッセージを理解できないため, それを送信しないことに単に注意するでしょう。

エンドポイントがより高いメジャーバージョン番号を持つメッセージを受信した場合, そのメッセージを破棄しなければならず (MUST), 自分がサポートする最高の (最も近い) バージョン番号を含む INVALID_MAJOR_VERSION タイプの認証されていない通知メッセージを送信すべきです (SHOULD)。エンドポイントがメジャーバージョン n とメジャーバージョン m をサポートする場合, n と m の間のすべてのバージョンをサポートしなければなりません (MUST)。自分がサポートするメジャーバージョンを持つメッセージを受信した場合, そのバージョン番号で応答しなければなりません (MUST)。2 つのノードが, 両方がサポートする最大バージョン番号より低いメジャーバージョン番号で通信するよう騙されるのを防ぐために, IKE は, ノードがより高いメジャーバージョン番号で通信できることを示すフラグを持っています。

したがって, IKE ヘッダー内のメジャーバージョン番号は, メッセージのバージョン番号を示し, 送信者がサポートする最高のバージョン番号ではありません。イニシエータがバージョン n, n+1, n+2 で通信できる場合で, レスポンダがバージョン n と n+1 で通信できる場合, それらは n+1 で通信することをネゴシエートし, イニシエータはより高いバージョンで通信する能力を示すフラグを設定します。もし誤って (おそらく能動的な攻撃者によるエラーメッセージの送信によって) バージョン n でネゴシエートした場合, 両者は相手側がより高いバージョン番号をサポートできることに気づき, 接続を切断してバージョン n+1 で再接続しなければなりません (MUST)。

IKEv1 はこれらのルールに従わないことに注意してください。なぜなら, v1 ではより高いバージョン番号で通信できることを示す方法がないからです。したがって, 能動的な攻撃者は 2 つの v2 対応ノードを騙して v1 で通信させることができます。v2 対応ノードが v1 にまでネゴシエートダウンした場合, その事実をログに記録すべきです。

また, 前方互換性のために, RESERVED とマークされたすべてのフィールドは, バージョン 2.0 を実行する実装によってゼロに設定されなければならず (MUST), その内容はバージョン 2.0 を実行する実装によって無視されなければなりません (MUST) ("送信には保守的に, 受信には寛容に" [IP])。このようにして, プロトコルの将来のバージョンは, それらを理解しない実装によって無視されることが保証される方法で, それらのフィールドを使用できます。同様に, 定義されていないペイロードタイプは将来の使用のために予約されています。それらが未定義であるバージョンの実装は, それらのペイロードをスキップし, その内容を無視しなければなりません (MUST)。

IKEv2 は, 前方互換性のさらなる柔軟性のために, 各ペイロードヘッダーに "クリティカル (critical)" フラグを追加します。クリティカルフラグが設定されており, ペイロードタイプが認識されない場合, メッセージは拒否されなければならず (MUST), そのペイロードを含む IKE 要求への応答には, サポートされていないクリティカルペイロードが含まれていたことを示す UNSUPPORTED_CRITICAL_PAYLOAD 通知ペイロードを含めなければなりません (MUST)。その通知ペイロード内で, 通知データは 1 オクテットのペイロードタイプを含みます。クリティカルフラグが設定されておらず, ペイロードタイプがサポートされていない場合, そのペイロードは無視されなければなりません (MUST)。IKE 応答メッセージで送信されるペイロードは, クリティカルフラグを設定してはなりません (MUST NOT)。クリティカルフラグはペイロードタイプにのみ適用され, 内容には適用されないことに注意してください。ペイロードタイプが認識されるが, ペイロードが認識されないものを含む場合 (SA ペイロード内の未知の変換や, 通知ペイロード内の未知の通知メッセージタイプなど), クリティカルフラグは無視されます。

将来新しいペイロードタイプが追加され, この仕様で定義されたフィールドと交互に現れる可能性がありますが, 実装はこの仕様で定義されたペイロードをセクション 1 と 2 の図に示された順序で送信すべきです (SHOULD)。実装は, それらのペイロードが他の任意の順序であるメッセージを無効として拒否してはなりません (MUST NOT)。