Information Technology Reference
In-Depth Information
3.2 RSIP
Described in [3] and [4], includes mechanisms for IPsec traversal, as described in
[23]. By enabling host-NA(P)T communication, RSIP addresses issues of IPsec SPI
de-multiplexing, as well as SPD overlap. By enabling hosts behind a NAT to share
the external IP address of the NA(P)T (the RSIP gateway), this approach is compati-
ble with protocols including embedded IP addresses. By tunnelling IKE and IPsec
packets, RSIP avoids changes to the IKE and IPsec protocols, although major changes
are required to host IKE and IPsec implementations to retrofit them for RSIP-
compatibility. It is thus compatible with all existing protocols (AH/ESP) and modes
(transport and tunnel). In order to handle de-multiplexing of IKE re-keys, RSIP re-
quires floating of the IKE source port, as well as re-keying to the floated port. As a
result, interoperability with existing IPsec implementations is not assured. RSIP does
not satisfy the deployment requirements for an IPsec-NAT compatibility solution
because an RSIP-enabled host requires a corresponding RSIP-enabled gateway in
order to establish an IPsec SA with another host. Since RSIP requires changes only to
clients and routers and not to servers, it is less difficult to deploy than IPv6 [1].
3.3 6to4
6to4, as described in [5] can form the basis for an IPsec-NAT traversal solution. In
this approach, the NAT provides IPv6 hosts with an IPv6 prefix derived from the
NAT external IPv4 address, and encapsulates IPv6 packets in IPv4 for transmission to
other 6to4 hosts or 6to4 relays. This enables an IPv6 host using IPsec to communicate
freely to other hosts within the IPv6 or 6to4 clouds. While 6to4 is an elegant and
robust solution where a single NA(P)T separates a client and VPN gateway, it is not
universally applicable. Since 6to4 requires the assignment of a routable IPv4 address
to the NA(P)T in order to allow formation of an IPv6 prefix, it is not usable where
multiple NA(P)Ts exist between the client and VPN gateway. For example, NA(P)T
with a private address on its external interface cannot be used by clients behind it to
obtain an IPv6 prefix via 6to4. While 6to4 requires little additional support from hosts
that already support IPv6, it does require changes to NATs, which need to be up-
graded to support 6to4. As a result, 6to4 may not be suitable for deployment in the
short term [1].
3.4 NAT-Traversal in the IKE
[21] describes how to detect one or more Network Address Translation devices
(NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of
IPsec packets [16] through NAT boxes in IKE.
For NAT Traversal to work properly, two things must occur. First, the communi-
cating VPN devices must support the same method of UDP encapsulation. Second, all
NAT devices along the communication path must be identified.
According to [21], IPsec devices will exchange a specific, known value to deter-
mine whether or not they both support NAT Traversal. If the two VPN devices agree
on NAT Traversal, they next determine whether or not NAT or NAPT occurs any-
where on the communications path between them.
