2.21. エラー処理

IKE 処理中に発生する可能性のあるエラーは多くあります。一般規則として, フォーマットが不正である, またはポリシー上の理由 (一致する暗号アルゴリズムがないなど) で受け入れられない要求を受信した場合, 応答にはエラーを示す Notify ペイロードが含まれます。そのような応答を送信するかどうかの決定は, 認証された IKE SA が存在するかどうかに依存します。

応答パケットの解析または処理中にエラーが発生した場合, 一般規則は, エラー・メッセージを一切送信しないことです。なぜなら, 応答は新しい要求を生成すべきではないからです (そしてエラー・メッセージを送信する唯一の方法は新しい要求となります)。応答パケットの解析または処理中のこのようなエラーは, 受信側が IKE 状態をクリーンアップする (たとえば, 不正な SA に対する Delete の送信によって) ことを依然として引き起こすべきです。

認証失敗 (AUTHENTICATION_FAILED および EAP 失敗) と不正な形式のメッセージ (INVALID_SYNTAX) のみが, Delete ペイロードを伴う明示的な INFORMATIONAL 交換を必要とせずに IKE SA の削除をもたらします。他のエラー条件は, ポリシーがそれを必要とする場合, そのような交換を必要とするかもしれません (MAY)。交換が EAP Failure で終了した場合, AUTHENTICATION_FAILED 通知は送信されません。

2.21.1. IKE_SA_INIT でのエラー処理

暗号学的に保護された IKE SA が確立される前に発生するエラーは, 非常に注意して処理する必要があります。問題を診断するためにピアを支援してエラーに応答したいということと, 偽造されたメッセージに基づく DoS 攻撃の一部になることを回避したいということとの間には, トレードオフがあります。

IKE_SA_INIT 交換では, どのエラー通知も交換を失敗させます。COOKIE, INVALID_KE_PAYLOAD, INVALID_MAJOR_VERSION などの一部のエラー通知は, その後の成功した交換につながる可能性があることに注意してください。すべてのエラー通知は完全に非認証であるため, 受信側はあきらめる前にしばらくの間試行し続けるべきです。受信側は, COOKIE, INVALID_KE_PAYLOAD, INVALID_MAJOR_VERSION のように, この仕様で是正措置が定義されている場合を除き, エラー通知に基づいて直ちに行動すべきではありません。

2.21.2. IKE_AUTH でのエラー処理

IKE_AUTH 交換で発生し, どのような理由 (無効な共有鍵, 無効な ID, 信頼できない証明書発行者, 失効または期限切れの証明書など) であれ認証を失敗させるすべてのエラーは, AUTHENTICATION_FAILED 通知をもたらすべきです (SHOULD)。エラーがレスポンダで発生した場合, 通知は保護された応答で返され, 通常その応答の唯一のペイロードです。IKE_AUTH メッセージは暗号化され整合性保護されていますが, この通知を受信したピアがまだ他端を認証していない場合, そのピアはその情報を慎重に扱う必要があります。

エラーがイニシエータで発生した場合, 通知は, 通常他のペイロードなしで, 別個の INFORMATIONAL 交換で返されてもかまいません (MAY)。これは, 応答のエラーに基づいて新しい交換を開始しないという一般規則の例外です。

しかし, サポートされていないクリティカル・ペイロードを含む要求メッセージ, またはメッセージ全体が不正な形式である (単なる悪いペイロード内容ではなく) 要求メッセージは, 全体として拒否されなければならず (MUST), また UNSUPPORTED_CRITICAL_PAYLOAD または INVALID_SYNTAX 通知のみが応答として送信されるようにしなければならない (MUST) ことに注意してください。この場合, 受信側は認証関連のペイロードを検証すべきではありません。

IKE_AUTH 交換で認証が成功した場合, IKE SA は確立されます。しかし, Child SA の確立や設定情報の要求は依然として失敗する可能性があります。この失敗は, IKE SA が削除される原因とはなりません。具体的には, レスポンダは, 認証関連のすべてのペイロード (IDr, CERT, AUTH) を含みながら, ピギーバックされた交換 (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN など) のエラー通知を送信してもかまいません (MAY)。そしてイニシエータは, このため認証を失敗させてはならない (MUST NOT)。イニシエータは, もちろんポリシー上の理由でそのような IKE SA を後で削除してもかまいません (MAY)。

IKE_AUTH 交換において, またはそれに直後に続く INFORMATIONAL 交換において (IKE_AUTH への応答の処理中にエラーが発生した場合), UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, AUTHENTICATION_FAILED 通知は, Delete ペイロードなしで IKE SA を削除または作成しないようにする唯一の通知です。拡張文書はこれらのセマンティクスを持つ新しいエラー通知を定義してもかまいませんが, ピアがそれらを理解していることが示されない限り (たとえば Vendor ID ペイロードを使用することによって), 使用してはなりません (MUST NOT)。

2.21.3. IKE SA 認証後のエラー処理

IKE SA が認証された後は, エラーのある要求はすべて, そのエラーを通知する応答をもたらさなければなりません (MUST)。

通常の状況では, 一方のピアからの有効な応答が他方のピアでエラー状況を引き起こすような場合はあってはならず, したがって, 応答として以外にエラー・メッセージを送信する理由があってはなりません。そのようなエラー・メッセージを INFORMATIONAL 交換として送信すると, さらにエラーを引き起こしループを引き起こす可能性があるため, そのようなエラーは送信されるべきではありません (SHOULD NOT)。ピアが同じ状態を持っていないことを示すエラーが見られた場合, IKE SA を削除して状態をクリーンアップしやり直すことが良いかもしれません。

要求を解析したピアが, それがメッセージ認証コード・チェックとウィンドウ・チェックを通過した後で, ひどくフォーマットが不正であると気付き INVALID_SYNTAX 通知を返す場合, このエラー通知は両方のピアで致命的と見なされ, IKE SA が明示的な Delete ペイロードなしで削除されることを意味します。

2.21.4. IKE SA 外のエラー処理

ノードは, 保護されていないメッセージに応答して送信するメッセージのレートを制限する必要があります。

ノードが, それが既知の IKE SA のコンテキスト外の UDP ポート 500 または 4500 でメッセージを受信した場合 (そしてそのメッセージが IKE SA を開始する要求ではない場合), これはノードの最近のクラッシュの結果かもしれません。メッセージが応答としてマークされている場合, ノードはその疑わしいイベントを監査できますが, 応答してはなりません (MUST NOT)。メッセージが要求としてマークされている場合, ノードはその疑わしいイベントを監査でき, また応答を送信してもかまいません (MAY)。応答が送信される場合, 応答は, それが来た IP アドレスおよびポートに, 同じ IKE SPI およびコピーされた Message ID で送信されなければなります (MUST)。応答は暗号学的に保護されてはならず (MUST NOT), また INVALID_IKE_SPI Notify ペイロードを含まなければなりません (MUST)。INVALID_IKE_SPI 通知は, 認識されない宛先 SPI を持つ IKE メッセージを受信したことを示します。これは通常, 受信側が再起動し, IKE SA の存在を忘れたことを示します。

このような保護されていない Notify ペイロードを受信したピアは, 応答してはならず (MUST NOT), また既存の SA の状態を変更してはならない (MUST NOT)。そのメッセージは偽造されているか, または本物の通信相手がだまされて送信した応答かもしれません。ノードは, そのようなメッセージ (および ICMP 宛先到達不能のようなネットワーク・メッセージも) を, その IP アドレスへの SA に問題がある可能性があるというヒントとして扱い, そのような IKE SA のいずれかに対する活性確認を開始すべきです。実装は, DoS 攻撃に加担させられることを回避するために, そのようなテストの頻度を制限すべきです (SHOULD)。

エラーが IKE 要求のコンテキスト外で発生した場合 (たとえば, ノードが存在しない SPI で ESP メッセージを受信した場合), ノードは, その問題を説明する Notify ペイロードを伴う INFORMATIONAL 交換を開始すべきです (SHOULD)。

ノードが, それが IKE SA を持つ IP アドレス (および, NAT トラバーサルが使用される場合はポート) から疑わしいメッセージを受信した場合, その SA 上で IKE INFORMATIONAL 交換を通じて IKE Notify ペイロードを送信すべきです (SHOULD)。受信側は, 結果としていかなる SA の状態も変更してはならず (MUST NOT), ただし故障診断を支援するためにそのイベントを監査してもかまいません。