安全考虑

安全考虑 (Security Considerations)

BGP implementation MUST 支持 RFC 2385 [RFC2385] 中规定的 authentication mechanism. 该机制提供的 authentication 可以按每个 peer 进行.

BGP 使用 TCP 在 peer router 之间可靠传输其 traffic. 为在 point-to-point 基础上提供 connection-oriented integrity 和 data origin authentication, BGP 规定使用 RFC 2385 中定义的机制. 这些服务旨在检测并拒绝针对 inter-router TCP connection 的 active wiretapping attack. 如果不使用实现这些安全服务的机制, attacker 可能干扰这些 TCP connection, 和/或冒充合法 peer router. 由于该 RFC 中定义的机制不提供 peer entity authentication, 这些 connection 可能暴露于某些 TCP layer 无法检测的 replay attack. 此类攻击可能导致 TCP 交付 "broken" 或 "spoofed" BGP message.

RFC 2385 中定义的机制通过 16-byte message authentication code (MAC) 扩展普通 TCP checksum, 该 MAC 基于与 TCP checksum 相同的数据计算. 此 MAC 基于 one-way hash function (MD5) 和 secret key 的使用. 该 key 在 peer router 之间共享, 用于生成没有该 key 的 attacker 难以计算的 MAC 值. conforming implementation 必须支持此机制, 并且必须允许 network administrator 按每个 peer 启用它.

RFC 2385 未规定用于管理 (例如生成, 分发和替换) 计算 MAC 所用 key 的方法. RFC 3562 [RFC3562] (informative document) 在这一领域提供了一些指导, 并给出了支持这些指导的理由. 需要注意, 与每个受保护 peer 通信时应使用不同 key. 如果同一 key 用于多个 peer, 所提供的安全服务可能受损, 例如某台 router 被攻陷的风险增加并对其他 router 产生不利影响.

用于 MAC 计算的 key 应定期更换, 以最小化 key compromise 或成功 cryptanalytic attack 的影响. RFC 3562 建议 cryptoperiod (key 使用的时间间隔) 不超过 90 天. 更频繁的 key change 会降低 replay attack (如上所述) 可行的可能性. 然而, 在没有标准机制用于在 peer 之间协调此类变更的情况下, 不能假定符合本 RFC 的 BGP-4 implementation 支持频繁 key change.

显然, 每个 key 也应选择为 attacker 难以猜测的值. RFC 1750 中规定的 random number generation 技术为生成可用作 key 的值提供了指导. RFC 2385 要求 implementation 支持 "由 80 byte 或更少 printable ASCII 字符组成" 的 key. RFC 3562 建议此上下文中使用的 key 应为 12 到 24 byte 的 random (pseudo-random) bit. 这与类似 MAC algorithm 的建议相当一致, 后者通常使用 16 到 20 byte 范围内的 key. 为在该范围较低端提供足够 random bit, RFC 3562 还指出, 典型 ASCII text string 必须接近 RFC 2385 规定 key length 的上限.

BGP vulnerability analysis 在 [RFC4272] 中讨论.