idnits 2.17.1 draft-ietf-v6ops-ipsec-tunnels-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 944. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 968. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 15, 2007) is 6305 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2893 (Obsoleted by RFC 4213) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations WG R. Graveman 3 Internet-Draft RFG Security, LLC 4 Intended status: Informational M. Parthasarathy 5 Expires: July 19, 2007 Nokia 6 P. Savola 7 CSC/FUNET 8 H. Tschofenig 9 Siemens 10 January 15, 2007 12 Using IPsec to Secure IPv6-in-IPv4 Tunnels 13 draft-ietf-v6ops-ipsec-tunnels-05.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July 19, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document gives guidance on securing manually configured IPv6-in- 47 IPv4 tunnels using IPsec in Transport Mode. No additional protocol 48 extensions are described beyond those available with the IPsec 49 framework. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3 55 2.1. IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4 56 2.2. IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 5 57 3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 5 59 3.2. Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 6 60 3.3. Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 8 61 4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 8 62 5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 9 63 5.1. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 10 64 5.2. Peer Authorization Database and Identities . . . . . . . . 12 65 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 72 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 73 Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 15 74 A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 16 75 A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 17 76 A.3. Specific SPD for Host-to-Router scenario . . . . . . . . . 17 77 Appendix B. Optional Features . . . . . . . . . . . . . . . . . . 18 78 B.1. Dynamic Address Configuration . . . . . . . . . . . . . . 18 79 B.2. NAT Traversal and Mobility . . . . . . . . . . . . . . . . 18 80 B.3. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 82 Intellectual Property and Copyright Statements . . . . . . . . . . 22 84 1. Introduction 86 The IPv6 operations (v6ops) working group has selected (manually 87 configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6 88 transition mechanisms for IPv6 deployment. 90 [RFC4213] identified a number of threats that had not been adequately 91 analyzed or addressed in its predecessor [RFC2893]. The most 92 complete solution is to use IPsec to protect IPv6-in-IPv4 tunneling. 93 The document was intentionally not expanded to include the details on 94 how to set up an IPsec-protected tunnel in an interoperable manner, 95 but instead the details were deferred to this memo. 97 First four sections of this document analyze the threats and 98 scenarios that can be addressed by IPsec and assumptions made by this 99 document for successful IPsec Security Association (SA) 100 establishment. Section 5 gives the details of Internet Key Exchange 101 (IKE) and IP security (IPsec) exchange with packet formats and 102 Security Policy Database (SPD) entries. Section 6 gives 103 recommendations. Appendices further discuss tunnel mode usage and 104 optional extensions. 106 This document does not address the use of IPsec for tunnels that are 107 not manually configured (e.g., 6to4 tunnels [RFC3056]). Presumably, 108 some form of opportunistic encryption or "better-than-nothing 109 security" might or might not be applicable. Similarly, propagating 110 quality of service attributes (apart from Explicit Congestion 111 Notification bits [RFC4213]) from the encapsulated packets to the 112 tunnel path is out of scope. 114 The use of the word "interface" or the phrase "IP interface" refers 115 to the IPv6 interface that must be present on any IPv6 node to send 116 or receive IPv6 packets. The use of the phrase "tunnel interface" 117 refers to the interface that receives the IPv6-in-IPv4 tunneled 118 packets over IPv4. 120 2. Threats and the Use of IPsec 122 [RFC4213] is mostly concerned about address spoofing threats: 124 1. The IPv4 source address of the encapsulating ("outer") packet can 125 be spoofed. 127 2. The IPv6 source address of the encapsulated ("inner") packet can 128 be spoofed. 130 The reason threat (1) exists is the lack of universal deployment of 131 IPv4 ingress filtering [RFC3704]. The reason threat (2) exists is 132 that the IPv6 packet is encapsulated in IPv4 and hence may escape 133 IPv6 ingress filtering. [RFC4213] specifies the following strict 134 address checks as mitigating measures: 136 o To mitigate threat (1), the decapsulator verifies that the IPv4 137 source address of the packet is the same as the address of the 138 configured tunnel endpoint. The decapsulator may also implement 139 IPv4 ingress filtering, i.e., check whether the packet is received 140 on a legitimate interface. 142 o To mitigate threat (2), the decapsulator verifies whether the 143 inner IPv6 address is a valid IPv6 address and also applies IPv6 144 ingress filtering before accepting the IPv6 packet. 146 This memo proposes using IPsec for providing stronger security in 147 preventing these threats and additionally providing integrity, 148 confidentiality, replay protection, and origin protection between 149 tunnel endpoints. 151 IPsec can be used in two ways, in transport and tunnel mode; detailed 152 discussion about applicability in this context is provided in 153 Section 5. 155 2.1. IPsec in Transport Mode 157 In transport mode, the IPsec Encapsulating Security Payload (ESP) or 158 Authentication Header (AH) security association (SA) is established 159 to protect the traffic defined by (IPv4-source, IPv4-dest, protocol = 160 41). On receiving such an IPsec packet, the receiver first applies 161 the IPsec transform (e.g., ESP) and then matches the packet against 162 the Security Parameter Index (SPI) and the inbound selectors 163 associated with the SA to verify that the packet is appropriate for 164 the SA via which it was received. A successful verification implies 165 that the packet came from the right IPv4 endpoint, because the SA is 166 bound to the IPv4 source address. 168 This prevents threat (1) but not the threat (2). IPsec in transport 169 mode does not verify the contents of the payload itself where the 170 IPv6 addresses are carried. That is, two nodes using IPsec transport 171 mode to secure the tunnel can spoof the inner payload. The packet 172 will be decapsulated successfully and accepted. 174 This shortcoming can be partially mitigated by IPv6 ingress filtering 175 i.e., check that the packet is arriving from the interface in the 176 direction of the route towards the tunnel end-point, similar to a 177 Strict Reverse Path Forwarding (RPF) check [RFC3704]. 179 In most implementations, a transport mode SA is applied to a normal 180 IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in 181 the tunnel interface. (Transport mode is often also used in other 182 kind of tunnels such as GRE [RFC4023] and L2TP [RFC3193].) 184 2.2. IPsec in Tunnel Mode 186 In tunnel mode, the IPsec SA is established to protect the traffic 187 defined by (IPv6-source, IPv6-destination). On receiving such an 188 IPsec packet, the receiver first applies the IPsec transform (e.g., 189 ESP) and then matches the packet against the SPI and the inbound 190 selectors associated with the SA to verify that the packet is 191 appropriate for the SA via which it was received. The successful 192 verification implies that the packet came from the right endpoint. 194 The outer IPv4 addresses may be spoofed and IPsec cannot detect this 195 in tunnel mode; the packets will be demultiplexed based on the SPI 196 and possibly the IPv6 address bound to the SA. Thus, the outer 197 address spoofing is irrelevant as long as the decryption succeeds and 198 the inner IPv6 packet can be verified to come from the right tunnel 199 endpoint. 201 As described in Section 5, using tunnel mode is more difficult than 202 applying transport mode to a tunnel interface, and as a result this 203 document recommends transport mode. Note that even though transport 204 rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnel 205 specified by Protocol 41 still exists. 207 3. Scenarios and Overview 209 There are roughly three scenarios: 211 1. (generic) router-to-router tunnels. 213 2. site-to-router or router-to-site tunnels. These refer to tunnels 214 between a site's IPv6 (border) device and an IPv6 upstream 215 provider's router. A degenerate case of a site is a single host. 217 3. Host-to-host tunnels. 219 3.1. Router-to-Router Tunnels 221 IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of 222 IPv4 forwarding topology by encapsulating them within IPv4 packets. 223 Tunneling can be used in a variety of ways. 225 .--------. _----_ .--------. 226 |v6-in-v4| _( IPv4 )_ |v6-in-v4| 227 | Router | <======( Internet )=====> | Router | 228 | A | (_ _) | B | 229 '--------' '----' '--------' 230 ^ IPsec tunnel between ^ 231 | Router A and Router B | 232 V V 234 Figure 1: Router-to-Router Scenario. 236 IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel 237 IPv6 packets between themselves. In this case, the tunnel spans one 238 segment of the end-to-end path that the IPv6 packet takes. 240 The source and destination addresses of the IPv6 packets traversing 241 the tunnel could come from a wide range of IPv6 prefixes, so binding 242 IPv6 addresses to be used to the SA is not generally feasible. IPv6 243 ingress filtering must be performed to mitigate the IPv6 address 244 spoofing threat. 246 A specific case of router-to-router tunnels, when one router resides 247 at an end site, is described in the next section. 249 3.2. Site-to-Router/Router-to-Site Tunnels 251 This is a generalization of host-to-router and router-to-host 252 tunneling, because the issues when connecting a whole site (using a 253 router), and connecting a single host are roughly equal. 255 _----_ .---------. IPsec _----_ IPsec .-------. 256 _( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 | 257 ( Internet )<--->| Router |<=======( Internet )=======>| Site B | 258 (_ _) | A | (_ _) '--------' 259 '----' '---------' '----' 260 ^ 261 | 262 V 263 .--------. 264 | Native | 265 | IPv6 | 266 | node | 267 '--------' 269 Figure 2: Router-to-Site Scenario. 271 IPv6/IPv4 routers can tunnel IPv6 packets to their final destination 272 IPv6/IPv4 site. This tunnel spans only the last segment of the end- 273 to-end path. 275 +---------------------+ 276 | IPv6 Network | 277 | | 278 .--------. _----_ | .--------. | 279 | V6/V4 | _( IPv4 )_ | |v6-in-v4| | 280 | Site B |<====( Internet )==========>| Router | | 281 '--------' (_ _) | | A | | 282 '----' | '--------' | 283 IPsec tunnel between | ^ | 284 IPv6 Site and Router A | | | 285 | V | 286 | .-------. | 287 | | V6 | | 288 | | Hosts | | 289 | '--------' | 290 +---------------------+ 292 Figure 3: Site-to-Router Scenario. 294 In the other direction, IPv6/IPv4 hosts can tunnel IPv6 packets to an 295 intermediary IPv6/IPv4 router that is reachable via an IPv4 296 infrastructure. This type of tunnel spans the first segment of the 297 packet's end-to-end path. 299 The hosts in the site originate the packets with IPv6 source 300 addresses coming from a well known prefix, whereas the destination 301 addresses could be any nodes on the Internet. 303 In this case, an IPsec tunnel mode SA could be bound to the prefix 304 that was allocated to the router at Site B, and router A could verify 305 that the source address of the packet matches the prefix. Site B 306 will not be able to do a similar verification for the packets it 307 receives. This may be quite reasonable for most of the deployment 308 cases, for example, an Internet Service Provider (ISP) allocating a 309 /48 to a customer. The Customer Premises Equipment (CPE) where the 310 tunnel is terminated "trusts" (in a weak sense) the ISP's router, and 311 the ISP's router can verify that Site B is the only one that can 312 originate packets within the /48. 314 IPv6 spoofing must be prevented, and setting up ingress filtering may 315 require some amount of manual configuration; see more of these 316 options in Section 5. 318 3.3. Host-to-Host Tunnels 320 .--------. _----_ .--------. 321 | V6/V4 | _( IPv4 )_ | V6/V4 | 322 | Host | <======( Internet )=====> | Host | 323 | A | (_ _) | B | 324 '--------' '----' '--------' 325 IPsec tunnel between 326 Host A and Host B 328 Figure 4: Host-to-Host Scenario. 330 IPv6/IPv4 hosts interconnected by an IPv4 infrastructure can tunnel 331 IPv6 packets between themselves. In this case, the tunnel spans the 332 entire end-to-end path. 334 In this case, the source and the destination IPv6 addresses are known 335 a priori. A tunnel mode SA could be bound to these specific 336 addresses. Address verification prevents IPv6 source address 337 spoofing completely. 339 As noted in the Introduction, automatic host-to-host tunneling 340 methods (e.g., 6to4) are out of scope for this memo. 342 4. IKE and IPsec Versions 344 This section discusses the different versions of the IKE and IPsec 345 security architecture and their applicability to this document. 347 The IPsec security architecture was previously defined in [RFC2401] 348 and is now superseded by [RFC4301]. IKE was originally defined in 349 [RFC2409] (which is called IKEv1 in this document) and is now 350 superseded by [RFC4306] (called IKEv2; see also [RFC4718]). There 351 are several differences between them. The differences relevant to 352 this document are discussed below. 354 1. [RFC2401] does not require allowing IP as the next layer protocol 355 in traffic selectors when an IPsec SA is negotiated. In 356 contrast, [RFC4301] requires supporting IP as the next layer 357 protocol (like TCP or UDP) in traffic selectors. 359 2. [RFC4301] assumes IKEv2, as some of the new features cannot be 360 negotiated using IKEv1. It is valid to negotiate multiple 361 traffic selectors for a given IPsec SA in [RFC4301]. This is 362 possible only with IKEv2. If IKEv1 is used, then multiple SAs 363 need to be set up, one for each traffic selector. 365 Note that the existing implementations based on IKEv1 may already be 366 able to support the [RFC4301] features described in (1) and (2). If 367 appropriate, the deployment may choose to use either version of the 368 security architecture. 370 IKEv2 supports features useful for configuring and securing tunnels 371 not present with IKEv1. 373 1. IKEv2 supports legacy authentication methods by carrying them in 374 EAP payloads. This can be used to authenticate hosts or sites to 375 an ISP using EAP methods that support username and password. 377 2. IKEv2 supports dynamic address configuration, which may be used 378 to configure the IPv6 address of the host. 380 NAT traversal works with both the old and revised IPsec 381 architectures, but the negotiation is integrated with IKEv2. 383 For the purposes of this document, where the confidentiality of ESP 384 [RFC4303] is not required, AH [RFC4302] can be used as an alternative 385 to ESP. The main difference is that AH is able to provide integrity 386 protection for certain fields in the outer IPv4 header and IPv4 387 options. However, as the outer IPv4 header will be discarded in any 388 case, and those particular fields are not believed to be relevant in 389 this particular application, there is no particular reason to use AH. 391 5. IPsec Configuration Details 393 The following section describes the SPD entries for setting up the 394 IPsec transport mode SA to protect the IPv6 traffic. 396 Several requirements arise when IPsec is used to protect the IPv6 397 traffic (inner header) for the scenarios listed in Section 3. 399 1. All of IPv6 traffic should be protected, including link-local 400 (e.g., Neighbor Discovery) and multicast traffic. Without this, 401 an attacker can pollute the IPv6 neighbor cache causing 402 disruption in communication between the two routers. 404 2. In router-to-router tunnels, the source and destination addresses 405 of the traffic could come from a wide range of prefixes that are 406 normally learned through routing. As routing can always learn a 407 new prefix, one cannot assume that all the prefixes are known a 408 priori [RFC3884]. This mainly affects scenario (1). 410 3. Source address selection depends on the notions of routes and 411 interfaces. This implies that the reachability to the various 412 IPv6 destinations appear as routes in the routing table. This 413 affects scenarios (2) and (3). 415 The IPv6 traffic can be protected using transport or tunnel mode. 416 There are many problems when using tunnel mode as implementations may 417 or may not model the IPsec tunnel mode SA as an interface as 418 described in Appendix A.1. 420 If IPsec tunnel mode SA is not modeled as an interface (e.g., as of 421 this writing, popular in many open source implementations), the SPD 422 entries for protecting all traffic between the two endpoints must be 423 described. Evaluating against the requirements above, all link-local 424 traffic multicast traffic would need to be identified, possibly 425 resulting in a long list of SPD entries. The second requirement is 426 difficult to satisfy, because the traffic needing protection is not 427 necessarily (e.g., router-to-router tunnel) known a priori [RFC3884]. 428 The third requirement is also problematic, because almost all 429 implementations assume addresses are assigned on interfaces (rather 430 than configured in SPDs) for proper source address selection. 432 If the IPsec tunnel mode SA is modeled as interface, the traffic that 433 needs protection can be modeled as routes pointing to the interface. 434 But the second requirement is difficult to satisfy, because the 435 traffic needing protection is not necessarily known a priori. The 436 third requirement is easily solved, because IPsec is modeled as an 437 interface. 439 In practice, (2) has been solved by protecting all the traffic 440 (::/0), but no inter-operable implementations support this feature. 441 For a detailed list of issues pertaining to this, see 442 [I-D.duffy-ppvpn-ipsec-vlink]. 444 Because applying transport mode to protect a tunnel is a much simpler 445 solution and also easily protects link-local and multicast traffic, 446 we do not recommend using tunnel mode in this context. Tunnel mode 447 is, however, discussed further in Appendix A. 449 This document assumes that tunnels are manually configured on both 450 sides and the ingress filtering is manually setup to discard spoofed 451 packets. 453 5.1. IPsec Transport Mode 455 Transport mode has typically been applied to L2TP, GRE, and other 456 tunneling methods, especially when the user wants to tunnel non-IP 457 traffic. [RFC3884], [RFC3193], and [RFC4023] provide examples of 458 applying transport mode to protect tunnel traffic that spans only a 459 part of an end-to-end path. 461 IPv6 ingress filtering must be applied on the tunnel interface on all 462 the packets that pass the inbound IPsec processing. 464 The following SPD entries assume that there are two routers, Router1 465 and Router2, with tunnel endpoint IPv4 addresses denoted IPV4-TEP1 466 and IPV4-TEP2, respectively. (In other scenarios, the SPDs are set 467 up similarly.) 469 Router1's SPD: 470 Next Layer 471 Rule Local Remote Protocol Action 472 ---- ----- ------ ---------- -------- 473 1 IPV4-TEP1 IPV4-TEP2 ESP BYPASS 474 2 IPV4-TEP1 IPV4-TEP2 IKE BYPASS 475 3 IPv4-TEP1 IPV4-TEP2 41 PROTECT(ESP,transport) 477 Router2's SPD: 478 Next Layer 479 Rule Local Remote Protocol Action 480 ---- ----- ------ ---------- -------- 481 1 IPV4-TEP2 IPV4-TEP1 ESP BYPASS 482 2 IPV4-TEP2 IPV4-TEP1 IKE BYPASS 483 3 IPv4-TEP2 IPV4-TEP1 41 PROTECT(ESP,transport) 485 In both SPD entries, "IKE" refers to UDP destination port 500 486 and possibly also port 4500 if NAT traversal is used. 488 The packet format is as shown in Table 1. 490 +----------------------------+------------------------------------+ 491 | Components (first to last) | Contains | 492 +----------------------------+------------------------------------+ 493 | IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) | 494 | ESP header | | 495 | IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) | 496 | (payload) | | 497 +----------------------------+------------------------------------+ 499 Table 1: Packet Format for IPv6/IPv4 Tunnels. 501 The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2, 502 and protocol value 41 as phase 2 identities. With IKEv2, the traffic 503 selectors are used to carry the same information. 505 5.2. Peer Authorization Database and Identities 507 The Peer Authorization Database (PAD) provides the link between SPD 508 and the key management daemon [RFC4306]. This is defined in 509 [RFC4301] and hence relevant only when used with IKEv2. 511 As there is no currently defined way to discover the PAD-related 512 parameters dynamically, it is assumed that these are manually 513 configured: 515 o The Identity of the peer asserted in the IKEv2 exchange: Many 516 different types of identities can be used. At least, the IPv4 517 address of the peer should be supported. 519 o IKEv2 can authenticate the peer by several methods. Pre-shared 520 key and X.509 certificate-based authentication is required by 521 [RFC4301]. At least, pre-shared key should be supported, because 522 it interoperates with a larger number of implementations. 524 o The child SA authorization data should contain the IPv4 address of 525 the peer. 527 IPv4 address should be supported as Identity during the key exchange. 528 As this not provide Identity protection, main mode or aggressive mode 529 can be used with IKEv1. 531 6. Recommendations 533 In Section 5, we examined the differences between setting up an IPsec 534 IPv6-in-IPv4 tunnel using either transport or tunnel mode. We 535 observe that applying transport mode to a tunnel interface is the 536 simplest and therefore recommended solution. 538 In Appendix A, we also explore what it would take to use so-called 539 Specific SPD (SSPD) tunnel mode. Such usage is more complicated 540 because IPv6 prefixes need to be known a priori and multicast and 541 link-local traffic do not work over such a tunnel. Fragment handling 542 in tunnel mode is also more difficult. However, because MOBIKE 543 [RFC4555] supports only tunnel mode, when the IPv4 endpoints of a 544 tunnel are dynamic and the other constraints are not applicable, 545 using tunnel mode may be an acceptable solution. 547 Therefore our primary recommendation is to use transport mode applied 548 to a tunnel interface. Source address spoofing can be limited by 549 enabling ingress filtering on the tunnel interface. 551 Manual keying must not be used as large amounts of IPv6 traffic may 552 be carried over the tunnels and doing so would make it easier for an 553 attacker to recover the keys. IKEv1 or IKEv2 must be used for 554 establishing the IPsec SAs. IKEv2 should be used where supported and 555 available; if not, IKEv1 may be used instead. 557 7. IANA Considerations 559 This memo makes no request to IANA. [[ RFC-editor: please remove this 560 section prior to publication. ]] 562 8. Security Considerations 564 When running IPv6-in-IPv4 tunnels (unsecured) over the Internet, it 565 is possible to "inject" packets into the tunnel by spoofing the 566 source address (data plane security), or if the tunnel is signaled 567 somehow (e.g., using authentication protocol and obtaining a static 568 v6 prefix), someone might be able to spoof the signaling (control 569 plane security). 571 The IPsec framework plays an important role in adding security to 572 both the protocol for tunnel setup and data traffic. 574 Either IKEv1 or IKEv2 provides a secure signaling protocol for 575 establishing, maintaining, and deleting an IPsec tunnel. 577 IPsec, with ESP, offers integrity and data origin authentication, 578 confidentiality, and optional (at the discretion of the receiver) 579 anti-replay features. Using confidentiality without integrity is 580 discouraged. ESP furthermore provides limited traffic flow 581 confidentiality. 583 IPsec provides access control mechanisms through the distribution of 584 keys and also through the application of policies dictated by the 585 Security Policy Database (SPD). 587 The NAT traversal mechanism provided by IKEv2 introduces some 588 weaknesses into IKE and IPsec. These issues are discussed in more 589 detail in [RFC4306]. 591 Please note that using IPsec for the scenarios described in Figure 3, 592 Figure 2 and Figure 1 does not aim to protect the end-to-end 593 communication. It protects just the tunnel part. It is still 594 possible for an IPv6 endpoint not attached to the IPsec tunnel to 595 spoof packets. 597 9. Contributors 599 The authors are listed in alphabetical order. 601 Suresh Satapati also participated in the initial discussions on this 602 topic. 604 10. Acknowledgments 606 The authors would like to thank Stephen Kent, Michael Richardson, 607 Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, Alfred 608 Hoenes, Francis Dupont, and David Black for their substantive 609 feedback. 611 We would like to thank Pasi Eronen for his text contributions and 612 suggestions for improvement. 614 11. References 616 11.1. Normative References 618 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 619 Internet Protocol", RFC 2401, November 1998. 621 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 622 (IKE)", RFC 2409, November 1998. 624 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 625 Networks", BCP 84, RFC 3704, March 2004. 627 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 628 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 629 RFC 3948, January 2005. 631 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 632 for IPv6 Hosts and Routers", RFC 4213, October 2005. 634 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 635 Internet Protocol", RFC 4301, December 2005. 637 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 638 RFC 4303, December 2005. 640 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 641 RFC 4306, December 2005. 643 11.2. Informative References 645 [I-D.duffy-ppvpn-ipsec-vlink] 646 Duffy, M., "Framework for IPsec Protected Virtual Links 647 for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in 648 progress), October 2002. 650 [I-D.palet-v6ops-tun-auto-disc] 651 Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point 652 Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-03 653 (work in progress), January 2005. 655 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 656 IPv6 Hosts and Routers", RFC 2893, August 2000. 658 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 659 via IPv4 Clouds", RFC 3056, February 2001. 661 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 662 "Securing L2TP using IPsec", RFC 3193, November 2001. 664 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 665 (NAT) Compatibility Requirements", RFC 3715, March 2004. 667 [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec 668 Transport Mode for Dynamic Routing", RFC 3884, 669 September 2004. 671 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 672 MPLS in IP or Generic Routing Encapsulation (GRE)", 673 RFC 4023, March 2005. 675 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 676 December 2005. 678 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 679 (MOBIKE)", RFC 4555, June 2006. 681 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 682 Implementation Guidelines", RFC 4718, October 2006. 684 Appendix A. Using Tunnel Mode 686 First, we describe the different tunnel mode implementation methods. 687 We note that, in this context, only the so-called Specific SPD (SSPD) 688 model (without a tunnel interface) can be made to work, but it has 689 reduced applicability, and the use of a transport mode tunnel is 690 recommended instead. However, we will describe how the SSPD Tunnel 691 Mode might look if one would like to use it in any case. 693 A.1. Tunnel Mode Implementation Methods 695 Tunnel mode could (in theory) be deployed in two very different ways 696 depending on the implementation: 698 1. "Generic SPDs": some implementations model the tunnel mode SA as 699 an IP interface. In this case, an IPsec tunnel interface is 700 created and used with "any" addresses ("::/0 <-> ::/0" ) as IPsec 701 traffic selectors while setting up the SA. Though this allows 702 all traffic between the two nodes to be protected by IPsec, the 703 routing table would decide what traffic gets sent over the 704 tunnel. Ingress filtering must be separately applied on the 705 tunnel interface as the IPsec policy checks do not check the IPv6 706 addresses at all. Routing protocols, multicast, etc. will work 707 through this tunnel. This mode is similar to transport mode. 708 The SPDs must be interface-specific. However, because IKE uses 709 IPv4 but the tunnel is IPv6, there is no standard solution to map 710 the IPv4 interface to IPv6 interface 711 [I-D.duffy-ppvpn-ipsec-vlink] and this approach is not feasible. 713 2. "Specific SPDs": some implementations do not model the tunnel 714 mode SA as an IP interface. Traffic selection is based on 715 specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8: 716 2::/48". As the IPsec session between two endpoints does not 717 have an interface (though an implementation may have a common 718 pseudo-interface for all IPsec traffic), there is no DAD, MLD, or 719 link-local traffic to protect; multicast is not possible over 720 such a tunnel. Ingress filtering is performed automatically by 721 the IPsec traffic selectors. 723 Ingress filtering is guaranteed by IPsec processing when option (2) 724 is chosen, whereas the operator has to enable it explicitly when 725 transport mode or option (1) is chosen. 727 In summary, there does not appear to be a standard solution in this 728 context for the first implementation approach. 730 The second approach can be made to work, but is only applicable in 731 host-to-host or site-to-router/router-to-site scenarios (i.e., when 732 the IPv6 prefixes can be known a priori), and it offers only a 733 limited set of features (e.g., no multicast) compared with a 734 transport mode tunnel. 736 When tunnel mode is used, fragment handling [RFC4301] may also be 737 more difficult compared with transport mode and, depending on 738 implementation, may need to be reflected in SPDs. 740 A.2. Specific SPD for Host-to-Host Scenario 742 The following SPD entries assume that there are two hosts, Host1 and 743 Host2, whose IPv6 addresses are denoted IPV6-EP1 and IPV6-EP2 (global 744 addresses), and the IPV4 addresses of the tunnel endpoints are 745 denoted IPV4-TEP1 and IPV4-TEP2, respectively. 747 Host1's SPD: 748 Next Layer 749 Rule Local Remote Protocol Action 750 ---- ----- ------ ---------- -------- 751 1 IPV6-EP1 IPV6-EP2 ESP BYPASS 752 2 IPV6-EP1 IPV6-EP2 IKE BYPASS 753 3 IPv6-EP1 IPV6-EP2 41 PROTECT(ESP, 754 tunnel{IPV4-TEP1,IPV4-TEP2}) 756 Host2's SPD: 757 Next Layer 758 Rule Local Remote Protocol Action 759 ---- ----- ------ ---------- -------- 760 1 IPV6-EP2 IPV6-EP1 ESP BYPASS 761 2 IPV6-EP2 IPV6-EP1 IKE BYPASS 762 3 IPv6-EP2 IPV6-EP1 41 PROTECT(ESP, 763 tunnel{IPV4-TEP2,IPV4-TEP1}) 765 "IKE" refers to UDP destination port 500 and possibly also 766 port 4500 if NAT traversal is used. 768 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 769 as phase 2 identities. With IKEv2, the traffic selectors are used to 770 carry the same information. 772 A.3. Specific SPD for Host-to-Router scenario 774 The following SPD entries assume that the host has the IPv6 address 775 IPV6-EP1 and the tunnel end points of the host and router are IPV4- 776 TEP1 and IPV4-TEP2 respectively. If the tunnel is between a router 777 and a host where the router has allocated a IPV6-PREF/48 to the host, 778 the corresponding SPD entries can be derived by replacing IPV6-EP1 779 with IPV6-PREF/48. 781 Please note the bypass entry for host's SPD, absent in router's SPD. 782 While this might be an implementation matter for host-to-router 783 tunneling, having a similar entry, "Local=IPV6-PREF/48 & Remote=IPV6- 784 PREF/48" is critical for site-to-router tunneling. 786 Host's SPD: 787 Next Layer 788 Rule Local Remote Protocol Action 789 ---- ----- ------ ---------- -------- 790 1 IPV6-EP1 IPV6-EP2 ESP BYPASS 791 2 IPV6-EP1 IPV6-EP2 IKE BYPASS 792 3 IPV6-EP1 IPV6-EP1 ANY BYPASS 793 4 IPV6-EP1 ANY ANY PROTECT(ESP, 794 tunnel{IPV4-TEP1,IPV4-TEP2}) 796 Router's SPD: 797 Next Layer 798 Rule Local Remote Protocol Action 799 ---- ----- ------ ---------- -------- 800 1 IPV6-EP2 IPV6-EP1 ESP BYPASS 801 2 IPV6-EP2 IPV6-EP1 IKE BYPASS 802 3 ANY IPV6-EP1 ANY PROTECT(ESP, 803 tunnel{IPV4-TEP1,IPV4-TEP2}) 805 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and 806 ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as their phase 2 807 identities. The starting address is zero and the end address is all 808 ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address 809 and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With 810 IKEv2, the traffic selectors are used to carry the same information. 812 Appendix B. Optional Features 814 B.1. Dynamic Address Configuration 816 With the exchange of protected configuration payloads, IKEv2 is able 817 to provide the IKEv2 peer with DHCP-like information payloads. These 818 configuration payloads are exchanged between the IKEv2 initiator and 819 responder. 821 This could be used (for example) by the host in the host-to-router 822 scenario to obtain an IPv6 address from the ISP as part of setting up 823 the IPsec tunnel mode SA. The details of these procedures are out of 824 scope for this memo. 826 B.2. NAT Traversal and Mobility 828 Network address (and port) translation devices are commonly found in 829 today's networks. A detailed description of the problem of IPsec- 830 protected data traffic traversing a NAT including requirements are 831 discussed in [RFC3715]. 833 IKEv2 can detect the presence of a NAT automatically by sending 834 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in 835 the initial IKE_SA_INIT exchange. Once a NAT is detected and both 836 end points support IPsec NAT traversal extensions, UDP encapsulation 837 can be enabled. 839 More details about UDP encapsulation of IPsec-protected IP packets 840 can be found in [RFC3948]. 842 For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two 843 reasons: 845 1. One of the tunnel endpoints is often behind a NAT, and configured 846 tunneling, using protocol 41, is not guaranteed to traverse the 847 NAT. Hence, using IPsec tunnels would enable one to set up both 848 a secure tunnel and a tunnel that might not always be possible 849 without other tunneling mechanisms. 851 2. Using NAT traversal allows the outer address to change without 852 having to renegotiate the SAs. This could be beneficial for a 853 crude form of mobility and in scenarios where the NAT changes the 854 IP addresses frequently. However, as the outer address may 855 change, this might introduce new security issues, and using 856 tunnel mode would be most appropriate. 858 When NAT is not applied, the second benefit would still be desirable. 859 In particular, using manually configured tunneling is an operational 860 challenge with dynamic IP addresses, because both ends need to be 861 reconfigured if an address changes. Therefore, an easy and efficient 862 way to re-establish the IPsec tunnel if the IP address changes would 863 be desirable. MOBIKE [RFC4555] provides a solution when IKEv2 is 864 used, but it only supports tunnel mode. 866 B.3. Tunnel Endpoint Discovery 868 The IKEv2 initiator needs to know the address of the IKEv2 responder 869 to start IKEv2 signaling. A number of ways can be used to provide 870 the initiator with this information, for example: 872 o Using out-of-band mechanisms, e.g., from the ISP's web page. 874 o Using DNS to look up a service name by appending it to the DNS 875 search path provided by DHCPv4 (e.g. "tunnel- 876 service.example.com"). 878 o Using a DHCP option. 880 o Using a pre-configured or pre-determined IPv4 anycast address. 882 o Using other, unspecified or proprietary methods. 884 For the purpose of this document it is assumed that this address can 885 be obtained somehow. Once the address has been learned, it is 886 configured as the tunnel end-point for the configured IPv6-in-IPv4 887 tunnel. 889 This problem is also discussed at more length in 890 [I-D.palet-v6ops-tun-auto-disc]. 892 However, simply discovering the tunnel endpoint is not sufficient for 893 establishing an IKE session with the peer. The PAD information (see 894 Section 5.2) also needs to be learned dynamically. Hence, currently, 895 automatic endpoint discovery provides benefit only if PAD information 896 is chosen in such a manner that it is not IP-address specific. 898 Authors' Addresses 900 Richard Graveman 901 RFG Security, LLC 902 15 Park Avenue 903 Morristown, New Jersey 07960 904 USA 906 Email: rfg@acm.org 908 Mohan Parthasarathy 909 Nokia 910 313 Fairchild Drive 911 Mountain View CA-94043 912 USA 914 Email: mohanp@sbcglobal.net 916 Pekka Savola 917 CSC/FUNET 918 Espoo 919 Finland 921 Email: psavola@funet.fi 922 Hannes Tschofenig 923 Siemens 924 Otto-Hahn-Ring 6 925 Munich, Bayern 81739 926 Germany 928 Email: Hannes.Tschofenig@siemens.com 930 Full Copyright Statement 932 Copyright (C) The IETF Trust (2007). 934 This document is subject to the rights, licenses and restrictions 935 contained in BCP 78, and except as set forth therein, the authors 936 retain all their rights. 938 This document and the information contained herein are provided on an 939 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 940 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 941 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 942 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 943 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 944 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 946 Intellectual Property 948 The IETF takes no position regarding the validity or scope of any 949 Intellectual Property Rights or other rights that might be claimed to 950 pertain to the implementation or use of the technology described in 951 this document or the extent to which any license under such rights 952 might or might not be available; nor does it represent that it has 953 made any independent effort to identify any such rights. Information 954 on the procedures with respect to rights in RFC documents can be 955 found in BCP 78 and BCP 79. 957 Copies of IPR disclosures made to the IETF Secretariat and any 958 assurances of licenses to be made available, or the result of an 959 attempt made to obtain a general license or permission for the use of 960 such proprietary rights by implementers or users of this 961 specification can be obtained from the IETF on-line IPR repository at 962 http://www.ietf.org/ipr. 964 The IETF invites any interested party to bring to its attention any 965 copyrights, patents or patent applications, or other proprietary 966 rights that may cover technology that may be required to implement 967 this standard. Please address the information to the IETF at 968 ietf-ipr@ietf.org. 970 Acknowledgment 972 Funding for the RFC Editor function is provided by the IETF 973 Administrative Support Activity (IASA).