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

2.6. IKE SA SPIs and Cookies (IKE SA の SPI とクッキー)

2.6. IKE SA SPIs and Cookies (IKE SA の SPI とクッキー)​

ヘッダ先頭の 8 オクテット 2 つを "IKE SPI" と呼び, IKE パケット冒頭の接続識別子として用いる. 各エンドポイントは 2 つの SPI の一方を選び, IKE SA の一意識別子となるよう選ばなければならない. SPI 値ゼロは特別で, 送信者がまだ相手の SPI を知らないことを示す.

着信 IKE パケットは (例えばソース IP ではなく) パケットの SPI のみで IKE SA にマッピングされる.

ESP や AH と異なり受信者の SPI だけがメッセージヘッダに現れるのに対し, IKE では送信者の SPI も毎回送られる. IKE SA の元 initiator が選んだ SPI が常に先に送られるため, 複数 IKE SA を開いたエンドポイントが自ら割り当てた SPI で適切な IKE SA を探すには, ヘッダの Initiator フラグを見て最初の 8 オクテットと次の 8 オクテットのどちらを割り当てたか判定しなければならない.

初期 IKE 交換の最初のメッセージでは initiator は responder の SPI を知らないためそのフィールドをゼロにする. IKE_SA_INIT が INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, または COOKIE のため IKE SA 作成に至らない場合, レスポンスでも responder の SPI はゼロになりうる. ただし responder が非ゼロの responder SPI を送った場合, initiator はそれだけを理由にレスポンスを拒否すべきではない.

IKE に対する想定される攻撃の 2 つは状態と CPU の枯渇であり, 偽造 IP からのセッション開始リクエストでターゲットが溢れる. responder が最小 CPU で, initiator が主張する送信元アドレスでパケットを受信できると分かるまで SA に状態をコミットしなければ, 攻撃は弱められる.

responder が多数の half-open IKE SA を検出したら, COOKIE 通知を含むレスポンスで IKE_SA_INIT に答えるべきである. この通知に関連するデータは 1 から 64 オクテット (含む) でなければならず, 生成は本節後述. IKE_SA_INIT レスポンスに COOKIE が含まれる場合, initiator は IKE_SA_INIT を再試行し, 受信データを含む COOKIE 通知を最初のペイロードとし他は変更せず含めなければならない. 初期交換は次のとおりとなる:

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 メッセージはクッキー伝達以外に initiator/responder 状態を変えない. 特に最初の 4 メッセージのシーケンス番号はすべてゼロ, 最後の 2 つは 1 である. 'A' は initiator の SPI, 'B' は responder の SPI である.

IKE 実装は, 2 番目の IKE_SA_INIT 到着時に保存状態なしで有効クッキーを認識できるよう responder クッキー生成を実装できる. クッキー生成の正確なアルゴリズムと構文は相互運用性に影響しないためここでは規定しない. 以下は限定的 DoS 防御にクッキーを使う例である.

次のように responder クッキーを設定するのが良い:

Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

ここで <secret> は responder のみが知る乱数秘密で定期的に変更し, | は連結である. <secret> を再生成するたび <VersionIDofSecret> を変えるべきである. 2 回目の IKE_SA_INIT でクッキーを再計算し受信メッセージのクッキーと比較できる. 一致すれば <secret> 最終変更以降に生成されたクッキーであり, IPi は初回に見たソースアドレスと同じでなければならない. SPIi を計算に入れると並行セットアップ時に異なるクッキーが得られる (initiator が一意の SPIi を選ぶ前提). Ni をハッシュに入れるとメッセージ 2 だけを見た攻撃者がメッセージ 3 を偽造できない. SPIi を入れると, 一端から 1 つのクッキーを取り異なる initiator SPI (とポート) で多数の IKE_SA_INIT を始め, responder に NAT 背後に多数のマシンがいると思わせることを防ぐ.

初期化中の接続がある間に <secret> の新値が選ばれると, 現在の <VersionIDofSecret> 以外が返る IKE_SA_INIT がありうる. その場合 responder は新クッキー付きの別レスポンスで拒否してもよく, 短時間古い <secret> を残しどちらで計算したクッキーも受け入れてもよい. <secret> 変更後も無期限にクッキーを受け入れてはならない (DoS 防御の一部が無効になる). 特に攻撃下では <secret> を頻繁に変えるべきである.

一方が期待値と一致しない内容のクッキーを含む IKE_SA_INIT を受け取ったら, そのクッキーを無視しクッキーが無かったかのように処理しなければならない. 通常は新クッキーを含むレスポンスを送る. initiator は諦める前に試すクッキー交換回数を制限し, 指数バックオフを使ってもよい. 攻撃者は initiator の IKE_SA_INIT に対し複数の偽クッキーレスポンスを偽造でき, それぞれ 2 パケットを引き起こす: initiator から responder への 1 パケット (偽クッキーは拒否), responder から initiator への正しいクッキーを含む 1 レスポンス.

用語: "cookies" は Karn と Simpson [PHOTURIS] の Photuris (IPsec 向け早期鍵管理提案) に由来し残った. ISAKMP [ISAKMP] 固定ヘッダの 8 オクテット 2 フィールドが "cookies" と呼ばれ, IKEv1/v2 で同じ構文を使うが IKEv2 では "IKE SPI" と呼び, Notify ペイロードに別フィールドでクッキーを持つ.

initiator が IKE_SA_INIT を再試行する一般的理由は 2 つ: responder がクッキーを要求するか, KEi に含まれたものとは異なる Diffie-Hellman 群を望むかである. initiator が responder からクッキーを受け取ったら, 次の 1 回の再試行だけに含めるか, 以降すべての再試行に含めるかを決める必要がある.

次の再試行にだけ含めると追加 RTT が要る場合がある. すべての再試行に含めても responder がサポートしないなら追加 RTT が要る. 例: responder が KEi をクッキー計算に含めると, 新クッキーを送ってリクエストを拒否する.

両ピアがすべての再試行にクッキーを含めることをサポートすれば, やや短い交換が可能である.

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

実装はこの短い交換をサポートすべきだが, 他実装がサポートしなくても失敗してはならない.

に最終更新