2.6. IKE SA の SPI と Cookie

ヘッダの先頭の 2 つの 8 オクテット・フィールドは "IKE SPIs" と呼ばれ, IKE パケットの先頭で接続識別子として使用されます。各エンドポイントは 2 つの SPI のうち一方を選択し, IKE SA の一意の識別子となるようにそれらを選択しなければなりません (MUST)。SPI 値がゼロであることは特別な意味を持ちます。それは, 送信側が相手側の SPI 値をまだ知らないことを示します。

入着する IKE パケットは, パケットの SPI のみを使用して IKE SA にマッピングされ, (たとえば) パケットの送信元 IP アドレスは使用されません。

ESP や AH ではメッセージのヘッダに受信者の SPI のみが現れるのに対し, IKE では送信者の SPI もすべてのメッセージで送信されます。IKE SA の本来のイニシエータが選択した SPI は常に最初に送信されるため, 複数の IKE SA を開いているエンドポイントが, 自身が割り当てた SPI を使用して適切な IKE SA を見つけたい場合, 自身が最初か 2 番目かの 8 オクテットを割り当てたかを判断するために, ヘッダの Initiator フラグを調べなければなりません (MUST)。

初期 IKE 交換の最初のメッセージにおいて, イニシエータはレスポンダの SPI 値を知らないため, そのフィールドをゼロに設定します。IKE_SA_INIT 交換が INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, または COOKIE (セクション 2.6 参照) のために IKE SA を作成しない場合, レスポンダの SPI も応答メッセージではゼロになります。ただし, レスポンダがゼロでないレスポンダ SPI を送信した場合, イニシエータはその理由のみで応答を拒否すべきではありません (SHOULD NOT)。

IKE に対する 2 つの想定される攻撃は, 状態および CPU の枯渇であり, ターゲットが偽装された IP アドレスからのセッション開始要求で溢れます。レスポンダが, イニシエータが実際にその送信を主張するアドレスでパケットを受信できると確信するまで, 最小限の CPU を使用し, SA に対していかなる状態もコミットしない場合, これらの攻撃の効果は低減されます。

レスポンダが多数の半開 (half-open) の IKE SA を検出したとき, それは COOKIE 通知を含む応答で IKE_SA_INIT 要求に返答すべきです (SHOULD)。この通知に関連するデータの長さは 1 から 64 オクテット (両端含む) でなければならず (MUST), その生成についてはこのセクションの後半で説明します。IKE_SA_INIT 応答に COOKIE 通知が含まれている場合, イニシエータは IKE_SA_INIT 要求を再試行しなければならず (MUST), 受信したデータを含む COOKIE 通知を最初のペイロードとして含め, 他のすべてのペイロードは変更せずに維持しなければなりません (MUST)。初期交換は次のようになります。

Initiator Responder

HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

最初の 2 つのメッセージは, cookie の通信を除き, イニシエータまたはレスポンダのいかなる状態にも影響を与えません。特に, 最初の 4 つのメッセージのメッセージ・シーケンス番号はすべてゼロとなり, 最後の 2 つのメッセージのメッセージ・シーケンス番号は 1 となります。'A' はイニシエータが割り当てた SPI であり, 'B' はレスポンダが割り当てた SPI です。

IKE 実装は, 2 番目の IKE_SA_INIT メッセージが到着したときに, 保存された状態を必要とせずにその有効な cookie を認識できるように, レスポンダの cookie 生成を実装できます。cookie の生成に使用される正確なアルゴリズムと構文は相互運用性に影響しないため, ここでは規定されません。以下は, エンドポイントが cookie を使用して限定的な DoS 保護を実装する方法の例です。

これを行う良い方法は, レスポンダの cookie を次のように設定することです。

Cookie = | Hash(Ni | IPi | SPIi | )

ここではレスポンダのみが知り, 定期的に変更されるランダムに生成された秘密であり, | は連結を示します。が再生成されるたびにを変更すべきです (SHOULD)。IKE_SA_INIT が 2 回目に到着したときに cookie を再計算し, 受信したメッセージ中の cookie と比較できます。一致すれば, レスポンダは, その cookie がの最後の変更以降に生成されたこと, および IPi が最初に見た送信元アドレスと同じでなければならないことを知ります。SPIi を計算に組み込むことで, 複数の IKE SA が並行してセットアップされている場合, それらがすべて異なる cookie を得ることが保証されます (イニシエータが一意の SPIi を選択したと仮定)。ハッシュに Ni を組み込むことで, メッセージ 2 のみを見た攻撃者がメッセージ 3 を首尾よく偽造できないことが保証されます。また, ハッシュに SPIi を組み込むことで, 攻撃者が他端から 1 つの cookie を取得し, その後, すべて異なるイニシエータ SPI (おそらくポート番号も) を持つ多くの IKE_SA_INIT 交換を開始して, レスポンダに 1 つの NAT ボックスの背後に多くのマシンがあるように見せかけて接続を試みることを防ぎます。

の新しい値が, 初期化処理中の接続がある間に選択された場合, 現在の以外を伴う IKE_SA_INIT が返される可能性があります。その場合, レスポンダは, 新しい cookie を伴う別の応答を送信してメッセージを拒否してもよく (MAY), または古いの値を短時間保持して, いずれかから計算された cookie を受け入れてもよい (MAY) です。レスポンダは, 変更後も無期限に cookie を受け入れるべきではありません (SHOULD NOT), なぜならそれは DoS 保護の一部を無効にするからです。レスポンダは, 特に攻撃を受けている場合は, の値を頻繁に変更すべきです (SHOULD)。

一方が, 内容が期待される値と一致しない cookie を含む IKE_SA_INIT 要求を受信した場合, その側は cookie を無視し, cookie が含まれていなかったかのようにメッセージを処理しなければなりません (MUST)。通常これは, 新しい cookie を含む応答を送信することを意味します。イニシエータは, あきらめる前に試行する cookie 交換の回数を制限すべきであり (SHOULD), おそらく指数バックオフを使用します。攻撃者は, イニシエータの IKE_SA_INIT メッセージに対する複数の cookie 応答を偽造でき, それらの偽造された cookie 応答のそれぞれが 2 つのパケットの送信を引き起こします。1 つはイニシエータからレスポンダへのパケット (レスポンダはそれらの cookie を拒否する), および正しい cookie を含むレスポンダからイニシエータへの 1 つの応答です。

用語についての注記: "cookies" という用語は, Photuris (IPsec のための初期の鍵管理提案) における Karn と Simpson の [PHOTURIS] に由来し, それ以降残っています。Internet セキュリティアソシエーションおよび鍵管理プロトコル (ISAKMP) [ISAKMP] の固定メッセージ・ヘッダには, "cookies" と呼ばれる 2 つの 8 オクテット・フィールドが含まれており, その構文は IKEv1 と IKEv2 の両方で使用されますが, IKEv2 ではそれらは "IKE SPI" と呼ばれ, cookie を保持する Notify ペイロード内に新しい独立したフィールドがあります。

イニシエータが IKE_SA_INIT 交換を再試行しなければならない一般的な理由は 2 つあります。レスポンダが cookie を要求するか, あるいは KEi ペイロードに含まれていたものとは異なる Diffie-Hellman グループを望むかです。イニシエータがレスポンダから cookie を受信した場合, イニシエータは, 次回の IKE_SA_INIT 要求の再試行でのみ cookie を含めるか, それともすべての後続の再試行でも含めるかを決定する必要があります。

イニシエータが次回の再試行でのみ cookie を含める場合, 一部のケースでは追加のラウンドトリップが必要になることがあります。イニシエータがすべての再試行で cookie を含め, しかしレスポンダがこれをサポートしない場合にも, 追加のラウンドトリップが必要です。たとえば, レスポンダが cookie 計算に KEi ペイロードを含める場合, それは新しい cookie を送信して要求を拒否します。

両ピアがすべての再試行で cookie を含めることをサポートしている場合, わずかに短い交換が発生する可能性があります。

Initiator Responder

HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,0), N(INVALID_KE_PAYLOAD) HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> <-- HDR(A,B), SAr1, KEr, Nr

実装はこの短い交換をサポートすべきです (SHOULD) が, 他の実装がこの短い交換をサポートしていない場合でも, 失敗してはなりません (MUST NOT)。