2.21. Error Handling (错误处理)

IKE 处理过程中可能出现多种错误. 一般规则是: 若收到格式错误或因策略不可接受的请求 (例如无匹配的密码算法), 响应中应含指示错误的 Notify 载荷. 是否发送此类响应取决于是否存在已认证的 IKE SA.

若解析或处理响应分组出错, 一般规则是不回送任何错误消息, 因为响应不应产生新请求 (而新请求本是回送错误的唯一途径). 此类解析或处理响应的错误仍应促使接收方清理 IKE 状态 (例如对错误 SA 发送 Delete).

仅认证失败 (AUTHENTICATION_FAILED 与 EAP failure) 以及格式错误消息 (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, INVALID_KE_PAYLOAD 与 INVALID_MAJOR_VERSION), 否则接收方不应仅根据错误通知立即采取行动.

2.21.2. Error Handling in IKE_AUTH (IKE_AUTH 中的错误处理)

IKE_AUTH 交换中发生的所有导致认证失败的错误 (无效共享秘密, 无效 ID, 不可信证书颁发者, 吊销或过期证书等) 均应导致 AUTHENTICATION_FAILED 通知. 若错误发生在响应方, 通知在受保护的响应中返回, 且通常为该响应中的唯一载荷. 尽管 IKE_AUTH 消息已加密并完整性保护, 收到此通知的对等体若尚未认证另一端, 仍须谨慎对待该信息.

若错误发生在发起方, 通知可以在单独的 INFORMATIONAL 交换中返回, 通常无其他载荷. 这是对 "不因响应错误而启动新交换" 一般规则的例外.

但是, 含不支持的强制 (critical) 载荷的请求消息, 或整条消息格式错误 (而非仅载荷内容错误), 必须整体拒绝, 且必须仅导致以 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 交换中 (若在 processing 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 以清理状态并重新开始可能较好.

若对等体解析请求时发现其格式错误 (已通过消息认证码检查与窗口检查后) 并返回 INVALID_SYNTAX 通知, 则该错误通知对双方均视为致命, 即无需显式 Delete 载荷即删除 IKE SA.

2.21.4. Error Handling Outside IKE SA (IKE SA 之外的错误处理)

节点必须限制对未保护消息的响应发送速率.

若节点在 UDP 端口 500 或 4500 上收到其已知 IKE SA 上下文之外的消息 (且该消息不是启动 IKE SA 的请求), 可能是节点最近崩溃所致. 若消息标记为响应, 节点可以审计可疑事件, 但必须不响应. 若消息标记为请求, 节点可以审计可疑事件, 并可以发送响应. 若发送响应, 必须将响应发到来源 IP 地址与端口, 复制相同的 IKE SPI 与 Message ID. 响应不得经密码保护, 且必须包含 INVALID_IKE_SPI Notify 载荷. INVALID_IKE_SPI 通知表示收到的 IKE 消息目的 SPI 无法识别; 通常表示接收方已重启并忘记了某 IKE SA 的存在.

收到此类未保护 Notify 载荷的对等体必须不响应, 且不得改变任何现有 SA 的状态. 该消息可能是伪造, 也可能是真实通信方被诱骗发送的响应. 节点应将此类消息 (以及如 ICMP 目的不可达等网络消息) 视为与该 IP 地址的 SA 可能存在问题, 并对任何此类 IKE SA 启动存活检测. 实现应限制此类测试频率, 以免被诱骗参与 DoS 攻击.

若在 IKE 请求上下文之外发生错误 (例如节点收到不存在 SPI 上的 ESP 消息), 节点应启动带描述问题的 Notify 载荷的 INFORMATIONAL 交换.

节点若从与其存在 IKE SA 的 IP 地址 (若使用 NAT 遍历则还包括端口) 收到可疑消息, 应通过该 SA 上的 IKE INFORMATIONAL 交换发送 IKE Notify 载荷. 接收方不得因此改变任何 SA 的状态, 但可以审计该事件以协助诊断故障.