11. Security Considerations (安全考量)

11. Security Considerations (安全考量)

与 NAT 相关的安全问题早已有文档记录. 见 RFC 2663 与 RFC 2993.

然而, 将 NAT 功能从 CPE 移至服务提供商网络核心并在客户之间共享 IPv4 地址, 在为滥用使用记录日志时会产生额外要求. 在任意 IPv4 地址不能唯一代表端主机的架构中, IPv4 地址与时间戳不再足以识别特定的宽带客户. AFTR 应该具备记录 tunnel-id, 协议, 端口/IP 地址以及 NAT 绑定创建时间的能力, 以唯一标识用户会话. 究竟记录哪些内容的准确细节取决于实现, 不在本文档范围之内.

AFTR 对使用 RFC 1918 地址或 IANA 保留地址范围 (192.0.0.0/29) 的内部 IPv4 主机执行转换功能. 在某些情况下, ISP 可能在 AFTR 中配置策略, 并指示 AFTR 基于 IPv4 Address, port number, protocol 元组绕过转换功能. 当 AFTR 收到来自内部主机且与策略信息匹配的分组时, AFTR 可以简单地转发该分组而不进行转换. 地址, 端口与协议信息必须在收到分组之前已在 AFTR 上配置. 配置机制不在本规范范围之内.

解封装分组时, AFTR 必须仅转发源为 RFC 1918 地址, IANA 保留地址范围或任何其他带外预授权地址的分组. AFTR 必须丢弃所有其他分组. 这可防止恶意设备在 IPv4 源首部字段中使用未授权的公有 IPv4 地址或在 IPv4 传输首部字段中使用未授权的传输端口范围发起拒绝服务攻击. 例如, 恶意设备可能通过发起 TCP SYN ACK 攻击 (RFC 4987) 轰炸某公共 Web 服务器. 受害者将以极快的速率收到来自随机 IPv4 源的 TCP SYN, 从而拒绝向合法用户提供 TCP 服务.

在多个用户共享 IPv4 地址的情况下, 端口成为关键资源. 因此, AFTR 需要实施某些机制来限制端口使用, 要么对新连接进行速率限制, 要么对单个用户可使用的最大端口数设置硬限制. 若该数值足够高, 则不应干扰正常使用, 同时仍为共享池提供合理保护. 关于共享 IPv4 地址的更多考量见 RFC 6269. 关于日志的其他考量与建议见 RFC 6302.

AFTR 应该支持将业务仅限制给已注册客户的方式. 一种简单选项是在 AFTR 的隧道接口上实施 IPv6 入向过滤, 仅接受过滤器中定义的 IPv6 地址范围.