12. Security Considerations (安全考虑事项)

12. Security Considerations (安全考虑事项)

据信, 在使用控制平面过程获取 EID-to-RLOC 映射时, 大多数安全机制将成为映射数据库服务的一部分。对于本规范中描述的数据平面触发的映射, 通过使用路由可返回性 (参见第 3 节) 机制来提供针对 ETR 欺骗的保护, 通过在 LISP 封装头部中使用 24 位 'Nonce' 字段和在 LISP 控制消息中使用 64 位 'Nonce' 字段来证明。

nonce 加上 ITR 仅接受请求的 Map-Reply, 提供了基本的安全级别, 在许多方面类似于当前互联网路由系统中经历的安全性。路径外攻击者很难针对这些 LISP 机制发起攻击, 因为他们没有 nonce 值。发送大量数据包以意外找到正确的 nonce 值是可能的, 但这本身就是拒绝服务 (DoS) 攻击。路径内攻击者可以执行更严重的攻击, 但路径内攻击者也可以在当前互联网中发起严重攻击, 包括窃听、阻止或重定向流量。有关此主题的更多讨论, 请参见第 6.1.5.1 节。

LISP 不依赖于 PKI 或更重量级的认证系统。这些系统挑战了 LISP 的主要设计目标之一 - 可扩展性。

DoS 攻击预防将取决于实现对控制平面的 Map-Request 和 Map-Reply 以及数据触发的 Map-Reply 数量进行速率限制。

实现不正确或恶意的 ITR 可能选择忽略 ETR 在其 Map-Reply 中提供的 Priority 和 Weight。这种流量导向将限于此 ITR 站点发送的流量, 并不比站点在 ETR 的入口链路之一上发起带宽 DoS 攻击更严重。ITR 的站点通常不会从不遵守 Weight 中获得任何好处, 并且通过遵守它们可能会获得更好的服务。

为了处理 ITR/PITR 中的 map-cache 耗尽尝试, 实现应考虑对存储的条目数量设置最大上限, 并为特殊或频繁访问的站点保留列表。这应该是由管理 ITR 和 PITR 的网络管理员设置的配置策略控制。当跨多个 Map-Cache 条目出现重叠的 EID-Prefix 时, 必须完全维护集合的完整性。因此, 如果由于达到最大上限而无法添加更具体的条目, 则不应将任何不太具体的条目存储在 map-cache 中。

鉴于 ITR/PITR 维护 EID-to-RLOC 映射的缓存, 缓存大小和维护是实现期间要记住的问题。安装仪器以检测缓存抖动是一个好主意。实现实验将用于确定哪些缓存管理策略效果最好。一般来说, 很难防御缓存抖动攻击。应该注意的是, ITR/PITR 中缓存过小不仅会对其支持的站点或区域造成不利影响, 还可能导致映射系统上的 Map-Request 负载增加。

第 6.1.3 节中讨论的 "Piggybacked (背负)" 映射数据指定了如何处理此类映射, 并包括 ETR 在 "受信任" 环境中运行时在验证前临时接受此类映射的可能性。在这种情况下, 存在一个潜在威胁, 即可能将虚假映射插入 (即使只是短时间) map-cache 中。如第 6.1.3 节所述, ETR 必须专门配置为在此类模式下运行, 并且可能仅将某些特定 ITR 视为也在同一受信任环境中运行。

ETR 生成它们正在响应的 EID-Prefix 这一事实中存在安全风险。ETR 可以声称比其实际负责的前缀更短。改善或解决此问题的各种机制将在未来进行研究 [LISP-SEC]。

LISP 封装数据包的内部头部地址欺骗是可能的, 就像任何隧道机制一样。ITR 必须在封装之前验证数据包的源地址是否属于站点 EID-Prefix 范围的 EID。ETR 必须仅解封装和转发内部头部目标与其 EID-Prefix 范围之一匹配的数据报。如果在接收和解封装时, 数据报的目标 EID 与 ETR 配置的 EID-Prefix 之一不匹配, 则 ETR 必须丢弃该数据报。如果 LISP 封装的数据包到达 ETR, 它应该将内部头部源 EID 地址和外部头部源 RLOC 地址与映射数据库中存在的映射进行比较。然后, 当发生欺骗攻击时, 可以使用外部头部源 RLOC 地址使用现有操作工具将攻击追溯到源站点。

此实验规范不涉及自动密钥管理 (AKM)。BCP 107 [RFC4107] 在此领域提供了指导。此外, 在撰写本文时, 正在进行大量工作以改善路由系统的安全性 [RFC6518] [RFC6480] [BGP-SEC] [LISP-SEC]。未来关于 LISP 的工作应解决 BCP 107 中讨论的问题以及其他开放的安全考虑, 这可能需要对本规范进行更改。