A Secure Way to Combine IPsec, NAT & DHCP - Computer Network Security - page 106

another IKE "main mode" and "quick mode" identifier (for example, user ID or fully
qualified domain name).
It may be of interest to note that IKE is a UDP based session layer protocol and is
not protected by network based IPsec security. Only a portion of the individual pay-
loads within IKE are protected. As a result, IKE sessions are permissible across NAT,
so long as IKE payload does not contain addresses and/or transport IDs specific to
one realm and not the other. Given that IKE is used to setup dynamic IPsec associa-
tions, the majority of current solutions propose a ways of making IPsec work through
a NAT function.
In the next section we explore some of those solutions that define how to combine
IPsec and NAT, and expose their limits.
3 Existing Solutions
End-to-end network layer security via IPsec cannot operate with an intervening NAT
device. One simple solution is to have a single device for performing NAT and IPsec
tunnelling. [28] is a useful resource that describes a security model with tunnel-mode
IPsec for NAT domains.
There are a variety of solutions being proposed for the NAT-IPsec compatibility
problem [1]. A number of them recommended as intermediate solutions pending the
wide-spread adoption of IPv6. Those solutions [1] are:
3.1 IPsec Tunnel Mode
In a limited set of circumstances, it is possible for an IPsec tunnel mode implementa-
tion, such as that described in [8], to traverse NA(P)T successfully [28]. However, the
requirements for successful traversal are sufficiently limited so that more general
solution must meet the following requirements [1]:
1. IPsec ESP . IPsec ESP tunnels do not cover the outer IP header within the message
integrity check, and so will not suffer Authentication Data invalidation due to ad-
dress translation. IPsec tunnels also need not be concerned about checksum invali-
dation.
2. No address validation . Most current IPsec tunnel mode implementations do not
perform source address validation so that incompatibilities between IKE identifiers
and source addresses will not be detected.
3. "Any to Any" SPD (Security Policy Database) entries . IPsec tunnel mode clients
can negotiate "any to any" SPDs, which are not invalidated by address translation.
This effectively precludes use of SPDs for the filtering of allowed tunnel traffic.
4. Single client operation . With only a single client behind a NAT, there is no risk of
overlapping SPDs. Since the NAT will not need to arbitrate between competing
clients, there is also no risk of re-key mis-translation, or improper incoming SPI or
cookie de-multiplexing.
5. Active sessions . Most VPN sessions typically maintain ongoing traffic flow during
their lifetime so that UDP port mappings are less likely be removed due to inactiv-
ity.