idnits 2.17.1 draft-ietf-v6ops-ipsec-tunnels-02.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 895. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 906. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 919. ** 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 (March 6, 2006) is 6624 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4303' is defined on line 710, 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: September 7, 2006 Nokia 6 P. Savola 7 CSC/FUNET 8 H. Tschofenig 9 Siemens 10 March 6, 2006 12 Using IPsec to Secure IPv6-in-IPv4 Tunnels 13 draft-ietf-v6ops-ipsec-tunnels-02.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 September 7, 2006. 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. Transport vs Tunnel Mode . . . . . . . . . . . . . . . . . 10 63 5.2. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 11 64 5.3. IPsec Tunnel Mode . . . . . . . . . . . . . . . . . . . . 11 65 5.3.1. Generic SPDs for Tunnel Mode . . . . . . . . . . . . . 12 66 6. Dynamic Address Configuration . . . . . . . . . . . . . . . . 12 67 7. NAT Traversal and Mobility . . . . . . . . . . . . . . . . . . 13 68 8. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . . . 14 69 9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 14 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 14.1. Normative References . . . . . . . . . . . . . . . . . . . 16 76 14.2. Informative References . . . . . . . . . . . . . . . . . . 16 77 Appendix A. Specific SPDs for Tunnel Mode . . . . . . . . . . . . 17 78 A.1. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 17 79 A.2. Specific SPD for Host-to-Router scenario . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 81 Intellectual Property and Copyright Statements . . . . . . . . . . 21 83 1. Introduction 85 The IPv6 operations (v6ops) working group has selected (manually 86 configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6 87 transition mechanisms for IPv6 deployment. 89 [RFC4213] identified a number of threats which had not been 90 adequately analyzed or addressed in its predecessor, [RFC2893]. The 91 most complete solution is to use IPsec to protect IPv6-in-IPv4 92 tunneling. The document was intentionally not expanded to include 93 the details on how to set up an IPsec-protected tunnel in an 94 interoperable manner, but instead the details were deferred to this 95 memo. 97 First this document analyses the threats and scenarios that can be 98 addressed by IPsec. Next, this document discusses some of the 99 assumptions made by this document for successful IPsec Security 100 Association (SA) establishment. Then, it gives the details of 101 Internet Key Exchange (IKE) and IP security (IPsec) exchange with 102 packet formats and Security Policy Database (SPD) entries. Finally, 103 it discusses the usage of IPsec NAT-traversal mechanism that can be 104 used with configured tunnels in some scenarios. 106 This document does not address the use of IPsec for tunnels which 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. IPsec can be used in two ways, in transport and 146 tunnel mode; further comparison is done in Section 5.1. 148 2.1. IPsec in Transport Mode 150 In transport mode, the IPsec security association (SA) is established 151 to protect the traffic defined by (IPv4-source, IPv4-dest, protocol = 152 41). On receiving such an IPsec packet, the receiver first applies 153 the IPsec transform (e.g., ESP) and then matches the packet against 154 the Security Parameter Index (SPI) and the inbound selectors 155 associated with the SA to verify that the packet is appropriate for 156 the SA via which it was received. A successful verification implies 157 that the packet came from the right IPv4 endpoint as the SA is bound 158 to the IPv4 source address. 160 This prevents threat (1) but not the threat (2). IPsec in transport 161 mode does not verify the contents of the payload itself where the 162 IPv6 addresses are carried, that is, two nodes that are using IPsec 163 transport mode to secure the tunnel can spoof the inner payload. The 164 packet will be decapsulated successfully and accepted. 166 The shortcoming can be mitigated by IPv6 ingress filtering i.e., 167 check that the packet is arriving from the interface in the direction 168 of the route towards the tunnel end-point, similar to a Strict 169 Reverse Path Forwarding (RPF) check [RFC3704]. 171 In most implementations, a transport mode SA is applied to a normal 172 IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in 173 the tunnel interface. (Transport mode is often also used in other 174 kind of tunnels such as GRE and L2TP.) 176 2.2. IPsec in Tunnel Mode 178 In tunnel mode, the IPsec SA is established to protect the traffic 179 defined by (IPv6-source, IPv6-destination). On receiving such an 180 IPsec packet, the receiver first applies the IPsec transform (e.g., 181 ESP) and then matches the packet against the SPI and the inbound 182 selectors associated with the SA to verify that the packet is 183 appropriate for the SA via which it was received. The successful 184 verification implies that the packet came from the right endpoint. 186 The outer IPv4 addresses may be spoofed and IPsec cannot detect it in 187 this mode; the packets will be demultiplexed based on the SPI and 188 possibly the IPv6 address bound to the SA. Thus, the outer address 189 spoofing is irrelevant as long as the decryption succeeds and the 190 inner IPv6 packet can be verified to come from the right tunnel 191 endpoint. 193 A Tunnel mode SA can be used in two ways depending on whether it is 194 modelled as an interface or not. These are described in section 195 Section 5.3. 197 3. Scenarios and Overview 199 There are roughly three kinds of scenarios: 201 1. (generic) router-to-router tunnels. 203 2. site-to-router/router-to-site tunnels. This refers to a tunnel 204 between a site's IPv6 (border) device to an IPv6 upstream 205 provider's router. A degenerate case of a site is a single host. 207 3. Host-to-host tunnels. 209 3.1. Router-to-Router Tunnels 211 IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of 212 IPv4 routing topology by encapsulating them within IPv4 packets. 213 Tunneling can be used in a variety of ways. 215 .--------. _----_ .--------. 216 |v6-in-v4| _( IPv4 )_ |v6-in-v4| 217 | Router | <======( Internet )=====> | Router | 218 | A | (_ _) | B | 219 '--------' '----' '--------' 220 ^ IPsec tunnel between ^ 221 | Router A and Router B | 222 V V 224 Figure 1: Router-to-Router Scenario 226 IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel 227 IPv6 packets between themselves. In this case, the tunnel spans one 228 segment of the end-to-end path that the IPv6 packet takes. 230 The source and destination addresses of the IPv6 packets traversing 231 the tunnel could come from a wide range of IPv6 prefixes, so binding 232 IPv6 addresses to be used to the SA is not feasible. IPv6 ingress 233 filtering must be performed to mitigate the IPv6 address spoofing 234 threat. 236 A specific case of router-to-router tunnels, when one router resides 237 at an end site, is described in the next section. 239 3.2. Site-to-Router/Router-to-Site Tunnels 241 This is a generalization of host-to-router and router-to-host 242 tunneling, because the issues when connecting a whole site (using a 243 router), and connecting a single host are roughly equal. 245 _----_ .---------. IPsec _----_ IPsec .-------. 246 _( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 | 247 ( Internet )<--->| Router |<=======( Internet )=======>| Site B | 248 (_ _) | A | (_ _) '--------' 249 '----' '---------' '----' 250 ^ 251 | 252 V 253 .--------. 254 | Native | 255 | IPv6 | 256 | node | 257 '--------' 259 Figure 2: Router-to-Site Scenario 261 IPv6/IPv4 routers can tunnel IPv6 packets to their final destination 262 IPv6/IPv4 site. This tunnel spans only the last segment of the end- 263 to-end path. 265 +---------------------+ 266 | IPv6 Network | 267 | | 268 .--------. _----_ | .--------. | 269 | V6/V4 | _( IPv4 )_ | |v6-in-v4| | 270 | Site B |<====( Internet )==========>| Router | | 271 '--------' (_ _) | | A | | 272 '----' | '--------' | 273 IPsec tunnel between | ^ | 274 IPv6 Site and Router A | | | 275 | V | 276 | .-------. | 277 | | V6 | | 278 | | Hosts | | 279 | '--------' | 280 +---------------------+ 282 Figure 3: Site-to-Router Scenario 284 Respectively, IPv6/IPv4 hosts can tunnel IPv6 packets to an 285 intermediary IPv6/IPv4 router that is reachable via an IPv4 286 infrastructure. This type of tunnel spans the first segment of the 287 packet's end-to-end path. 289 The hosts in the site originate the packets with source addresses 290 coming from a well known prefix whereas the destination address could 291 be any node on the Internet. 293 In this case, the IPsec tunnel mode SA can be bound to the prefix 294 that was allocated to the router at Site B and router A can verify 295 that the source address of the packet matches the prefix. Site B 296 will not be able to do a similar verification for the packets it 297 receives. This may be quite reasonable for most of the deployment 298 cases, for example, the Internet Service Provider (ISP) allocating a 299 /48 to a customer. The Customer Premises Equipment (CPE) where the 300 tunnel is terminated "trusts" (in a weak sense) the ISP's router and 301 the ISP's router can verify that the Site B is the only one that can 302 originate packets within the /48. 304 IPv6 spoofing must be prevented, and setting up ingress filtering may 305 require some amount of manual configuration; see more of these 306 options in Section 5. 308 3.3. Host-to-Host Tunnels 310 .--------. _----_ .--------. 311 | V6/V4 | _( IPv4 )_ | V6/V4 | 312 | Host | <======( Internet )=====> | Host | 313 | A | (_ _) | B | 314 '--------' '----' '--------' 315 IPsec tunnel between 316 Host A and Host B 318 Figure 4: Host-to-Host Scenario 320 IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can 321 tunnel IPv6 packets between themselves. In this case, the tunnel 322 spans the entire end-to-end path that the packet takes. 324 In this case, the source and the destination IPv6 address are known a 325 priori. A tunnel mode SA can be bound to the specific address. The 326 address verification prevents IPv6 address spoofing completely. 328 As noted in the Introduction, automatic host-to-host tunneling 329 methods (e.g., 6to4) are out of scope of this memo. 331 4. IKE and IPsec Versions 333 This section discusses the different versions of the IKE and IPsec 334 security architecture and their applicability to this document. 336 The IPsec security architecture was originally defined in [RFC2401] 337 and now superseded by [RFC4301]. IKE was originally defined in 338 [RFC2409] (which is referred to as IKEv1 in this document) and is now 339 superseded by [RFC4306] (referred to as IKEv2). There are several 340 differences between them. The differences relevant to this document 341 are discussed below. 343 1. [RFC2401] does not allow IP as the next layer protocol in traffic 344 selectors when an IPsec SA is negotiated. [RFC4301] also allows 345 IP as the next layer protocol like TCP or UDP in traffic 346 selectors. 348 2. [RFC2401] does not support transport mode SAs between hosts and 349 security gateways. [RFC4301] supports transport mode SA between 350 hosts and security gateway to provide link security e.g., IP-IP 351 tunnel protected with IPsec. 353 3. [RFC4301] assumes IKEv2, as some of the new features cannot be 354 negotiated using IKEv1. It is valid to negotiate multiple 355 traffic selectors for a given IPsec SA in [RFC4301]. This is 356 possible only with [RFC4306]. If [RFC2409] is used, then 357 multiple SAs need to be set up for each traffic selector. 359 Note that the existing implementations based on [RFC2409] may already 360 be able to support the [RFC4301] features described in (1) and (2). 361 If appropriate, the deployment may choose to use the two versions of 362 the security architecture. 364 IKEv2 supports features that are useful for configuring and securing 365 tunnels which are not present with IKEv1. 367 1. IKEv2 supports legacy authentication methods by carrying them in 368 EAP payloads. This can be used to authenticate the hosts/sites 369 to the ISP using EAP methods that support username and password. 371 2. IKEv2 supports dynamic address configuration which may be used to 372 configure the IPv6 address of the host. 374 NAT traversal works with both the old and revised IPsec 375 architectures, but the negotiation is integrated with IKEv2. 377 For the purposes of this document, where the confidentiality of ESP 378 is not required, Authentication Header (AH) [RFC4302] can be used 379 interchangeably. The main difference is that AH is able to provide 380 integrity-protection for certain fields in the outer IP header and IP 381 options. However, as the outer IP header will be discarded in any 382 case and those particular fields are not believed to be relevant in 383 this particular application, there is no particular reason to use AH. 385 5. IPsec Configuration Details 387 This section describes details about the establishment of an IPsec 388 tunnel for the protection of IPv4/IPv6 data traffic. However, first 389 we will take a look at the packet format on the wire, and the salient 390 differences between transport and tunnel modes. 392 The packet format is the same for both transport mode and tunnel mode 393 as shown in Table 1. 395 +----------------------------+------------------------------------+ 396 | Components (first to last) | Contains | 397 +----------------------------+------------------------------------+ 398 | IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) | 399 | ESP header | | 400 | IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) | 401 | (payload) | | 402 +----------------------------+------------------------------------+ 404 Table 1 406 5.1. Transport vs Tunnel Mode 408 Transport mode is typically used by setting up a regular IPv6-in-IPv4 409 (or GRE, L2TP, ...) tunnel, and then applying a transport mode SA to 410 protect the packets before they are sent out over an interface. 412 Tunnel mode can be deployed in two very different ways depending on 413 the implementation: 415 1. "Generic SPDs": some implementations model the tunnel mode SA as 416 an IP interface. In this case, an IPsec tunnel interface is 417 created and used with "any" address ("::/0 <-> ::/0" ) as IPsec 418 traffic selectors while setting up the SA. Though this allows 419 all traffic between the two nodes to be protected by IPsec, the 420 routing table would decide what traffic gets sent over the 421 tunnel. Ingress filtering must be separately applied on the 422 tunnel interface as the IPsec policy checks do not check the IPv6 423 addresses at all. Routing protocols, multicast, etc. will work 424 through this tunnel. This mode is very similar to the transport 425 mode. 427 2. "Specific SPDs": some implementations don't model the tunnel mode 428 SA as an IP interface. Traffic selection is done based on 429 specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8: 430 2::/48". As the IPsec session between two endpoints does not 431 have an interface (though an implementation may have a common 432 pseudo-interface for all IPsec traffic), there is no DAD, MLD, or 433 link-local traffic to protect; multicast is not possible over 434 such a tunnel. Ingress filtering is performed automatically by 435 the IPsec traffic selectors. 437 Ingress filtering is guaranteed by IPsec processing when option (2) 438 is chosen whereas the operator has to enable them explicitly when 439 transport mode or option (1) of tunnel mode SA is chosen. 441 We describe the specific SPD case in Appendix A due to its length and 442 relative complexity compared to transport mode or generic SPD tunnel 443 mode. 445 5.2. IPsec Transport Mode 447 The transport mode has typically been applied to L2TP, GRE, and other 448 kind of tunneling methods, especially when the user wants to tunnel 449 non-IP traffic. [RFC3884] provides an example of applicability. 451 IPv6 ingress filtering must be applied on the tunnel interface on all 452 the packets which pass the inbound IPsec processing. 454 The following SPD entries assume that there are two routers Router1 455 and Router2, with tunnel endpoint IPv4 addresses are denoted by IPV4- 456 TEP1 and IPV4-TEP2 respectively. (In other scenarios, the SPDs are 457 set up in a similar fashion.) Implementations that are strictly 458 conformant to [RFC2401] may not be able to setup the IPsec transport 459 mode SA. 461 Router1's SPD OUT : 463 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 464 THEN USE ESP TRANSPORT MODE SA 466 Router1's SPD IN: 468 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 469 THEN USE ESP TRANSPORT MODE SA 471 Router2's SPD OUT: 473 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 474 THEN USE ESP TRANSPORT MODE SA 476 Router2's SPD IN: 478 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 479 THEN USE ESP TRANSPORT MODE SA 481 The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2 482 and protocol value 41 as phase 2 identities. With IKEv2, the traffic 483 selectors are used to carry the same information. 485 5.3. IPsec Tunnel Mode 487 As we described above, tunnel mode can be used either with "generic" 488 or "specific" SPDs. We describe the generic approach below, and 489 specific SPDs in Appendix A. 491 Implementations may or may not model a tunnel mode SA as a separate 492 interface between each IPsec peer. A separate interface for each is 493 simple as long as generic SPDs are used. However, with specific 494 SPDs, having an interface becomes highly problematic. That is, 495 interfaces must always have link-local addresses, run Duplicate 496 Address Detection, etc. -- which results in packets which must be 497 secured. These would require a set-up of a number of complex SPDs 498 because link-local addresses are not unique. Therefore, this memo 499 restricts to describing only the scenario where SPD tunnel mode is 500 not modelled as separate interfaces. 502 Routing protocols, multicast, etc. work fine over generic SPD tunnel 503 mode, but are not feasible with specific SPDs. 505 5.3.1. Generic SPDs for Tunnel Mode 507 In the generic SPD case, for any scenario, SPDs are not really used 508 for traffic selectors. All the SPD entries match all the traffic, 509 i.e., "src = ::/0 & destination = ::/0" (we do not write these out as 510 the SPD entries are trivial). We assume that the tunnel is modelled 511 as an interface, one for each IPsec session. Instead of SPDs, the 512 routing table is used to perform outbound traffic selection, and all 513 the traffic that is passed to the interface, gets IPsec-protected. 515 Similarly, the inbound SPD matches everything, so demultiplexing is 516 done based on the SPI. This is secure; while an attacker could spoof 517 packets with the correct SPI (and even tunnel source/destination 518 addresses), the attacker would not know the keying material and such 519 packets would fail IPsec processing. 521 This mode obviously does not prevent an attacker from spoofing IPv6 522 addresses, as any traffic sent by the IPsec peer is accepted. 523 Therefore, ingress filtering must be applied on the tunnel interface. 525 As all (IP) traffic will pass on this kind of tunnel, routing 526 protocols, multicast, etc. will work without problems. 528 6. Dynamic Address Configuration 530 With the exchange of protected configuration payloads, IKEv2 is able 531 to provide the IKEv2 peer with DHCP-like information payloads. These 532 configuration payloads are exchanged between the IKEv2 initiator and 533 the responder. 535 This can be used (for example) by the host in the host-to-router 536 scenario to obtain the IPv6 address from the ISP as part of setting 537 up the IPsec tunnel mode SA. The details of these procedures are out 538 of scope of this memo. 540 7. NAT Traversal and Mobility 542 Network address (and port) translation devices are commonly found in 543 today's networks. A detailed description of the problem of IPsec 544 protected data traffic traversing a NAT including requirements are 545 discussed in [RFC3715]. 547 IKEv2 can detect the presence of a NAT automatically by sending an 548 Informational exchange with NAT_DETECTION_SOURCE_IP and 549 NAT_DETECTION_DESTINATION_IP payloads before establishing an IPsec 550 SA. These payloads are processed in the same way as in the initial 551 IKE_SA_INIT exchange. Once a NAT is detected and both end points 552 support IPsec NAT traversal extensions UDP encapsulation can be 553 enabled. 555 More details about UDP encapsulation of IPsec protected IP packets 556 can be found in [RFC3948]. 558 For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two 559 reasons: 561 1. One of the tunnel endpoints is often behind a NAT, and configured 562 tunneling, using protocol 41, is not guaranteed to traverse the 563 NAT. Hence, using IPsec tunnels would enable one to both set-up 564 a secure tunnel, and set-up a tunnel where it might not always be 565 possible without other tunneling mechanisms. 567 2. Using NAT traversal allows the outer address to change without 568 having to renegotiate the SAs. This could be very beneficial for 569 a crude form of mobility, and in scenarios where the NAT changes 570 the IP addresses frequently. However, as the outer address may 571 change, this might introduce new security issues, and using 572 tunnel mode would be most appropriate. 574 When NAT is not applied, the second benefit would still be desirable. 575 In particular, using manually configured tunneling is an operational 576 challenge with dynamic IP addresses as both ends need to be 577 reconfigured if an address changes. Therefore an easy and efficient 578 way to re-establish the IPsec tunnel if the IP address changes would 579 be desirable. The IETF MOBIKE working group is looking into 580 providing a solution for IKEv2 but the work is still in progress 581 [I-D.ietf-mobike-protocol]. 583 8. Tunnel Endpoint Discovery 585 The IKEv2 initiator needs to know the address of the IKEv2 responder 586 to start IKEv2 signaling. A number of ways can be used to provide 587 the initiator with this information, for example: 589 o Using out-of-band mechanisms, e.g., from the ISP's web page. 591 o Using DNS to look up a service name by appending it to the DNS 592 search path provided by DHCPv4 (e.g. "tunnel- 593 service.example.com"). 595 o Using a DHCP option. 597 o Using a pre-configured or pre-determined IPv4 anycast address. 599 o Using other, unspecified or proprietary methods. 601 For the purpose of this document it is assumed that this address can 602 be obtained somehow. Once the address has been learned, it is 603 configured as the tunnel end-point for the configured IPv6-in-IPv4 604 tunnel. 606 This problem is also discussed at more length in 607 [I-D.palet-v6ops-tun-auto-disc]. 609 9. Recommendations 611 In Section 5 we examined the differences of setting up an IPsec IPv6- 612 in-IPv4 using either tunnel or transport mode. We observe that the 613 transport mode and tunnel mode with generic SPDs are very similar; 614 multicast and routing protocols work over both, and ingress filtering 615 must be applied on the tunnel interface manually. 617 Tunnel mode with specific SPDs is slightly more complicated. The 618 approach does not seem feasible if modelled as an interface, so we do 619 not recommend it. Without an interface, the main benefit is that it 620 automatically applies ingress filtering within the IPsec processing. 621 However, multicast, routing protocols, etc. are not feasible with 622 this approach, so its applicability is limited to host-to-host or 623 edge tunnel cases. 625 Tunnel mode may be more attractive when the IPv4 tunnel endpoint 626 addresses change, as MOBIKE only supports tunnel mode. 628 Therefore our primary recommendation is to use either tunnel mode 629 with generic SPDs or transport mode, and apply ingress filtering on 630 the tunnel. 632 10. IANA Considerations 634 This memo makes no request to IANA. [[ RFC-editor: please remove this 635 section prior to publication. ]] 637 11. Security Considerations 639 When you run IPv6-in-IPv4 tunnels (unsecured) over the Internet, it 640 is possible to "inject" packets into the tunnel by spoofing the 641 source address (data plane security), or if the tunnel is signalled 642 somehow (e.g., some messages where you authenticate to the server, so 643 that you would get a static v6 prefix), someone might be able to 644 spoof the signalling (control plane security). 646 The IPsec framework plays an important role in adding security to 647 both the protocol for tunnel setup and data traffic. 649 Either IKEv1 or IKEv2 provides a secure signaling protocol for 650 establishing, maintaining and deleting an IPsec tunnel. 652 IPsec, with the Encapsulating Security Payload (ESP), offers 653 integrity and data origin authentication, confidentiality, with 654 optional (at the discretion of the receiver) anti-replay features. 655 The usage of confidentity-only is discouraged. ESP furthermore 656 provides limited traffic flow confidentality. 658 IPsec provides access control mechanisms through the distribution of 659 keys and also through the usage of policies dictated by the Security 660 Policy Database (SPD). 662 The NAT traversal mechanism provided by IKEv2 introduces some 663 weaknesses into IKE and IPsec. These issues are discussed in more 664 detail in [RFC4306]. 666 Please note that the usage of IPsec for the scenarios described in 667 Figure 3, Figure 2 and Figure 1 does not aim to protect the end-to- 668 end communication. It protects just the tunnel part. It is still 669 possible for an IPv6 endpoint that is not attached to the IPsec 670 tunnel to spoof packets. 672 12. Contributors 674 The authors are listed in alphabetical order. 676 Suresh Satapati also participated in the initial discussions on the 677 topic. 679 13. Acknowledgments 681 The authors would like to thank Stephen Kent, Michael Richardson, 682 Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, and Alfred 683 Hines for their substantive feedback. 685 We would like to thank Pasi Eronen for his text contributions. 687 14. References 689 14.1. Normative References 691 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 692 Internet Protocol", RFC 2401, November 1998. 694 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 695 (IKE)", RFC 2409, November 1998. 697 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 698 Networks", BCP 84, RFC 3704, March 2004. 700 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 701 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 702 RFC 3948, January 2005. 704 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 705 for IPv6 Hosts and Routers", RFC 4213, October 2005. 707 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 708 Internet Protocol", RFC 4301, December 2005. 710 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 711 RFC 4303, December 2005. 713 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 714 RFC 4306, December 2005. 716 14.2. Informative References 718 [I-D.ietf-mobike-protocol] 719 Eronen, P., "IKEv2 Mobility and Multihoming Protocol 720 (MOBIKE)", draft-ietf-mobike-protocol-08 (work in 721 progress), February 2006. 723 [I-D.palet-v6ops-tun-auto-disc] 724 Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point 725 Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-03 726 (work in progress), January 2005. 728 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 729 IPv6 Hosts and Routers", RFC 2893, August 2000. 731 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 732 via IPv4 Clouds", RFC 3056, February 2001. 734 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 735 (NAT) Compatibility Requirements", RFC 3715, March 2004. 737 [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec 738 Transport Mode for Dynamic Routing", RFC 3884, 739 September 2004. 741 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 742 December 2005. 744 Appendix A. Specific SPDs for Tunnel Mode 746 We describe the specific SPD case in an appendix due to its length 747 and relative complexity compared to transport mode or generic SPD 748 tunnel mode. 750 We assume that this kind of IPsec association is not modelled as an 751 interface, because then the link-local traffic would require very 752 complex SPDs as well. 754 A.1. Specific SPD for Host-to-Host Scenario 756 The following SPD entries assume that there are two hosts Host1 and 757 Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2 758 (global addresses) and IPV4 addresses of the tunnel endpoints are 759 denoted by IPV4-TEP1 and IPV4-TEP2 respectively. 761 The outbound SPD will encrypt the traffic to the specified global 762 IPv6 address. 764 Host1's SPD OUT : 766 IF SRC = IPV6-EP1 & DST = IPV6-EP2 767 THEN USE ESP TUNNEL MODE SA: 768 outer source = IPv4-TEP1 769 outer dest = IPV4-TEP2 771 Host1's SPD IN: 773 IF SRC = IPV6-EP2 && DST = IPV6-EP1 774 THEN USE ESP TUNNEL MODE SA 775 outer source = IPV4-TEP2 776 outer dest = IPV4-TEP1 778 Host2's SPD OUT: 780 IF SRC = IPV6-EP2 & DST = IPV6-EP1 781 THEN USE ESP TUNNEL MODE SA: 782 outer source = IPv4-TEP2 783 outer dest = IPV4-TEP1 785 Host2's SPD IN: 787 IF SRC = IPV6-EP1 && DST = IPV6-EP2 788 THEN USE ESP TUNNEL MODE SA: 789 outer source = IPv4-TEP1 790 outer dest = IPV4-TEP2 792 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 793 as phase 2 identities. With IKEv2, the traffic selectors are used to 794 carry the same information. 796 A.2. Specific SPD for Host-to-Router scenario 798 The following SPD entries assume that the host has the IPv6 address 799 IPV6-EP1 and the tunnel end points of the host and router are IPV4- 800 TEP1 and IPV4-TEP2 respectively. If the tunnel is between a router 801 and a host where the router has allocated a IPV6-PREF/48 to the host, 802 the corresponding SPD entries can be derived by substituting IPV6-EP1 803 by IPV6-PREF/48. 805 Please note the bypass entry for host's outbound SPD, absent in 806 router's inbound SPD. While this might be an implementation matter 807 for host-to-router tunneling, having a similar entry, "SRC=IPV6- 808 PREF/48 & DST=IPV6-PREF/48" is critical for site-to-router tunneling. 810 Host's SPD OUT: 812 IF SRC=IPV6-EP1 & DST = IPV6-EP1 813 THEN BYPASS 815 IF SRC = IPV6-EP1 & DST = any 816 THEN USE ESP TUNNEL MODE SA: 817 outer source = IPv4-TEP1 818 outer dest = IPV4-TEP2 820 Host's SPD IN: 822 IF SRC = any && DST = IPV6-EP1 823 THEN use ESP TUNNEL MODE SA 824 outer source = IPV4-TEP2 825 outer dest = IPV4-TEP1 827 Router's SPD OUT: 829 IF SRC = any & DST = IPV6-EP1 830 THEN USE ESP TUNNEL MODE SA: 831 outer source = IPv4-TEP2 832 outer dest = IPV4-TEP1 834 Router's SPD IN: 836 IF SRC = IPV6-EP1 && DST = any 837 THEN use ESP TUNNEL MODE SA 838 outer source = IPV4-TEP1 839 outer dest = IPV4-TEP2 841 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and 842 ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity. 843 The starting address is zero IP address and the end address is all 844 ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address 845 and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With 846 IKEv2, the traffic selectors are used to carry the same information. 848 Authors' Addresses 850 Richard Graveman 851 RFG Security, LLC 852 15 Park Avenue 853 Morristown, New Jersey 07960 854 USA 856 Email: rfg@acm.org 858 Mohan Parthasarathy 859 Nokia 860 313 Fairchild Drive 861 Mountain View CA-94043 862 USA 864 Email: mohanp@sbcglobal.net 866 Pekka Savola 867 CSC/FUNET 868 Espoo 869 Finnland 871 Email: psavola@funet.fi 873 Hannes Tschofenig 874 Siemens 875 Otto-Hahn-Ring 6 876 Munich, Bayern 81739 877 Germany 879 Email: Hannes.Tschofenig@siemens.com 881 Full Copyright Statement 883 Copyright (C) The Internet Society (2006). 885 This document is subject to the rights, licenses and restrictions 886 contained in BCP 78, and except as set forth therein, the authors 887 retain all their rights. 889 This document and the information contained herein are provided on an 890 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 891 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 892 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 893 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 894 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 895 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 897 Intellectual Property 899 The IETF takes no position regarding the validity or scope of any 900 Intellectual Property Rights or other rights that might be claimed to 901 pertain to the implementation or use of the technology described in 902 this document or the extent to which any license under such rights 903 might or might not be available; nor does it represent that it has 904 made any independent effort to identify any such rights. Information 905 on the procedures with respect to rights in RFC documents can be 906 found in BCP 78 and BCP 79. 908 Copies of IPR disclosures made to the IETF Secretariat and any 909 assurances of licenses to be made available, or the result of an 910 attempt made to obtain a general license or permission for the use of 911 such proprietary rights by implementers or users of this 912 specification can be obtained from the IETF on-line IPR repository at 913 http://www.ietf.org/ipr. 915 The IETF invites any interested party to bring to its attention any 916 copyrights, patents or patent applications, or other proprietary 917 rights that may cover technology that may be required to implement 918 this standard. Please address the information to the IETF at 919 ietf-ipr@ietf.org. 921 Acknowledgment 923 Funding for the RFC Editor function is provided by the IETF 924 Administrative Support Activity (IASA).