Security Considerations (安全考虑)

Security Considerations (安全考虑)

BGP 实现必须支持 RFC 2385 [RFC2385] 中指定的认证机制。此机制提供的认证可以按对等体进行。

BGP 使用 TCP 在对等路由器之间可靠地传输其流量。为了在点对点的基础上提供面向连接的完整性和数据源认证, BGP 指定使用 RFC 2385 中定义的机制。这些服务旨在检测和拒绝针对路由器间 TCP 连接的主动窃听攻击。如果不使用影响这些安全服务的机制, 攻击者可以破坏这些 TCP 连接和/或伪装成合法的对等路由器。由于 RFC 中定义的机制不提供对等实体认证, 这些连接可能会受到某些形式的重放攻击, 这些攻击在 TCP 层不会被检测到。此类攻击可能导致从 TCP 传递"损坏的"或"欺骗的" BGP 消息。

RFC 2385 中定义的机制通过一个 16 字节的消息认证码 (MAC) 增强了正常的 TCP 校验和, 该 MAC 是在与 TCP 校验和相同的数据上计算的。此 MAC 基于单向哈希函数 (MD5) 和密钥的使用。密钥在对等路由器之间共享, 用于生成攻击者在无法访问密钥的情况下不容易计算的 MAC 值。兼容的实现必须支持此机制, 并且必须允许网络管理员按对等体激活它。

RFC 2385 没有指定管理 (例如, 生成、分发和替换) 用于计算 MAC 的密钥的方法。RFC 3562 [RFC3562] (一份信息性文档) 在此领域提供了一些指导, 并提供了支持此指导的理由。它指出应该为与每个受保护对等体的通信使用不同的密钥。如果对多个对等体使用相同的密钥, 则提供的安全服务可能会降级, 例如, 由于一个路由器的密钥泄露风险增加, 从而对其他路由器产生不利影响。

用于 MAC 计算的密钥应该定期更改, 以最小化密钥泄露或成功密码分析攻击的影响。RFC 3562 建议密码周期 (使用密钥的间隔) 最多为 90 天。更频繁的密钥更改减少了重放攻击 (如上所述) 可行的可能性。但是, 如果没有一种标准机制以协调的方式在对等体之间实现此类更改, 则不能假设符合本 RFC 的 BGP-4 实现将支持频繁的密钥更改。

显然, 每个密钥也应该选择为对攻击者来说难以猜测。RFC 1750 中为随机数生成指定的技术为生成可以用作密钥的值提供了指南。RFC 2385 要求实现支持"由 80 字节或更少的可打印 ASCII 字符串组成"的密钥。RFC 3562 建议此上下文中使用的密钥应为 12 到 24 字节的随机 (伪随机) 位。这与类似 MAC 算法的建议相当一致, 这些算法通常使用 16 到 20 字节范围内的密钥。为了在此范围的低端提供足够的随机位, RFC 3562 还观察到典型的 ASCII 文本字符串必须接近 RFC 2385 中指定的密钥长度的上限。

BGP 漏洞分析在 [RFC4272] 中讨论。