2.21. Error Handling (エラー処理)

IKE 処理中に多様なエラーが起こり得る. 一般規則は, 形式が悪いかポリシー上受け入れられない要求 (一致する暗号アルゴリズムがないなど) を受け取った場合, 応答にエラーを示す Notify ペイロードを含めることである. その応答を送るかは認証済み IKE SA があるかによる.

応答パケットの解析または処理エラーでは, 応答が新しい要求を生成すべきでないため (新しい要求がエラーを返す唯一の手段となる), 一般にエラーを返さない. それでも受信者は IKE 状態をクリーンアップすべきである (悪い SA に Delete を送るなど).

認証失敗 (AUTHENTICATION_FAILED と EAP 失敗) と形式不正メッセージ (INVALID_SYNTAX) のみが, Delete ペイロードを伴う明示的 INFORMATIONAL 交換なしに IKE SA 削除につながる. 他のエラー条件はポリシーによりそのような交換が必要な場合がある. 交換が EAP Failure で終了した場合, AUTHENTICATION_FAILED 通知は送らない.

2.21.1. Error Handling in IKE_SA_INIT (IKE_SA_INIT のエラー処理)

暗号保護 IKE SA 確立前のエラーは非常に注意深く扱う必要がある. ピアの診断を助けるため応答したいことと, 偽造メッセージに基づく DoS の一部になりたくないことのトレードオフである.

IKE_SA_INIT 交換では, 任意のエラー通知が交換を失敗させる. COOKIE, INVALID_KE_PAYLOAD, INVALID_MAJOR_VERSION など一部は後続の成功交換につながり得る. すべてのエラー通知は完全に未認証のため, 受信者は諦める前にしばらく再試行を続けるべきである. 本仕様で定義された是正措置 (COOKIE など) がない限り, エラー通知だけを根拠に即座に行動すべきでない.

2.21.2. Error Handling in IKE_AUTH (IKE_AUTH のエラー処理)

IKE_AUTH 交換で認証が失敗するあらゆる理由のエラー (共有秘密が無効, ID が無効, 信頼できない CA, 失効または期限切れ証明書など) は AUTHENTICATION_FAILED 通知となるべきである. レスポンダ側のエラーなら保護された応答に含め, 通常その応答の唯一のペイロードである. IKE_AUTH は暗号化・完全性保護されているが, まだ相手を認証していないピアは情報を慎重に扱う必要がある.

イニシエータ側のエラーなら, 通常他ペイロードのない別 INFORMATIONAL 交換で返してよい. これは応答のエラーで新交換を始めないという一般規則の例外である.

ただし, サポートされないクリティカルペイロードを含む要求, または全体が形式不正 (ペイロード内容だけが悪いのではない) の場合は全体を拒否し, UNSUPPORTED_CRITICAL_PAYLOAD または INVALID_SYNTAX 通知のみを応答として送らなければならない. この場合受信者は認証関連ペイロードを検証すべきでない.

IKE_AUTH で認証に成功すれば IKE SA は確立するが, Child SA 確立や設定情報要求はまだ失敗し得る. その失敗が自動的に IKE SA 削除を意味しない. 具体的にレスポンダは認証関連 (IDr, CERT, AUTH) をすべて含めつつ, 付随交換に FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN などのエラー通知を送ってもよく, イニシエータはこれだけで認証失敗としてはならない. ポリシーにより後で IKE SA を削除してもよい.

IKE_AUTH 交換または直後の INFORMATIONAL (IKE_AUTH 応答処理中のエラー時) では, UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, AUTHENTICATION_FAILED のみが Delete ペイロードなしで IKE SA を削除または未作成にする. 拡張文書は同じ意味の新通知を定義してもよいが, Vendor ID などでピアが理解すると示されるまで用いてはならない.

2.21.3. Error Handling after IKE SA is Authenticated (IKE SA 認証後のエラー処理)

IKE SA 認証後, エラーのあるすべての要求は相手にエラーを通知する応答を生じなければならない.

通常, 一方の有効な応答が相手側でエラーになる状況はないはずなので, 応答以外でエラーメッセージを送る理由はないはずである. そのようなエラーを INFORMATIONAL で送るとさらなるエラーとループの原因になり得るため, 送るべきではない. ピア間で状態が一致しないエラーが見えたら, IKE SA を削除してやり直すのがよい場合がある.

要求を解析するピアが (MAC チェックとウィンドウチェック後に) 形式不正と判断し INVALID_SYNTAX を返した場合, その通知は両ピアで致命的とみなされ, 明示 Delete なしで IKE SA が削除される.

2.21.4. Error Handling Outside IKE SA (IKE SA 外のエラー処理)

ノードは未保護メッセージへの応答送信レートを制限しなければならない.

UDP 500 または 4500 で, 既知の IKE SA の文脈外 (IKE SA 開始要求でもない) メッセージを受け取った場合, 最近クラッシュした結果かもしれない. 応答としてマークされていれば監査してよいが応答してはならない. 要求としてマークされていれば監査し, 応答を送ってもよい. 応答する場合, 同一 IKE SPI と Message ID をコピーし, 送信元 IP アドレスとポートへ送らなければならない. 応答は暗号保護してはならず INVALID_IKE_SPI Notify を含めなければならない. INVALID_IKE_SPI は認識されない目的 SPI の IKE メッセージを受け取ったことを示し, 通常は受信者が再起動して IKE SA を忘れたことを意味する.

そのような未保護 Notify を受け取ったピアは応答してはならず, 既存 SA の状態を変えてはならない. 偽造か, 正当な相手が騙されて送った応答かもしれない. ノードはそのようなメッセージ (および ICMP destination unreachable など) をその IP の SA に問題があるヒントとして扱い, 該当 IKE SA で生存確認を開始すべきである. 実装は DoS に巻き込まれないようテスト頻度を制限すべきである.

IKE 要求の文脈外のエラー (存在しない SPI で ESP を受信するなど) では, 問題を述べる Notify を含む INFORMATIONAL を開始すべきである.

IKE SA を持つ IP (NAT 使用時はポート) から疑わしいメッセージを受け取ったノードは, その SA 上の IKE INFORMATIONAL で IKE Notify を送るべきである. 受信者は SA 状態を変えてはならないが, 障害診断のため監査してもよい.