8. Backward-Compatibility Considerations (下位互換性の考慮事項)
8. Backward-Compatibility Considerations (下位互換性の考慮事項)
ESP にはバージョン番号がなく, IPsec ピアが各自が使用している, または使用すべき ESP のバージョンを発見またはネゴシエートできるメカニズムもありません。このセクションでは, その結果生じる下位互換性の問題について説明します。
まず, ESP v3 で利用可能な新機能のいずれも使用されていない場合, ESP v2 と v3 の ESP パケットの形式は同一です。組み合わせモード暗号化アルゴリズムが使用される場合 (ESP v3 でのみサポートされる機能), 結果として生成されるパケット形式は ESP v2 仕様とは異なる可能性があります。ただし, ESP v2 のみを実装するピアは, ESP v3 コンテキストでのみ使用するために定義されているため, そのようなアルゴリズムをネゴシエートすることはありません。
拡張シーケンス番号 (ESN) のネゴシエーションは IKE v2 でサポートされており, IKE v1 の解釈ドメイン (DOI) への ESN 追補によって IKE v1 にも対応されています。
新しい ESP (v3) では, トラフィックフロー機密性 (TFC) をより適切にサポートするために 2 つの規定を設けています:
- IP パケットの終端後の任意のパディング
- Next Header = 59 を使用した破棄規約
最初の機能は受信者に問題を引き起こすべきではありません。なぜなら, IP 総長フィールドが IP パケットの終端位置を示すからです。したがって, パケットの終端後の TFC パディングバイトは, IPsec ソフトウェアがそのようなパディングを削除しない場合でも, ESP 処理後の IP パケット処理のある時点で削除されるべきです。したがって, これは ESP v3 の機能であり, 受信者が ESP v2 または ESP v3 を実装しているかに関係なく, 送信者が使用できます。
2 番目の機能により, 送信者は TFC 目的でトンネル内に必ずしも適切な形式の IP パケットを構成しない任意のバイト文字列のペイロードを送信できます。ESP パケットの Next Header フィールドに値 "59" が含まれている場合, ESP v2 受信者が何をするかは未解決の問題です。不正な形式の IP ヘッダーを見つけたときにパケットを破棄し, このイベントをログに記録する可能性がありますが, 認証されたピアから受信したトラフィックに対する DoS 脆弱性を構成するため, 確実にクラッシュすべきではありません。したがって, この機能は最適化であり, 受信者が ESP v2 または ESP v3 を実装しているかに関係なく, ESP v3 送信者が利用できます。