2.21. 错误处理

在 IKE 处理过程中可能发生多种错误。一般规则是, 如果收到的请求格式错误, 或者由于策略原因 (例如没有匹配的密码算法) 不可接受, 响应包含一个指示错误的 Notify 载荷。是否发送这样的响应取决于是否存在已认证的 IKE SA。

如果在解析或处理响应数据包时发生错误, 一般规则是不发回任何错误消息, 因为响应不应生成新的请求 (而发回错误消息的唯一方式将是一个新的请求)。在解析或处理响应数据包中的此类错误仍应导致接收方清理 IKE 状态 (例如, 通过为坏 SA 发送一个 Delete)。

只有认证失败 (AUTHENTICATION_FAILED 和 EAP 失败) 和格式错误的消息 (INVALID_SYNTAX) 会导致 IKE SA 被删除, 而不需要携带 Delete 载荷的显式 INFORMATIONAL 交换。如果策略规定需要, 其他错误条件可能 (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, 不可信的证书颁发者, 吊销或过期的证书等) 导致认证失败, 应 (SHOULD) 导致 AUTHENTICATION_FAILED 通知。如果错误发生在响应方, 该通知在受保护的响应中返回, 并且通常是该响应中唯一的载荷。尽管 IKE_AUTH 消息是加密和完整性保护的, 如果接收此通知的对端尚未认证另一端, 该对端需要谨慎对待该信息。

如果错误发生在发起方, 该通知可以 (MAY) 在单独的 INFORMATIONAL 交换中返回, 通常没有其他载荷。这是不对基于响应中的错误启动新交换的一般规则的例外。

但请注意, 包含不受支持的关键载荷的请求消息, 或者整个消息格式错误 (而不是仅仅是坏的载荷内容) 的请求消息, 必须 (MUST) 被整体拒绝, 并且必须 (MUST) 仅导致一个 UNSUPPORTED_CRITICAL_PAYLOAD 或 INVALID_SYNTAX 通知作为响应发送。在这种情况下, 接收方不应验证与认证相关的载荷。

如果在 IKE_AUTH 交换中认证成功, IKE SA 即已建立; 但是, 建立 Child SA 或请求配置信息仍可能失败。此失败不会自动导致 IKE SA 被删除。具体来说, 响应方可以 (MAY) 包含与认证相关的所有载荷 (IDr, CERT 和 AUTH), 同时针对捎带的交换 (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN 等) 发送错误通知, 而发起方必须 (MUST NOT) 因此使认证失败。发起方当然可以 (MAY) 出于策略原因稍后删除这样的 IKE SA。

在 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 之外的错误处理

一个节点需要限制它响应未受保护的消息而发送消息的速率。

如果一个节点在 UDP 端口 500 或 4500 上接收到一条消息, 该消息不在它已知的 IKE SA 的上下文中 (并且该消息不是开始一个 IKE SA 的请求), 这可能是该节点最近崩溃的结果。如果该消息被标记为响应, 节点可以审计该可疑事件但必须 (MUST NOT) 响应。如果该消息被标记为请求, 节点可以审计该可疑事件并可以 (MAY) 发送响应。如果发送了响应, 该响应必须 (MUST) 发送到它来自的 IP 地址和端口, 并复制相同的 IKE SPI 和消息 ID。该响应必须 (MUST NOT) 受密码学保护, 并且必须 (MUST) 包含一个 INVALID_IKE_SPI Notify 载荷。INVALID_IKE_SPI 通知指示收到一个带有无法识别的目标 SPI 的 IKE 消息; 这通常表示接收方已重启并忘记了某个 IKE SA 的存在。

接收此类未受保护 Notify 载荷的对端必须 (MUST NOT) 响应, 并且必须 (MUST NOT) 更改任何现有 SA 的状态。该消息可能是伪造的, 也可能是真正的通信方被骗发送的响应。一个节点应将该消息 (以及像 ICMP 目的不可达这样的网络消息) 视为一个提示: 到该 IP 地址的 SA 可能存在问题, 并且应发起对任何此类 IKE SA 的活动性检查。一个实现应 (SHOULD) 限制此类测试的频率, 以避免被骗参与 DoS 攻击。

如果错误发生在 IKE 请求的上下文之外 (例如, 节点在一个不存在的 SPI 上收到 ESP 消息), 节点应 (SHOULD) 发起一个带有描述该问题的 Notify 载荷的 INFORMATIONAL 交换。

一个节点从它拥有 IKE SA 的 IP 地址 (以及端口, 如果使用 NAT 穿越) 接收到一个可疑消息, 应 (SHOULD) 在该 SA 上通过 IKE INFORMATIONAL 交换发送一个 IKE Notify 载荷。接收方必须 (MUST NOT) 因此更改任何 SA 的状态, 但可以审计该事件以辅助诊断故障。