11. Security Considerations
11. Security Considerations
Security issues associated with NAT have long been documented. See [RFC2663] and [RFC2993].
However, moving the NAT functionality from the CPE to the core of the service provider network and sharing IPv4 addresses among customers create additional requirements when logging data for abuse usage. With any architecture where an IPv4 address does not uniquely represent an end host, IPv4 addresses and timestamps are no longer sufficient to identify a particular broadband customer. The AFTR should have the capability to log the tunnel-id, protocol, ports/IP addresses, and the creation time of the NAT binding to uniquely identify the user sessions. Exact details of what is logged are implementation specific and out of scope for this document.
The AFTR performs translation functions for interior IPv4 hosts using RFC 1918 addresses or the IANA reserved address range (192.0.0.0/29). In some circumstances, an ISP may provision policies in the AFTR and instruct the AFTR to bypass translation functions based on <IPv4 Address, port number, protocol>. When the AFTR receives a packet with matching information of the policy from the interior host, the AFTR can simply forward the packet without translation. The addresses, ports, and protocol information must be provisioned on the AFTR before receiving the packet. The provisioning mechanism is out of scope for this specification.
When decapsulating packets, the AFTR MUST only forward packets sourced by RFC 1918 addresses, an IANA reserved address range, or any other out-of-band pre-authorized addresses. The AFTR MUST drop all other packets. This prevents rogue devices from launching denial-of-service attacks using unauthorized public IPv4 addresses in the IPv4 source header field or an unauthorized transport port range in the IPv4 transport header field. For example, rogue devices could bombard a public web server by launching a TCP SYN ACK attack [RFC4987]. The victim will receive TCP SYN from random IPv4 source addresses at a rapid rate and deny TCP services to legitimate users.
With IPv4 addresses shared by multiple users, ports become a critical resource. As such, some mechanisms need to be put in place by an AFTR to limit port usage, either by rate-limiting new connections or putting a hard limit on the maximum number of ports usable by a single user. If this number is high enough, it should not interfere with normal usage and still provide reasonable protection of the shared pool. More considerations on sharing IPv4 addresses can be found in [RFC6269]. Other considerations and recommendations on logging can be found in [RFC6302].
AFTRs should support ways to limit service only to registered customers. One simple option is to implement an IPv6 ingress filter on the AFTR's tunnel interface to accept only the IPv6 address range defined in the filter.