idnits 2.17.1 draft-ietf-v6ops-ipsec-tunnels-04.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 928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 952. 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 (November 21, 2006) is 6359 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: May 25, 2007 Nokia 6 P. Savola 7 CSC/FUNET 8 H. Tschofenig 9 Siemens 10 November 21, 2006 12 Using IPsec to Secure IPv6-in-IPv4 Tunnels 13 draft-ietf-v6ops-ipsec-tunnels-04.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 May 25, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2006). 44 Abstract 46 This document gives guidance on securing manually configured IPv6-in- 47 IPv4 tunnels using IPsec. No additional protocol extensions are 48 described beyond those available with the IPsec framework. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3 54 2.1. IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4 55 2.2. IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 5 56 3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 5 58 3.2. Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 6 59 3.3. Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 8 60 4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 8 61 5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 9 62 5.1. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 10 63 5.2. IPsec Tunnel Mode . . . . . . . . . . . . . . . . . . . . 10 64 5.3. Peer Authorization Database . . . . . . . . . . . . . . . 12 65 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 72 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 73 Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 15 74 A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 15 75 A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 16 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 analyse 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 2. Threats and the Use of IPsec 116 [RFC4213] is mostly concerned about address spoofing threats: 118 1. The IPv4 source address of the encapsulating ("outer") packet can 119 be spoofed. 121 2. The IPv6 source address of the encapsulated ("inner") packet can 122 be spoofed. 124 IPsec can obviously also provide payload integrity, replay detection, 125 and confidentiality as well for the part of the end-to-end path that 126 is tunneled. 128 The reason threat (1) exists is the lack of widespread deployment of 129 IPv4 ingress filtering [RFC3704]. The reason threat (2) exists is 130 that the IPv6 packet is encapsulated in IPv4 and hence may escape 131 IPv6 ingress filtering. [RFC4213] specifies the following strict 132 address checks as mitigating measures: 134 o To mitigate threat (1), the decapsulator verifies that the IPv4 135 source address of the packet is the same as the address of the 136 configured tunnel endpoint. The decapsulator may also implement 137 IPv4 ingress filtering, i.e., check whether the packet is received 138 on a legitimate interface. 140 o To mitigate threat (2), the decapsulator verifies whether the 141 inner IPv6 address is a valid IPv6 address and also applies IPv6 142 ingress filtering before accepting the IPv6 packet. 144 This memo proposes using IPsec for providing stronger security in 145 preventing these threats and additionally providing integrity and 146 confidentiality. 148 IPsec can be used in two ways, in transport and tunnel mode; detailed 149 discussion about applicability in this context is provided in 150 Section 5. 152 2.1. IPsec in Transport Mode 154 In transport mode, the IPsec Encapsulating Security Payload (ESP) or 155 Authentication Header (AH) security association (SA) is established 156 to protect the traffic defined by (IPv4-source, IPv4-dest, protocol = 157 41). On receiving such an IPsec packet, the receiver first applies 158 the IPsec transform (e.g., ESP) and then matches the packet against 159 the Security Parameter Index (SPI) and the inbound selectors 160 associated with the SA to verify that the packet is appropriate for 161 the SA via which it was received. A successful verification implies 162 that the packet came from the right IPv4 endpoint, because the SA is 163 bound to the IPv4 source address. 165 This prevents threat (1) but not the threat (2). IPsec in transport 166 mode does not verify the contents of the payload itself where the 167 IPv6 addresses are carried. That is, two nodes using IPsec transport 168 mode to secure the tunnel can spoof the inner payload. The packet 169 will be decapsulated successfully and accepted. 171 This shortcoming can be partially mitigated by IPv6 ingress filtering 172 i.e., check that the packet is arriving from the interface in the 173 direction of the route towards the tunnel end-point, similar to a 174 Strict Reverse Path Forwarding (RPF) check [RFC3704]. 176 In most implementations, a transport mode SA is applied to a normal 177 IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in 178 the tunnel interface. (Transport mode is often also used in other 179 kind of tunnels such as GRE [RFC4023] and L2TP [RFC3193].) 181 2.2. IPsec in Tunnel Mode 183 In tunnel mode, the IPsec SA is established to protect the traffic 184 defined by (IPv6-source, IPv6-destination). On receiving such an 185 IPsec packet, the receiver first applies the IPsec transform (e.g., 186 ESP) and then matches the packet against the SPI and the inbound 187 selectors associated with the SA to verify that the packet is 188 appropriate for the SA via which it was received. The successful 189 verification implies that the packet came from the right endpoint. 191 The outer IPv4 addresses may be spoofed and IPsec cannot detect this 192 in tunnel mode; the packets will be demultiplexed based on the SPI 193 and possibly the IPv6 address bound to the SA. Thus, the outer 194 address spoofing is irrelevant as long as the decryption succeeds and 195 the inner IPv6 packet can be verified to come from the right tunnel 196 endpoint. 198 As described in Section 5.2, using tunnel mode is more difficult than 199 applying transport mode to a tunnel interface, and as a result this 200 document recommends transport mode. Note that even though transport 201 rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnel 202 specified by Protocol 41 still exists. 204 3. Scenarios and Overview 206 There are roughly three scenarios: 208 1. (generic) router-to-router tunnels. 210 2. site-to-router or router-to-site tunnels. These refer to tunnels 211 between a site's IPv6 (border) device and an IPv6 upstream 212 provider's router. A degenerate case of a site is a single host. 214 3. Host-to-host tunnels. 216 3.1. Router-to-Router Tunnels 218 IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of 219 IPv4 forwarding topology by encapsulating them within IPv4 packets. 220 Tunneling can be used in a variety of ways. 222 .--------. _----_ .--------. 223 |v6-in-v4| _( IPv4 )_ |v6-in-v4| 224 | Router | <======( Internet )=====> | Router | 225 | A | (_ _) | B | 226 '--------' '----' '--------' 227 ^ IPsec tunnel between ^ 228 | Router A and Router B | 229 V V 231 Figure 1: Router-to-Router Scenario. 233 IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel 234 IPv6 packets between themselves. In this case, the tunnel spans one 235 segment of the end-to-end path that the IPv6 packet takes. 237 The source and destination addresses of the IPv6 packets traversing 238 the tunnel could come from a wide range of IPv6 prefixes, so binding 239 IPv6 addresses to be used to the SA is not generally feasible. IPv6 240 ingress filtering must be performed to mitigate the IPv6 address 241 spoofing threat. 243 A specific case of router-to-router tunnels, when one router resides 244 at an end site, is described in the next section. 246 3.2. Site-to-Router/Router-to-Site Tunnels 248 This is a generalization of host-to-router and router-to-host 249 tunneling, because the issues when connecting a whole site (using a 250 router), and connecting a single host are roughly equal. 252 _----_ .---------. IPsec _----_ IPsec .-------. 253 _( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 | 254 ( Internet )<--->| Router |<=======( Internet )=======>| Site B | 255 (_ _) | A | (_ _) '--------' 256 '----' '---------' '----' 257 ^ 258 | 259 V 260 .--------. 261 | Native | 262 | IPv6 | 263 | node | 264 '--------' 266 Figure 2: Router-to-Site Scenario. 268 IPv6/IPv4 routers can tunnel IPv6 packets to their final destination 269 IPv6/IPv4 site. This tunnel spans only the last segment of the end- 270 to-end path. 272 +---------------------+ 273 | IPv6 Network | 274 | | 275 .--------. _----_ | .--------. | 276 | V6/V4 | _( IPv4 )_ | |v6-in-v4| | 277 | Site B |<====( Internet )==========>| Router | | 278 '--------' (_ _) | | A | | 279 '----' | '--------' | 280 IPsec tunnel between | ^ | 281 IPv6 Site and Router A | | | 282 | V | 283 | .-------. | 284 | | V6 | | 285 | | Hosts | | 286 | '--------' | 287 +---------------------+ 289 Figure 3: Site-to-Router Scenario. 291 In the other direction, IPv6/IPv4 hosts can tunnel IPv6 packets to an 292 intermediary IPv6/IPv4 router that is reachable via an IPv4 293 infrastructure. This type of tunnel spans the first segment of the 294 packet's end-to-end path. 296 The hosts in the site originate the packets with IPv6 source 297 addresses coming from a well known prefix, whereas the destination 298 addresses could be any nodes on the Internet. 300 In this case, an IPsec tunnel mode SA could be bound to the prefix 301 that was allocated to the router at Site B, and router A could verify 302 that the source address of the packet matches the prefix. Site B 303 will not be able to do a similar verification for the packets it 304 receives. This may be quite reasonable for most of the deployment 305 cases, for example, an Internet Service Provider (ISP) allocating a 306 /48 to a customer. The Customer Premises Equipment (CPE) where the 307 tunnel is terminated "trusts" (in a weak sense) the ISP's router, and 308 the ISP's router can verify that Site B is the only one that can 309 originate packets within the /48. 311 IPv6 spoofing must be prevented, and setting up ingress filtering may 312 require some amount of manual configuration; see more of these 313 options in Section 5. 315 3.3. Host-to-Host Tunnels 317 .--------. _----_ .--------. 318 | V6/V4 | _( IPv4 )_ | V6/V4 | 319 | Host | <======( Internet )=====> | Host | 320 | A | (_ _) | B | 321 '--------' '----' '--------' 322 IPsec tunnel between 323 Host A and Host B 325 Figure 4: Host-to-Host Scenario. 327 IPv6/IPv4 hosts interconnected by an IPv4 infrastructure can tunnel 328 IPv6 packets between themselves. In this case, the tunnel spans the 329 entire end-to-end path. 331 In this case, the source and the destination IPv6 addresses are known 332 a priori. A tunnel mode SA could be bound to these specific 333 addresses. Address verification prevents IPv6 source address 334 spoofing completely. 336 As noted in the Introduction, automatic host-to-host tunneling 337 methods (e.g., 6to4) are out of scope for this memo. 339 4. IKE and IPsec Versions 341 This section discusses the different versions of the IKE and IPsec 342 security architecture and their applicability to this document. 344 The IPsec security architecture was previously defined in [RFC2401] 345 and is now superseded by [RFC4301]. IKE was originally defined in 346 [RFC2409] (which is called as IKEv1 in this document) and is now 347 superseded by [RFC4306] (called IKEv2; see also [RFC4718]). There 348 are several differences between them. The differences relevant to 349 this document are discussed below. 351 1. [RFC2401] does not allow IP as the next layer protocol in traffic 352 selectors when an IPsec SA is negotiated. [RFC4301] also allows 353 IP as the next layer protocol (like TCP or UDP) in traffic 354 selectors. 356 2. [RFC4301] assumes IKEv2, as some of the new features cannot be 357 negotiated using IKEv1. It is valid to negotiate multiple 358 traffic selectors for a given IPsec SA in [RFC4301]. This is 359 possible only with [RFC4306]. If [RFC2409] is used, then 360 multiple SAs need to be set up for each traffic selector. 362 Note that the existing implementations based on [RFC2409] may already 363 be able to support the [RFC4301] features described in (1) and (2). 364 If appropriate, the deployment may choose to use either version of 365 the security architecture. 367 IKEv2 supports features useful for configuring and securing tunnels 368 not present with IKEv1. 370 1. IKEv2 supports legacy authentication methods by carrying them in 371 EAP payloads. This can be used to authenticate hosts or sites to 372 an ISP using EAP methods that support username and password. 374 2. IKEv2 supports dynamic address configuration, which may be used 375 to configure the IPv6 address of the host. 377 NAT traversal works with both the old and revised IPsec 378 architectures, but the negotiation is integrated with IKEv2. 380 For the purposes of this document, where the confidentiality of ESP 381 [RFC4303] is not required, AH [RFC4302] can be used as an alternative 382 to ESP. The main difference is that AH is able to provide integrity 383 protection for certain fields in the outer IPv4 header and IPv4 384 options. However, as the outer IPv4 header will be discarded in any 385 case, and those particular fields are not believed to be relevant in 386 this particular application, there is no particular reason to use AH. 388 5. IPsec Configuration Details 390 This section describes details about establishing an IPsec tunnel for 391 the protection of IPv4/IPv6 data traffic. 393 The packet format is the same for both transport mode and tunnel mode 394 as shown in Table 1. 396 +----------------------------+------------------------------------+ 397 | Components (first to last) | Contains | 398 +----------------------------+------------------------------------+ 399 | IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) | 400 | ESP header | | 401 | IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) | 402 | (payload) | | 403 +----------------------------+------------------------------------+ 405 Table 1: Packet Format for IPv6/IPv4 Tunnels. 407 5.1. IPsec Transport Mode 409 Transport mode has typically been applied to L2TP, GRE, and other 410 tunneling methods, especially when the user wants to tunnel non-IP 411 traffic. [RFC3884], [RFC3193], and [RFC4023] provide examples of 412 applying transport mode to protect tunnel traffic that spans only a 413 part of an end-to-end path. 415 IPv6 ingress filtering must be applied on the tunnel interface on all 416 the packets that pass the inbound IPsec processing. 418 The following SPD entries assume that there are two routers, Router1 419 and Router2, with tunnel endpoint IPv4 addresses denoted IPV4-TEP1 420 and IPV4-TEP2, respectively. (In other scenarios, the SPDs are set 421 up similarly.) 423 Router1's SPD: 424 Next Layer 425 Rule Local Remote Protocol Action 426 ---- ----- ------ ---------- -------- 427 1 IPV4-TEP1 IPV4-TEP2 ESP BYPASS 428 2 IPV4-TEP1 IPV4-TEP2 IKE BYPASS 429 3 IPv4-TEP1 IPV4-TEP2 41 PROTECT(ESP,transport) 431 Router2's SPD: 432 Next Layer 433 Rule Local Remote Protocol Action 434 ---- ----- ------ ---------- -------- 435 1 IPV4-TEP2 IPV4-TEP1 ESP BYPASS 436 2 IPV4-TEP2 IPV4-TEP1 IKE BYPASS 437 3 IPv4-TEP2 IPV4-TEP1 41 PROTECT(ESP,transport) 439 In both SPD entries, "IKE" refers to UDP destination port 500 440 and possibly also port 4500 if NAT traversal is used. 442 The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2, 443 and protocol value 41 as phase 2 identities. With IKEv2, the traffic 444 selectors are used to carry the same information. 446 5.2. IPsec Tunnel Mode 448 A tunnel mode SA is essentially an SA applied to an IP tunnel, with 449 the access controls applied to the headers of the traffic inside the 450 tunnel [RFC4301]. 452 Several requirements arise when IPsec is used to protect the IPv6 453 traffic (inner header) for the scenarios listed in Section 3. 455 1. All of IPv6 traffic should be protected, including link-local 456 (e.g., Neighbor Discovery) and multicast traffic. 458 2. In router-to-router tunnels, the source and destination addresses 459 of the traffic could come from a wide range of prefixes that are 460 normally learned through routing. As routing can always learn a 461 new prefix, there is no way to know all the prefixes a priori 462 [RFC3884]. 464 3. Source address selection depends on the notions of routes and 465 interfaces. This affects scenarios (2) and (3). 467 Implementations may or may not model the IPsec tunnel mode SA as an 468 interface as described in Appendix A.1. 470 If IPsec tunnel mode SA is not modeled as an interface (e.g., as of 471 this writing, popular in many open source implementations), the SPD 472 entries for protecting all traffic between the two endpoints must be 473 described. Evaluating against the requirements above, link-local 474 traffic cannot be sent, because there is no interface and multicast 475 traffic would need to be identified, possibly resulting in a long 476 list of SPD entries. The second requirement is difficult to satisfy, 477 because the traffic needing protection is not necessarily (e.g., 478 router-to-router tunnel) known a priori [RFC3884]. The third 479 requirement is also problematical, because almost all implementations 480 assume addresses are assigned on interfaces (rather than configured 481 in SPDs) for proper source address selection. 483 If the IPsec tunnel mode SA is modeled as interface, the traffic that 484 needs protection can be modeled as routes pointing to the interface. 485 The second requirement is difficult to satisfy, because the traffic 486 needing protection is not necessarily known a priori. The third 487 requirement is easily solved, because IPsec is modeled as an 488 interface. 490 In practice, (2) has been solved by protecting all the traffic 491 (::/0), bu no inter-operable implementations support this feature. 492 For a detailed list of issues pertaining to this, see 493 [I-D.duffy-ppvpn-ipsec-vlink]. 495 Because applying transport mode to protect a tunnel is a much simpler 496 solution and also easily protects link-local and multicast traffic, 497 we do not recommend using tunnel mode in this context. Tunnel mode 498 is, however, discussed further in Appendix A. 500 5.3. Peer Authorization Database 502 The Peer Authorization Database (PAD) provides the link between SPD 503 and the key management daemon [RFC4306]. This is defined in 504 [RFC4301] and hence relevant only when used with IKEv2. 506 As there is no currently defined way to discover the PAD-related 507 parameters dynamically, it is assumed that these are manually 508 configured: 510 o The Identity of the peer asserted in the IKEv2 exchange: Many 511 different types of identities can be used. At least, the IPv4 512 address of the peer should be supported. 514 o IKEv2 can authenticate the peer by several methods. Pre-shared 515 key and X.509 certificate-based authentication is required by 516 [RFC4301]. At least, pre-shared key should be supported, because 517 it interoperates with a larger number of implementations. 519 o The child SA authorization data should contain the IPv4 address of 520 the peer. 522 6. Recommendations 524 In Section 5, we examined the differences between setting up an IPsec 525 IPv6-in-IPv4 tunnel using either transport or tunnel mode. We 526 observe that applying transport mode to a tunnel interface is the 527 simplest and therefore recommended solution. 529 In Appendix A, we also explore what it would take to use so-called 530 Specific SPD (SSPD) tunnel mode. Such usage is more complicated 531 because IPv6 prefixes need to be known a priori and multicast and 532 link-local traffic do not work over such a tunnel. Fragment handling 533 in tunnel mode is also more difficult. However, because MOBIKE 534 [RFC4555] supports only tunnel mode, when the IPv4 endpoints of a 535 tunnel are dynamic and the other constraints are not applicable, 536 using tunnel mode may be an acceptable solution. 538 Therefore our primary recommendation is to use transport mode applied 539 to a tunnel interface. Source address spoofing can be limited by 540 enabling ingress filtering on the tunnel interface. 542 7. IANA Considerations 544 This memo makes no request to IANA. [[ RFC-editor: please remove this 545 section prior to publication. ]] 547 8. Security Considerations 549 When running IPv6-in-IPv4 tunnels (unsecured) over the Internet, it 550 is possible to "inject" packets into the tunnel by spoofing the 551 source address (data plane security), or if the tunnel is signaled 552 somehow (e.g., using authentication protocol and obtaining a static 553 v6 prefix), someone might be able to spoof the signaling (control 554 plane security). 556 The IPsec framework plays an important role in adding security to 557 both the protocol for tunnel setup and data traffic. 559 Either IKEv1 or IKEv2 provides a secure signaling protocol for 560 establishing, maintaining, and deleting an IPsec tunnel. 562 IPsec, with ESP, offers integrity and data origin authentication, 563 confidentiality, and optional (at the discretion of the receiver) 564 anti-replay features. Using confidentiality without integrity is 565 discouraged. ESP furthermore provides limited traffic flow 566 confidentiality. 568 IPsec provides access control mechanisms through the distribution of 569 keys and also through the application of policies dictated by the 570 Security Policy Database (SPD). 572 The NAT traversal mechanism provided by IKEv2 introduces some 573 weaknesses into IKE and IPsec. These issues are discussed in more 574 detail in [RFC4306]. 576 Please note that using IPsec for the scenarios described in Figure 3, 577 Figure 2 and Figure 1 does not aim to protect the end-to-end 578 communication. It protects just the tunnel part. It is still 579 possible for an IPv6 endpoint not attached to the IPsec tunnel to 580 spoof packets. 582 9. Contributors 584 The authors are listed in alphabetical order. 586 Suresh Satapati also participated in the initial discussions on this 587 topic. 589 10. Acknowledgments 591 The authors would like to thank Stephen Kent, Michael Richardson, 592 Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, Alfred 593 Hoenes, and Francis Dupont for their substantive feedback. 595 We would like to thank Pasi Eronen for his text contributions and 596 suggestions for improvement. 598 11. References 600 11.1. Normative References 602 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 603 Internet Protocol", RFC 2401, November 1998. 605 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 606 (IKE)", RFC 2409, November 1998. 608 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 609 Networks", BCP 84, RFC 3704, March 2004. 611 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 612 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 613 RFC 3948, January 2005. 615 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 616 for IPv6 Hosts and Routers", RFC 4213, October 2005. 618 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 619 Internet Protocol", RFC 4301, December 2005. 621 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 622 RFC 4303, December 2005. 624 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 625 RFC 4306, December 2005. 627 11.2. Informative References 629 [I-D.duffy-ppvpn-ipsec-vlink] 630 Duffy, M., "Framework for IPsec Protected Virtual Links 631 for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in 632 progress), October 2002. 634 [I-D.palet-v6ops-tun-auto-disc] 635 Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point 636 Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-03 637 (work in progress), January 2005. 639 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 640 IPv6 Hosts and Routers", RFC 2893, August 2000. 642 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 643 via IPv4 Clouds", RFC 3056, February 2001. 645 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 646 "Securing L2TP using IPsec", RFC 3193, November 2001. 648 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 649 (NAT) Compatibility Requirements", RFC 3715, March 2004. 651 [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec 652 Transport Mode for Dynamic Routing", RFC 3884, 653 September 2004. 655 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 656 MPLS in IP or Generic Routing Encapsulation (GRE)", 657 RFC 4023, March 2005. 659 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 660 December 2005. 662 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 663 (MOBIKE)", RFC 4555, June 2006. 665 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 666 Implementation Guidelines", RFC 4718, October 2006. 668 Appendix A. Using Tunnel Mode 670 First, we describe the different tunnel mode implementation methods. 671 We note that, in this context, only the so-called Specific SPD (SSPD) 672 model (without a tunnel interface) can be made to work, but it has 673 reduced applicability, and the use of a transport mode tunnel is 674 recommended instead. However, we will describe how the SSPD Tunnel 675 Mode might look if one would like to use it in any case. 677 A.1. Tunnel Mode Implementation Methods 679 Tunnel mode could (in theory) be deployed in two very different ways 680 depending on the implementation: 682 1. "Generic SPDs": some implementations model the tunnel mode SA as 683 an IP interface. In this case, an IPsec tunnel interface is 684 created and used with "any" addresses ("::/0 <-> ::/0" ) as IPsec 685 traffic selectors while setting up the SA. Though this allows 686 all traffic between the two nodes to be protected by IPsec, the 687 routing table would decide what traffic gets sent over the 688 tunnel. Ingress filtering must be separately applied on the 689 tunnel interface as the IPsec policy checks do not check the IPv6 690 addresses at all. Routing protocols, multicast, etc. will work 691 through this tunnel. This mode is similar to transport mode. 692 The SPDs must be interface-specific. However, because IKE uses 693 IPv4 but the tunnel is IPv6, there is no standard solution to map 694 the IPv4 interface to IPv6 interface 695 [I-D.duffy-ppvpn-ipsec-vlink] and this approach is not feasible. 697 2. "Specific SPDs": some implementations do not model the tunnel 698 mode SA as an IP interface. Traffic selection is based on 699 specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8: 700 2::/48". As the IPsec session between two endpoints does not 701 have an interface (though an implementation may have a common 702 pseudo-interface for all IPsec traffic), there is no DAD, MLD, or 703 link-local traffic to protect; multicast is not possible over 704 such a tunnel. Ingress filtering is performed automatically by 705 the IPsec traffic selectors. 707 Ingress filtering is guaranteed by IPsec processing when option (2) 708 is chosen, whereas the operator has to enable it explicitly when 709 transport mode or option (1) is chosen. 711 In summary, there does not appear to be a standard solution in this 712 context for the first implementation approach. 714 The second approach can be made to work, but is only applicable in 715 host-to-host or site-to-router/router-to-site scenarios (i.e., when 716 the IPv6 prefixes can be known a priori), and it offers only a 717 limited set of features (e.g., no multicast) compared with a 718 transport mode tunnel. 720 When tunnel mode is used, fragment handling [RFC4301] may also be 721 more difficult compared with transport mode and, depending on 722 implementation, may need to be reflected in SPDs. 724 A.2. Specific SPD for Host-to-Host Scenario 726 The following SPD entries assume that there are two hosts, Host1 and 727 Host2, whose IPv6 addresses are denoted IPV6-EP1 and IPV6-EP2 (global 728 addresses), and the IPV4 addresses of the tunnel endpoints are 729 denoted IPV4-TEP1 and IPV4-TEP2, respectively. 731 Host1's SPD: 732 Next Layer 733 Rule Local Remote Protocol Action 734 ---- ----- ------ ---------- -------- 735 1 IPV6-EP1 IPV6-EP2 ESP BYPASS 736 2 IPV6-EP1 IPV6-EP2 IKE BYPASS 737 3 IPv6-EP1 IPV6-EP2 41 PROTECT(ESP, 738 tunnel{IPV4-TEP1,IPV4-TEP2}) 740 Host2's SPD: 741 Next Layer 742 Rule Local Remote Protocol Action 743 ---- ----- ------ ---------- -------- 744 1 IPV6-EP2 IPV6-EP1 ESP BYPASS 745 2 IPV6-EP2 IPV6-EP1 IKE BYPASS 746 3 IPv6-EP2 IPV6-EP1 41 PROTECT(ESP, 747 tunnel{IPV4-TEP2,IPV4-TEP1}) 749 "IKE" refers to UDP destination port 500 and possibly also 750 port 4500 if NAT traversal is used. 752 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 753 as phase 2 identities. With IKEv2, the traffic selectors are used to 754 carry the same information. 756 A.3. Specific SPD for Host-to-Router scenario 758 The following SPD entries assume that the host has the IPv6 address 759 IPV6-EP1 and the tunnel end points of the host and router are IPV4- 760 TEP1 and IPV4-TEP2 respectively. If the tunnel is between a router 761 and a host where the router has allocated a IPV6-PREF/48 to the host, 762 the corresponding SPD entries can be derived by replacing IPV6-EP1 763 with IPV6-PREF/48. 765 Please note the bypass entry for host's SPD, absent in router's SPD. 766 While this might be an implementation matter for host-to-router 767 tunneling, having a similar entry, "Local=IPV6-PREF/48 & Remote=IPV6- 768 PREF/48" is critical for site-to-router tunneling. 770 Host's SPD: 771 Next Layer 772 Rule Local Remote Protocol Action 773 ---- ----- ------ ---------- -------- 774 1 IPV6-EP1 IPV6-EP2 ESP BYPASS 775 2 IPV6-EP1 IPV6-EP2 IKE BYPASS 776 3 IPV6-EP1 IPV6-EP1 ANY BYPASS 777 4 IPV6-EP1 ANY ANY PROTECT(ESP, 778 tunnel{IPV4-TEP1,IPV4-TEP2}) 780 Router's SPD: 781 Next Layer 782 Rule Local Remote Protocol Action 783 ---- ----- ------ ---------- -------- 784 1 IPV6-EP2 IPV6-EP1 ESP BYPASS 785 2 IPV6-EP2 IPV6-EP1 IKE BYPASS 786 3 ANY IPV6-EP1 ANY PROTECT(ESP, 787 tunnel{IPV4-TEP1,IPV4-TEP2}) 789 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and 790 ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as their phase 2 791 identities. The starting address is zero and the end address is all 792 ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address 793 and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With 794 IKEv2, the traffic selectors are used to carry the same information. 796 Appendix B. Optional Features 798 B.1. Dynamic Address Configuration 800 With the exchange of protected configuration payloads, IKEv2 is able 801 to provide the IKEv2 peer with DHCP-like information payloads. These 802 configuration payloads are exchanged between the IKEv2 initiator and 803 responder. 805 This could be used (for example) by the host in the host-to-router 806 scenario to obtain an IPv6 address from the ISP as part of setting up 807 the IPsec tunnel mode SA. The details of these procedures are out of 808 scope for this memo. 810 B.2. NAT Traversal and Mobility 812 Network address (and port) translation devices are commonly found in 813 today's networks. A detailed description of the problem of IPsec- 814 protected data traffic traversing a NAT including requirements are 815 discussed in [RFC3715]. 817 IKEv2 can detect the presence of a NAT automatically by sending 818 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in 819 the initial IKE_SA_INIT exchange. Once a NAT is detected and both 820 end points support IPsec NAT traversal extensions, UDP encapsulation 821 can be enabled. 823 More details about UDP encapsulation of IPsec-protected IP packets 824 can be found in [RFC3948]. 826 For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two 827 reasons: 829 1. One of the tunnel endpoints is often behind a NAT, and configured 830 tunneling, using protocol 41, is not guaranteed to traverse the 831 NAT. Hence, using IPsec tunnels would enable one to set up both 832 a secure tunnel and a tunnel that might not always be possible 833 without other tunneling mechanisms. 835 2. Using NAT traversal allows the outer address to change without 836 having to renegotiate the SAs. This could be beneficial for a 837 crude form of mobility and in scenarios where the NAT changes the 838 IP addresses frequently. However, as the outer address may 839 change, this might introduce new security issues, and using 840 tunnel mode would be most appropriate. 842 When NAT is not applied, the second benefit would still be desirable. 843 In particular, using manually configured tunneling is an operational 844 challenge with dynamic IP addresses, because both ends need to be 845 reconfigured if an address changes. Therefore, an easy and efficient 846 way to re-establish the IPsec tunnel if the IP address changes would 847 be desirable. MOBIKE [RFC4555] provides a solution when IKEv2 is 848 used, but it only supports tunnel mode. 850 B.3. Tunnel Endpoint Discovery 852 The IKEv2 initiator needs to know the address of the IKEv2 responder 853 to start IKEv2 signaling. A number of ways can be used to provide 854 the initiator with this information, for example: 856 o Using out-of-band mechanisms, e.g., from the ISP's web page. 858 o Using DNS to look up a service name by appending it to the DNS 859 search path provided by DHCPv4 (e.g. "tunnel- 860 service.example.com"). 862 o Using a DHCP option. 864 o Using a pre-configured or pre-determined IPv4 anycast address. 866 o Using other, unspecified or proprietary methods. 868 For the purpose of this document it is assumed that this address can 869 be obtained somehow. Once the address has been learned, it is 870 configured as the tunnel end-point for the configured IPv6-in-IPv4 871 tunnel. 873 This problem is also discussed at more length in 874 [I-D.palet-v6ops-tun-auto-disc]. 876 However, simply discovering the tunnel endpoint is not sufficient for 877 establishing an IKE session with the peer. The PAD information (see 878 Section 5.3) also needs to be learned dynamically. Hence, currently, 879 automatic endpoint discovery provides benefit only if PAD information 880 is chosen in such a manner that it is not IP-address specific. 882 Authors' Addresses 884 Richard Graveman 885 RFG Security, LLC 886 15 Park Avenue 887 Morristown, New Jersey 07960 888 USA 890 Email: rfg@acm.org 892 Mohan Parthasarathy 893 Nokia 894 313 Fairchild Drive 895 Mountain View CA-94043 896 USA 898 Email: mohanp@sbcglobal.net 900 Pekka Savola 901 CSC/FUNET 902 Espoo 903 Finland 905 Email: psavola@funet.fi 906 Hannes Tschofenig 907 Siemens 908 Otto-Hahn-Ring 6 909 Munich, Bayern 81739 910 Germany 912 Email: Hannes.Tschofenig@siemens.com 914 Full Copyright Statement 916 Copyright (C) The IETF Trust (2006). 918 This document is subject to the rights, licenses and restrictions 919 contained in BCP 78, and except as set forth therein, the authors 920 retain all their rights. 922 This document and the information contained herein are provided on an 923 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 924 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 925 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 926 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 927 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 928 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 930 Intellectual Property 932 The IETF takes no position regarding the validity or scope of any 933 Intellectual Property Rights or other rights that might be claimed to 934 pertain to the implementation or use of the technology described in 935 this document or the extent to which any license under such rights 936 might or might not be available; nor does it represent that it has 937 made any independent effort to identify any such rights. Information 938 on the procedures with respect to rights in RFC documents can be 939 found in BCP 78 and BCP 79. 941 Copies of IPR disclosures made to the IETF Secretariat and any 942 assurances of licenses to be made available, or the result of an 943 attempt made to obtain a general license or permission for the use of 944 such proprietary rights by implementers or users of this 945 specification can be obtained from the IETF on-line IPR repository at 946 http://www.ietf.org/ipr. 948 The IETF invites any interested party to bring to its attention any 949 copyrights, patents or patent applications, or other proprietary 950 rights that may cover technology that may be required to implement 951 this standard. Please address the information to the IETF at 952 ietf-ipr@ietf.org. 954 Acknowledgment 956 Funding for the RFC Editor function is provided by the IETF 957 Administrative Support Activity (IASA).