Information Technology Reference
In-Depth Information
trates our proposed solution for assuring the end-to-end security using IPsec in the
NAT/DHCP environment and validates it using an automatic protocol analyser called
Hermes. Section 5 presents some security consideration related to our solution. Sec-
tion 6 concludes this paper and gives directions for future work.
2 IPSEC/NAT Incompatibilities
This section describes known incompatibilities between NAT and IPsec. The use of
IPsec, or any other security protocol with "NAT" which uses IP addresses as part of a
SA (Security Association), for communications that span multiple routing realms is
problematic. NATs clearly limit the scope where IPsec could be applicable (or vice
versa, IPsec could limit the scope where NATs could be applicable). IPsec techniques
which are intended to preserve the endpoint addresses of an IP packet will not work
with NAT enroute for most applications in practice [29]. Techniques such as AH
(Authentication Header) [19] and ESP in tunnel mode (Encapsulation Security Pay-
load) [20] protect the contents of the IP headers (including the source and destination
addresses) from modification. Yet, NAT's fundamental role is to alter the addresses in
the IP header of a packet. IPsec supports two "modes". Transport mode provides end-
to-end security between hosts, while tunnel mode protects encapsulated IP packets
between security gateways.
In IPsec transport mode, both AH and ESP have an integrity check covering the
entire payload. When the payload is TCP [26] or UDP [25], the TCP/UDP checksum
is covered by the integrity check. When a NAT device modifies an address the check-
sum is no longer valid with respect to the new address. Normally, NAT also updates
the checksum, but this is ineffective when AH and ESP are used. Consequently, re-
ceivers will discard a packet either because it fails the IPsec integrity check (if the
NAT device updates the checksum), or because the checksum is invalid (if the NAT
device leaves the checksum unmodified).
Note that IPsec tunnel mode ESP is permissible so long as the embedded packet
contents are unaffected by the outer IP header translation. If the transport endpoint is
under our control, we might be able to turn off checksum verification. In other words,
ESP can pass through NAT in tunnel mode, or in transport mode with TCP check-
sums disabled or ignored by the receiver. IPsec tunnel mode AH doesn't suite NAT
because whole packet is authenticated (including header) hence leaving no space for
NAT to modify the IP header. Thus, co-existence of NAT and IPsec (using AH) in
either of the operational modes is not feasible due to functional architecture of AH. If
we stick to ESP in tunnel mode or turn off checksums, there's still another obstacle:
the IKE (Internet Key Exchange) [14].
IPsec-based VPNs (Virtual Private Networks) use IKE to automate security asso-
ciation setup and authenticate endpoints. The most basic and common method of
authentication in use today is preshared key. Unfortunately, this method depends upon
the source IP address of the packet. If NAT is inserted between endpoints, the outer
source IP address will be translated into the address of the NAT router, and no longer
identify the originating security gateway. To avoid this problem, it is possible to use
Search WWH ::




Custom Search