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