3. Requirements for IPsec-NAT Compatibility
3. Requirements for IPsec-NAT Compatibility
The goal of an IPsec-NAT compatibility solution is to expand the range of usable IPsec functionality beyond that available in the NAT-compatible IPsec tunnel mode solution described in Section 2.3.
In evaluating a solution to IPsec-NAT incompatibility, the following criteria should be kept in mind:
Deployment
Since IPv6 will address the address scarcity issues that frequently lead to use of NA(P)Ts with IPv4, the IPsec-NAT compatibility issue is a transitional problem that needs to be solved in the time frame prior to widespread deployment of IPv6. Therefore, to be useful, an IPsec-NAT compatibility solution MUST be deployable on a shorter time scale than IPv6.
Since IPv6 deployment requires changes to routers as well as hosts, a potential IPsec-NAT compatibility solution, which requires changes to both routers and hosts, will be deployable on approximately the same time scale as IPv6. Thus, an IPsec-NAT compatibility solution SHOULD require changes only to hosts, and not to routers.
Among other things, this implies that communication between the host and the NA(P)T SHOULD NOT be required by an IPsec-NAT compatibility solution, since that would require changes to the NA(P)Ts, and interoperability testing between the host and NA(P)T implementations. In order to enable deployment in the short term, it is necessary for the solution to work with existing router and NA(P)T products within the deployed infrastructure.
Protocol Compatibility
An IPsec NAT traversal solution is not expected to resolve issues with protocols that cannot traverse NA(P)T when unsecured with IPsec. Therefore, ALGs may still be needed for some protocols, even when an IPsec NAT traversal solution is available.
Security
Since NA(P)T directionality serves a security function, IPsec NA(P)T traversal solutions should not allow arbitrary incoming IPsec or IKE traffic from any IP address to be received by a host behind the NA(P)T, although mapping state should be maintained once bidirectional IKE and IPsec communication is established.
Telecommuter Scenario
Since one of the primary uses of IPsec is remote access to corporate Intranets, a NA(P)T traversal solution MUST support NA(P)T traversal, via either IPsec tunnel mode or L2TP over IPsec transport mode [RFC3193]. This includes support for traversal of more than one NA(P)T between the remote client and the VPN gateway.
The client may have a routable address and the VPN gateway may be behind at least one NA(P)T, or alternatively, both the client and the VPN gateway may be behind one or more NA(P)Ts. Telecommuters may use the same private IP address, each behind their own NA(P)T, or many telecommuters may reside on a private network behind the same NA(P)T, each with their own unique private address, connecting to the same VPN gateway. Since IKE uses UDP port 500 as the destination, it is not necessary to enable multiple VPN gateways operating behind the same external IP address.
Gateway-to-Gateway Scenario
In a gateway-gateway scenario, a privately addressed network (DMZ) may be inserted between the corporate network and the Internet. In this design, IPsec security gateways connecting portions of the corporate network may be resident in the DMZ and have private addresses on their external (DMZ) interfaces. A NA(P)T connects the DMZ network to the Internet.
End-to-End Scenario
A NAT-IPsec solution MUST enable secure host-host TCP/IP communication via IPsec, as well as host-gateway communications. A host on a private network MUST be able to bring up one or multiple IPsec-protected TCP connections or UDP sessions to another host with one or more NA(P)Ts between them. For example, NA(P)Ts may be deployed within branch offices connecting to the corporate network, with an additional NA(P)T connecting the corporate network to the Internet. Likewise, NA(P)Ts may be deployed within a corporate network LAN or WAN to connect wireless or remote location clients to the corporate network. This may require special processing of TCP and UDP traffic on the host.
Bringing up SCTP connections to another host with one or more NA(P)Ts between them may present special challenges. SCTP supports multi-homing. If more than one IP address is used, these addresses are transported as part of the SCTP packet during the association setup (in the INIT and INIT-ACK chunks). If only single homed SCTP end-points are used, [RFC2960] section 3.3.2.1 states:
Note that not using any IP address parameters in the INIT and
INIT-ACK is an alternative to make an association more likely
to work across a NAT box.
This implies that IP addresses should not be put into the SCTP packet unless necessary. If NATs are present and IP addresses are included, then association setup will fail. Recently [AddIP] has been proposed which allows the modification of the IP address once an association is established. The modification messages have also IP addresses in the SCTP packet, and so will be adversely affected by NATs.
Firewall Compatibility
Since firewalls are widely deployed, a NAT-IPsec compatibility solution MUST enable a firewall administrator to create simple, static access rule(s) to permit or deny IKE and IPsec NA(P)T traversal traffic. This implies, for example, that dynamic allocation of IKE or IPsec destination ports is to be avoided.
Scaling
An IPsec-NAT compatibility solution should be capable of being deployed within an installation consisting of thousands of telecommuters. In this situation, it is not possible to assume that only a single host is communicating with a given destination at a time. Thus, an IPsec-NAT compatibility solution MUST address the issue of overlapping SPD entries and de-multiplexing of incoming packets.
Mode Support
At a minimum, an IPsec-NAT compatibility solution MUST support traversal of the IKE and IPsec modes required for support within [RFC2409] and [RFC2401]. For example, an IPsec gateway MUST support ESP tunnel mode NA(P)T traversal, and an IPsec host MUST support IPsec transport mode NA(P)T traversal. The purpose of AH is to protect immutable fields within the IP header (including addresses), and NA(P)T translates addresses, invalidating the AH integrity check. As a result, NA(P)T and AH are fundamentally incompatible and there is no requirement that an IPsec-NAT compatibility solution support AH transport or tunnel mode.
Backward Compatibility and Interoperability
An IPsec-NAT compatibility solution MUST be interoperable with existing IKE/IPsec implementations, so that they can communicate where no NA(P)T is present. This implies that an IPsec-NAT compatibility solution MUST be backwards-compatible with IPsec as defined in [RFC2401] and IKE as defined in [RFC2409]. In addition, it SHOULD be able to detect the presence of a NA(P)T, so that NA(P)T traversal support is only used when necessary. This implies that it MUST be possible to determine that an existing IKE implementation does not support NA(P)T traversal, so that a standard IKE conversation can occur, as described in [RFC2407], [RFC2408], and [RFC2409]. Note that while this implies initiation of IKE to port 500, there is no requirement for a specific source port, so that UDP source port 500 may or may not be used.
Security
An IPsec-NAT compatibility solution MUST NOT introduce additional IKE or IPsec security vulnerabilities. For example, an acceptable solution must demonstrate that it introduces no new denial of service or spoofing vulnerabilities. IKE MUST be allowed to re-key in a bi-directional manner as described in [RFC2408].