5. IPsec Configuration Details
This section describes the SPD entries for setting up the IPsec
transport mode SA to protect the IPv6 traffic.
Several requirements arise when IPsec is used to protect the IPv6
traffic (inner header) for the scenarios listed in Section 3.
1. All of IPv6 traffic should be protected, including link-local
(e.g., Neighbor Discovery) and multicast traffic. Without this,
an attacker can pollute the IPv6 neighbor cache causing
disruption in communication between the two routers.
2. In router-to-router tunnels, the source and destination addresses
of the traffic could come from a wide range of prefixes that are
normally learned through routing. As routing can always learn a
new prefix, one cannot assume that all the prefixes are known a
priori [RFC3884]. This mainly affects scenario (1).
3. Source address selection depends on the notions of routes and
interfaces. This implies that the reachability to the various
IPv6 destinations appear as routes in the routing table. This
affects scenarios (2) and (3).
The IPv6 traffic can be protected using transport or tunnel mode.
There are many problems when using tunnel mode as implementations may
or may not model the IPsec tunnel mode SA as an interface as
described in Appendix A.1.
If IPsec tunnel mode SA is not modeled as an interface (e.g., as of
this writing, popular in many open source implementations), the SPD
entries for protecting all traffic between the two endpoints must be
described. Evaluating against the requirements above, all link-local
traffic multicast traffic would need to be identified, possibly
resulting in a long list of SPD entries. The second requirement is
difficult to satisfy, because the traffic needing protection is not
necessarily (e.g., router-to-router tunnel) known a priori [RFC3884].
The third requirement is also problematic, because almost all
implementations assume addresses are assigned on interfaces (rather
than configured in SPDs) for proper source address selection.
If the IPsec tunnel mode SA is modeled as interface, the traffic that
needs protection can be modeled as routes pointing to the interface.
But the second requirement is difficult to satisfy, because the
traffic needing protection is not necessarily known a priori. The
third requirement is easily solved, because IPsec is modeled as an
interface.
In practice, (2) has been solved by protecting all the traffic
(::/0), but no interoperable implementations support this feature.
For a detailed list of issues pertaining to this, see [VLINK].
Because applying transport mode to protect a tunnel is a much simpler
solution and also easily protects link-local and multicast traffic,
we do not recommend using tunnel mode in this context. Tunnel mode
is, however, discussed further in Appendix A.
This document assumes that tunnels are manually configured on both
sides and the ingress filtering is manually set up to discard spoofed
packets.
Transport mode has typically been applied to L2TP, GRE, and other
tunneling methods, especially when the user wants to tunnel non-IP
traffic. [RFC3884], [RFC3193], and [RFC4023] provide examples of
applying transport mode to protect tunnel traffic that spans only a
part of an end-to-end path.
IPv6 ingress filtering must be applied on the tunnel interface on all
the packets that pass the inbound IPsec processing.
The following SPD entries assume that there are two routers, Router1
and Router2, with tunnel endpoint IPv4 addresses denoted IPV4-TEP1
and IPV4-TEP2, respectively. (In other scenarios, the SPDs are set
up similarly.)
Router1's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP1 IPV4-TEP2 ESP BYPASS
2 IPV4-TEP1 IPV4-TEP2 IKE BYPASS
3 IPv4-TEP1 IPV4-TEP2 41 PROTECT(ESP,transport)
Router2's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP2 IPV4-TEP1 ESP BYPASS
2 IPV4-TEP2 IPV4-TEP1 IKE BYPASS
3 IPv4-TEP2 IPV4-TEP1 41 PROTECT(ESP,transport)
In both SPD entries, "IKE" refers to UDP destination port 500
and possibly also port 4500 if NAT traversal is used.
The packet format is as shown in Table 1.
+----------------------------+------------------------------------+
| Components (first to last) | Contains |
+----------------------------+------------------------------------+
| IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) |
| ESP header | |
| IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) |
| (payload) | |
+----------------------------+------------------------------------+
Table 1: Packet Format for IPv6/IPv4 Tunnels.
The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2,
and protocol value 41 as phase 2 identities. With IKEv2, the traffic
selectors are used to carry the same information.
The Peer Authorization Database (PAD) provides the link between SPD
and the key management daemon [RFC4306]. This is defined in
[RFC4301] and hence relevant only when used with IKEv2.
As there is currently no defined way to discover the PAD-related
parameters dynamically, it is assumed that these are manually
configured:
o The Identity of the peer asserted in the IKEv2 exchange: Many
different types of identities can be used. At least, the IPv4
address of the peer should be supported.
o IKEv2 can authenticate the peer by several methods. Pre-shared
key and X.509 certificate-based authentication is required by
[RFC4301]. At least, pre-shared key should be supported, because
it interoperates with a larger number of implementations.
o The child SA authorization data should contain the IPv4 address of
the peer.
IPv4 address should be supported as Identity during the key exchange.
As this does not provide Identity protection, main mode or aggressive
mode can be used with IKEv1.
