idnits 2.17.1 draft-ietf-v6ops-ipsec-tunnels-00.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 926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 910. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 916. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (July 7, 2005) is 6865 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2461' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC2710' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'I-D.palet-v6ops-tun-auto-disc' is defined on line 730, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) == Outdated reference: A later version (-08) exists of draft-ietf-mobike-protocol-00 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2893 (Obsoleted by RFC 4213) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 10 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 Expires: January 8, 2006 M. Parthasarathy 5 Nokia 6 P. Savola 7 CSC/FUNET 8 H. Tschofenig 9 Siemens 10 July 7, 2005 12 Using IPsec to Secure IPv6-in-IPv4 Tunnels 13 draft-ietf-v6ops-ipsec-tunnels-00.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 January 8, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 12 68 8. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . . . 13 69 9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 14 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 71 11. Security Considerations . . . . . . . . . . . . . . . . . . 14 72 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 73 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 14.1 Normative References . . . . . . . . . . . . . . . . . . . 15 76 14.2 Informative References . . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 78 A. Specific SPDs for Tunnel Mode . . . . . . . . . . . . . . . . 18 79 A.1 Specific SPD for Host-to-Host Scenario . . . . . . . . . . 18 80 A.2 Specific SPD for Host-to-Router scenario . . . . . . . . . 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 [I-D.ietf-v6ops-mech-v2] as one of 87 the IPv6 transition mechanisms for IPv6 deployment. 89 [I-D.ietf-v6ops-mech-v2] identified a number of threats which had not 90 been adequately analyzed or addressed in its predecessor, [RFC2893]. 91 The 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 SA 100 establishment. Then, it gives the details of Internet Key Exchange 101 (IKE) and IP security (IPsec) exchange with packet formats and SPD 102 entries. Finally, it discusses the usage of IPsec NAT-traversal 103 mechanism that can be used with configured tunnels in some scenarios. 105 This document does not address the use of IPsec for tunnels which are 106 not manually configured (e.g., 6to4 tunnels [RFC3056]). Presumably, 107 some form of opportunistic encryption or "better-than-nothing 108 security" might or might not be applicable. Similarly, propagating 109 quality of service attributes (apart from ECN bits [I-D.ietf-v6ops- 110 mech-v2]) from the encapsulated packets to the tunnel path is out of 111 scope. 113 2. Threats and the Use of IPsec 115 [I-D.ietf-v6ops-mech-v2] was mostly concerned about address spoofing 116 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. [I-D.ietf-v6ops-mech-v2] specifies following 131 strict address checks as mitigating measures. 133 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 IPv4 136 ingress filtering, i.e., checks whether the packet is received on a 137 legitimate interface. 139 To mitigate threat (2), the decapsulator verifies whether the inner 140 IPv6 address is a valid IPv6 address and also applies IPv6 ingress 141 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 (ESP) and then matches the packet against the SPI 154 and the inbound selectors associated with the SA to verify that the 155 packet is appropriate for the SA via which it was received. The 156 successful verification implies that the packet came from the right 157 IPv4 endpoint as the SA is bound to the IPv4 source address. 159 This prevents threat (1) but not the threat (2). IPsec in transport 160 mode does not verify the contents of the payload itself where the 161 IPv6 addresses are carried, that is, two nodes that are using IPsec 162 transport mode to secure the tunnel can spoof the inner payload. The 163 packet will be decapsulated successfully and accepted. 165 The shortcoming can be mitigated by IPv6 ingress filtering i.e., 166 check that the packet is arriving from the interface in the direction 167 of the route towards the tunnel end-point, similar to a Strict 168 Reverse Path Forwarding (RPF) check [RFC3704]. 170 In most implementations, a transport mode SA is applied to a normal 171 IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in 172 the tunnel interface. (Transport mode is often also used in other 173 kind of tunnels such as GRE and L2TP.) 175 2.2 IPsec in Tunnel Mode 177 In tunnel mode, the IPsec SA is established to protect the traffic 178 defined by (IPv6-source, IPv6-destination). On receiving such an 179 IPsec packet, the receiver first applies the IPsec transform (ESP) 180 and then matches the packet against the SPI and the inbound selectors 181 associated with the SA to verify that the packet is appropriate for 182 the SA via which it was received. The successful verification 183 implies that the packet came from the right endpoint. 185 The outer IPv4 addresses may be spoofed and IPsec cannot detect it in 186 this mode; the packets will be demultiplexed based on the SPI and 187 possibly the IPv6 address bound to the SA. Thus, the outer address 188 spoofing is irrelevant as long as the decryption succeeds and the 189 inner IPv6 packet can be verified to come from the right tunnel 190 endpoint. 192 Tunnel mode SA can be used in two ways depending on whether it is 193 modelled as an interface or not. These are described in section 194 Section 5.3. 196 3. Scenarios and Overview 198 There are roughly three kinds of scenarios: 200 1. (generic) router-to-router tunnels. 202 2. site-to-route/router-to-site tunnels. This refers to a tunnel 203 between a site's IPv6 (border) device to an IPv6 upstream 204 provider's router. A degenerate case of a site is a single host. 206 3. Host-to-host tunnels. 208 3.1 Router-to-Router Tunnels 210 IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of 211 IPv4 routing topology by encapsulating them within IPv4 packets. 212 Tunneling can be used in a variety of ways. 214 .--------. _----_ .--------. 215 |v6-in-v4| _( IPv4 )_ |v6-in-v4| 216 | Router | <======( Internet )=====> | Router | 217 | A | (_ _) | B | 218 '--------' '----' '--------' 219 ^ IPsec tunnel between ^ 220 | Router A and Router B | 221 V V 223 Figure 1: Router-to-Router Scenario 225 IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel 226 IPv6 packets between themselves. In this case, the tunnel spans one 227 segment of the end-to-end path that the IPv6 packet takes. 229 The source and destination addresses of the IPv6 packets traversing 230 the tunnel could come from a wide range of IPv6 prefixes, so binding 231 IPv6 addresses to be used to the SA is not feasible. IPv6 ingress 232 filtering must be performed to mitigate the IPv6 address spoofing 233 threat. 235 A specific case of router-to-router tunnels, when one router resides 236 at an end site, is described in the next section. 238 3.2 Site-to-Router/Router-to-Site Tunnels 240 This is a generalization of host-to-router and router-to-host 241 tunneling, because the issues when connecting a whole site (using a 242 router), and connecting a single host are roughly equal. 244 _----_ .---------. IPsec _----_ IPsec .-------. 245 _( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 | 246 ( Internet )<--->| Router |<=======( Internet )=======>| Site B | 247 (_ _) | A | (_ _) '--------' 248 '----' '---------' '----' 249 ^ 250 | 251 V 252 .--------. 253 | Native | 254 | IPv6 | 255 | node | 256 '--------' 258 Figure 2: Router-to-Site Scenario 260 IPv6/IPv4 routers can tunnel IPv6 packets to their final destination 261 IPv6/IPv4 site. This tunnel spans only the last segment of the end- 262 to-end path. 264 +---------------------+ 265 | IPv6 Network | 266 | | 267 .--------. _----_ | .--------. | 268 | V6/V4 | _( IPv4 )_ | |v6-in-v4| | 269 | Site B |<====( Internet )==========>| Router | | 270 '--------' (_ _) | | A | | 271 '----' | '--------' | 272 IPsec tunnel between | ^ | 273 IPv6 Site and Router A | | | 274 | V | 275 | .-------. | 276 | | V6 | | 277 | | Hosts | | 278 | '--------' | 279 +---------------------+ 281 Figure 3: Site-to-Router Scenario 283 Respectively, IPv6/IPv4 hosts can tunnel IPv6 packets to an 284 intermediary IPv6/IPv4 router that is reachable via an IPv4 285 infrastructure. This type of tunnel spans the first segment of the 286 packet's end-to-end path. 288 The hosts in the site originate the packets with source addresses 289 coming from a well known prefix whereas the destination address could 290 be any node on the Internet. 292 In this case, the IPsec tunnel mode SA can be bound to the prefix 293 that was allocated to the router at Site B and router A can verify 294 that the source address of the packet matches the prefix. Site B 295 will not be able to do a similar verification for the packets it 296 receives. This may be quite reasonable for most of the deployment 297 cases, for example, the ISP allocating a /48 to a customer. The CPE 298 (where the tunnel is terminated) "trusts" (in a weak sense) the ISP's 299 router and the ISP's router can verify that the Site B is the only 300 one that can originate packets within the /48. 302 IPv6 spoofing must be prevented, and setting up ingress filtering may 303 require some amount of manual configuration; see more of these 304 options in Section 5. 306 3.3 Host-to-Host Tunnels 308 .--------. _----_ .--------. 309 | V6/V4 | _( IPv4 )_ | V6/V4 | 310 | Host | <======( Internet )=====> | Host | 311 | A | (_ _) | B | 312 '--------' '----' '--------' 313 IPsec tunnel between 314 Host A and Host B 316 Figure 4: Host-to-Host Scenario 318 IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can 319 tunnel IPv6 packets between themselves. In this case, the tunnel 320 spans the entire end-to-end path that the packet takes. 322 In this case, the source and the destination IPv6 address are known a 323 priori. A tunnel mode SA can be bound to the specific address. The 324 address verification prevents IPv6 address spoofing completely. 326 As noted in Introduction, automatic host-to-host tunneling methods 327 (e.g., 6to4) are out of scope of this memo. 329 4. IKE and IPsec Versions 331 This section discusses the different versions of the IKE and IPsec 332 security architecture and their applicability to this document. 334 IPsec security architecture is defined in [RFC2401] and [I-D.ietf- 335 ipsec-rfc2401bis]. There are several differences between them. The 336 difference relevant to this document are discussed below. 338 1. [RFC2401] does not allow IP as the next layer protocol in traffic 339 selectors when IPsec SA is negotiated. [I-D.ietf-ipsec- 340 rfc2401bis] also allows IP as the next layer protocol like TCP or 341 UDP in traffic selectors. 343 2. [RFC2401] does not support transport mode SAs between hosts and 344 security gateways. [I-D.ietf-ipsec-rfc2401bis] supports 345 transport mode SA between hosts and security gateway to provide 346 link security e.g., IP-IP tunnel protected with IPsec. 348 3. [I-D.ietf-ipsec-rfc2401bis] assumes IKEv2, as some of the new 349 features cannot be negotiated using IKEv1. It is valid to 350 negotiate multiple traffic selectors for a given IPsec SA in 351 [I-D.ietf-ipsec-rfc2401bis]. This is possible only with 352 [I-D.ietf-ipsec-ikev2]. If [RFC2409] is used, then multiple SAs 353 need to be set up for each traffic selector. 355 Note that the existing implementations based on [RFC2409] may already 356 be able to support the [I-D.ietf-ipsec-rfc2401bis] features described 357 in (1) and (2). If appropriate, the deployment may choose to use 358 them. 360 IKE is defined in [RFC2409] (which is referred to as IKE in this 361 document) and in [I-D.ietf-ipsec-ikev2] (which is referred to as 362 IKEv2 in this document). IKEv2 supports features that are useful for 363 configuring and securing tunnels which 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 We do not consider the usage of the IP Authentication Header (AH) 376 [I-D.ietf-ipsec-rfc2402bis] as ESP [I-D.ietf-ipsec-esp-v3] provides 377 security services (such as integrity protection without 378 confidentiality protection using 'NULL' encryption) which are 379 comparable with AH. This is explicitly stated in [I-D.ietf-ipsec- 380 rfc2401bis]. 382 5. IPsec Configuration Details 384 This section describes details about the IPsec tunnel establishment 385 for protection of IPv4/IPv6 data traffic. However, first we'll take 386 a look on the packet format on the wire, and the salient differences 387 between transport and tunnel modes. 389 The packet format is the same for both transport mode and tunnel mode 390 as shown in Figure 5. 392 IPv4 header (source = IPV4-TEP1, 393 destination = IPV4-TEP2) 394 ESP header 395 IPv6 header (source = IPV6-EP1, 396 destination = IPV6-EP2) 398 Figure 5: Packet Format for transport and tunnel mode 400 5.1 Transport vs Tunnel Mode 402 Transport mode is typically used by setting up a regular IPv6-in-IPv4 403 (or GRE, L2TP, ...) tunnel, and then applying a transport mode SA to 404 protect the packets before they are sent out over an interface. 406 Tunnel mode can be deployed in two very different ways depending on 407 the implementation: 409 1. "Generic SPDs": some implementations model the tunnel mode SA as 410 an IP interface. In this case, an IPsec tunnel interface is 411 created and used with "any" address ("::/0 <-> ::/0" ) as IPsec 412 traffic selectors while setting up the SA. Though this allows 413 all traffic between the two nodes to be protected by IPsec, the 414 routing table would decide what traffic gets sent over the 415 tunnel. Ingress filtering must be separately applied on the 416 tunnel interface as the IPsec policy checks do not check the IPv6 417 addresses at all. Routing protocols, multicast, etc. will work 418 through this kind of tunnel. This mode is very similar to the 419 transport mode. 421 2. "Specific SPDs": some implementations don't model the tunnel mode 422 SA as an IP interface. Traffic selection is done based on 423 specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8: 424 2::/48". As the IPsec session between two endpoints does not 425 have an interface (though an implementation may have a common 426 pseudo-interface for all IPsec traffic), there is no DAD, MLD, or 427 link-local traffic to protect; multicast is not possible over 428 such a tunnel. Ingress filtering is performed automatically by 429 the IPsec traffic selectors. 431 Ingress filtering is guaranteed by IPsec processing when option (2) 432 is chosen whereas the operator has to enable them explicitly when 433 transport mode or option (1) of tunnel mode SA is chosen. 435 We describe the specific SPD case in Appendix A due to its length and 436 relative complexity compared to transport mode or generic SPD tunnel 437 mode. 439 5.2 IPsec Transport Mode 441 The transport mode has typically been applied to L2TP, GRE, and other 442 kind of tunneling methods, especially when the user wants to tunnel 443 non-IP traffic. [RFC3884] provides an example of applicability. 445 IPv6 ingress filtering must be applied on the tunnel interface on all 446 the packets which pass the inbound IPsec processing. 448 The following SPD entries assume that there are two routers Router1 449 and Router2, whose tunnel endpoint's IPv4 address is denoted by IPV4- 450 TEP1 and IPV4-TEP2 respectively. (In other scenarios, the SPDs are 451 set up in a similar fashion.) The implementations that are strictly 452 conformant to [RFC2401] may not be able to setup the IPsec transport 453 mode SA. 455 Router1's SPD OUT : 457 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 458 THEN USE ESP TRANSPORT MODE SA 460 Router1's SPD IN: 462 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 463 THEN USE ESP TRANSPORT MODE SA 465 Router2's SPD OUT: 467 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 468 THEN USE ESP TRANSPORT MODE SA 470 Router2's SPD IN: 472 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 473 THEN USE ESP TRANSPORT MODE SA 475 The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2 476 and protocol value 41 as phase 2 identities. With IKEv2, the traffic 477 selectors are used to carry the same information. 479 5.3 IPsec Tunnel Mode 481 As we described above, tunnel mode can be used either with "generic" 482 or "specific" SPDs. We describe the generic approach below, and 483 specific SPDs in Appendix A. 485 Implementations may or may not model a tunnel mode SA as a separate 486 interface between each IPsec peer. A separate interface for each is 487 simple as long as generic SPDs are used. However, with specific 488 SPDs, having an interface becomes highly problematic. That is, 489 interfaces must always have link-local addresses, run Duplicate 490 Address Detection, etc. -- which results in packets which must be 491 secured. These would require a set-up of a number of complex SPDs 492 because link-local addresses are not unique. Therefore, we 493 specifically require that specific SPD tunnel mode is not modelled as 494 separate interfaces. 496 Routing protocols, multicast, etc. work fine over generic SPD tunnel 497 mode, but are not feasible with specific SPDs. 499 5.3.1 Generic SPDs for Tunnel Mode 501 In the generic SPD case, for any scenario, SPDs are not really used 502 for traffic selectors. All the SPD entries match all the traffic, 503 i.e., "src = ::/0 & destination = ::/0" (we do not write these out as 504 the SPD entries are trivial). We assume that the tunnel is modelled 505 as an interface, one for each IPsec session. Instead of SPDs, 506 routing table is used to perform outbound traffic selection, and all 507 the traffic that is passes to the interface, gets IPsec-protected. 509 Similarly, the inbound SPD matches everything, so demultiplexing is 510 done based on the SPI. This is secure; while an attacker could spoof 511 packets with the correct SPI (and even tunnel source/destination 512 addresses), the attacker would not know the keying material and such 513 packets would fail IPsec processing. 515 This mode obviously does not prevent from spoofing IPv6 addresses, as 516 any traffic sent by the IPsec peer is accepted. Therefore, ingress 517 filtering must be applied on the tunnel interface. 519 As all (IP) traffic will pass on this kind of tunnel, routing 520 protocols, multicast, etc. will work without problems. 522 6. Dynamic Address Configuration 524 With the exchange of protected configuration payloads, IKEv2 is able 525 to provide the IKEv2 peer with DHCP-like information payloads. These 526 configuration payloads are exchanged between the IKEv2 initiator and 527 the responder. 529 This can be used (for example) by the host in the host-to-router 530 scenario to obtain the IPv6 address from the ISP as part of setting 531 up the IPsec tunnel mode SA. The details of these procedures are out 532 of scope of this memo. 534 7. NAT Traversal and Mobility 536 Network address (and port) translation devices are commonly found in 537 today's networks. A detailed description of the problem of IPsec 538 protected data traffic traversing a NAT including requirements are 539 discussed in [RFC3715]. 541 IKEv2 can detect the presence of a NAT automatically by sending an 542 Informational exchange with NAT_DETECTION_SOURCE_IP and 543 NAT_DETECTION_DESTINATION_IP payloads before establishing an IPsec 544 SA. These payloads are processed the same way as in the initial 545 IKE_SA_INIT exchange. Once a NAT is detected and both end points 546 support IPsec NAT traversal extensions UDP encapsulation can be 547 enabled. 549 More details about UDP encapsulation of IPsec protected IP packets 550 can be found in [RFC3948]. 552 For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two 553 reasons: 555 1. One of the tunnel endpoints is often behind a NAT, and configured 556 tunneling, using protocol 41, is not guaranteed to traverse the 557 NAT. Hence, using IPsec tunnels would enable one to both set-up 558 a secure tunnel, and set-up a tunnel where it might not always be 559 possible without other tunneling mechanisms. 561 2. Using NAT traversal allows the outer address to change without 562 having to renegotiate the SAs. This could be very beneficial for 563 a crude form of mobility, and in scenarios the NAT changes the IP 564 addresses frequently. However, as the outer address may change, 565 this might introduce new security issues, and using tunnel mode 566 would be most appropriate. 568 When NAT is not applied, the second benefit would still be desirable. 569 In particular, using manually configured tunneling is an operational 570 challenge with dynamic IP addresses as both ends need to be 571 reconfigured if an address changes. Therefore an easy and efficient 572 way to re-establish the IPsec tunnel if the IP address changes would 573 be desirable. MOBIKE is looking into providing a solution for IKEv2 574 but the work is still in progress [I-D.ietf-mobike-protocol]. 576 8. Tunnel Endpoint Discovery 578 The IKEv2 initiator needs to know the address of the IKEv2 responder 579 to start IKEv2 signaling. A number of ways can be used to provide 580 the initiator with this information, for example: 582 o Using off-band mechanisms, e.g., from the ISP's web page. 584 o Using DNS to look up a service name by appending it to the DNS 585 search path provided by DHCPv4 (e.g. "tunnel- 586 service.example.com"). 588 o Using a DHCP option. 590 o Using a pre-configured or pre-determined IPv4 anycast address. 592 o Using other, unspecified or proprietary methods. 594 For the purpose of this document it is assumed that this address can 595 be obtained somehow. Once the address has been learned, it is 596 configured as the tunnel end-point for the configured IPv6-in-IPv4 597 tunnel. 599 This problem is also discussed at more length in [I-D.palet-v6ops- 600 tun-auto-disc]. 602 9. Recommendations 604 In Section 5 we examined the differences of setting up an IPsec IPv6- 605 in-IPv4 using either tunnel or transport mode. We observe that the 606 transport mode and tunnel mode with generic SPDs are very similar; 607 multicast and routing protocols work over both, and ingress filtering 608 must be applied on the tunnel interface manually. 610 Tunnel mode with specific SPDs is slightly more complicated. The 611 approach does not seem feasible if modelled as an interface, so we do 612 not support it. Without an interface, the main benefit is that it 613 automatically applies ingress filtering within the IPsec processing. 614 However, multicast, routing protocols, etc. are not feasible with 615 this approach, so its applicability is limited to host-to-host or 616 edge tunnel cases. 618 Tunnel mode may be more attractive when the IPv4 tunnel endpoint 619 addresses change, as MOBIKE only supports tunnel mode. 621 Therefore our primary recommendation is to either tunnel mode with 622 generic SPDs or transport mode, and applying ingress filtering on the 623 tunnel. 625 10. IANA Considerations 627 This memo makes no request to IANA. [[ RFC-editor: please remove this 628 section prior to publication. ]] 630 11. Security Considerations 632 When you run IPv6-in-IPv4 tunnels (unsecured) over the Internet, it 633 is possible to "inject" packets in the tunnel by spoofing the source 634 address (data plane security), or if the tunnel is signalled somehow 635 (e.g., some messages where you authenticate to the server, so that 636 you would get a static v6 prefix), someone might be able to spoof the 637 signalling (control plane security). 639 The IPsec framework plays an important role in adding security to the 640 both, the protocol for tunnel setup and data traffic. 642 IKE provides a secure signaling protocol for establishing, 643 maintaining and deleting an IPsec tunnel. 645 IPsec, with the Encapsulating Security Payload (ESP), offers 646 integrity and data origin authentication, confidentiality, with 647 optional (at the discretion of the receiver) anti-replay features. 648 The usage of confidentity-only is discouraged. ESP furthermore 649 provides limited traffic flow confidentality. 651 IPsec provides access control mechanisms through the distribution of 652 keys and also through the usage of policies dictated by the Security 653 Policy Database (SPD). 655 The NAT traversal mechanism provided by IKE introduces some 656 weaknesses into IKE and IPsec. These issues are discussed in more 657 detail in [I-D.ietf-ipsec-ikev2]. 659 Please note that the usage of IPsec for the scenarios described in 660 Figure 3, Figure 2 and Figure 1 does not aim to protect the end-to- 661 end communication. It protects just the tunnel part. It is still 662 possible for an IPv6 endpoint that is not attached to the IPsec 663 tunnel to spoof packets. 665 12. Contributors 667 The authors are listed in alphabetical order. 669 Suresh Satapati also participated in the initial discussions on the 670 topic. 672 13. Acknowledgments 674 The authors would like to thank Stephen Kent, Michael Richardson, 675 Florian Weimer, Elwyn Davies, and Eric Vyncke for their substantive 676 feedback. 678 We would like to thank Pasi Eronen for his text contributions. 680 14. References 682 14.1 Normative References 684 [I-D.ietf-ipsec-esp-v3] 685 Kent, S., "IP Encapsulating Security Payload (ESP)", 686 draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005. 688 [I-D.ietf-ipsec-ikev2] 689 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 690 draft-ietf-ipsec-ikev2-17 (work in progress), 691 October 2004. 693 [I-D.ietf-ipsec-rfc2401bis] 694 Kent, S. and K. Seo, "Security Architecture for the 695 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work 696 in progress), April 2005. 698 [I-D.ietf-v6ops-mech-v2] 699 Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 700 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 701 (work in progress), March 2005. 703 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 704 Discovery for IP Version 6 (IPv6)", RFC 2461, 705 December 1998. 707 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 708 Listener Discovery (MLD) for IPv6", RFC 2710, 709 October 1999. 711 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 712 Networks", BCP 84, RFC 3704, March 2004. 714 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 715 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 716 RFC 3948, January 2005. 718 14.2 Informative References 720 [I-D.ietf-ipsec-rfc2402bis] 721 Kent, S., "IP Authentication Header", 722 draft-ietf-ipsec-rfc2402bis-11 (work in progress), 723 March 2005. 725 [I-D.ietf-mobike-protocol] 726 Eronen, P., "IKEv2 Mobility and Multihoming Protocol 727 (MOBIKE)", draft-ietf-mobike-protocol-00 (work in 728 progress), June 2005. 730 [I-D.palet-v6ops-tun-auto-disc] 731 Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point 732 Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-03 733 (work in progress), January 2005. 735 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 736 Internet Protocol", RFC 2401, November 1998. 738 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 739 (IKE)", RFC 2409, November 1998. 741 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 742 IPv6 Hosts and Routers", RFC 2893, August 2000. 744 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 745 via IPv4 Clouds", RFC 3056, February 2001. 747 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 748 (NAT) Compatibility Requirements", RFC 3715, March 2004. 750 [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec 751 Transport Mode for Dynamic Routing", RFC 3884, 752 September 2004. 754 Authors' Addresses 756 Richard Graveman 757 RFG Security, LLC 758 15 Park Avenue 759 Morristown, New Jersey 07960 760 USA 762 Email: rfg@acm.org 764 Mohan Parthasarathy 765 Nokia 766 313 Fairchild Drive 767 Mountain View CA-94043 768 USA 770 Email: mohanp@sbcglobal.net 772 Pekka Savola 773 CSC/FUNET 774 Espoo 775 Finnland 777 Email: psavola@funet.fi 778 Hannes Tschofenig 779 Siemens 780 Otto-Hahn-Ring 6 781 Munich, Bayern 81739 782 Germany 784 Email: Hannes.Tschofenig@siemens.com 786 Appendix A. Specific SPDs for Tunnel Mode 788 We describe the specific SPD case in an appendix due to its length 789 and relative complexity compared to transport mode or generic SPD 790 tunnel mode. 792 We assume that this kind of IPsec associations are not modelled as 793 interfaces, because then the link-local traffic would require very 794 complex SPDs as well. 796 A.1 Specific SPD for Host-to-Host Scenario 798 The following SPD entries assume that there are two hosts Host1 and 799 Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2 800 (global addresses) and IPV4 addresses of the tunnel endpoints are 801 denoted by IPV4-TEP1 and IPV4-TEP2 respectively. 803 The outbound SPD will encrypt the traffic to the specified global 804 IPv6 address. 806 Host1's SPD OUT : 808 IF SRC = IPV6-EP1 & destination = IPV6-EP2 809 THEN USE ESP TUNNEL MODE SA: 810 outer source = IPv4-TEP1 811 outer dest = IPV4-TEP2 813 Host1's SPD IN: 815 IF SRC = IPV6-EP2 && DST = IPV6-EP1 816 THEN USE ESP TUNNEL MODE SA 817 outer source = IPV4-TEP2 818 outer dest = IPV4-TEP1 820 Host2's SPD OUT: 822 IF SRC = IPV6-EP2 & destination = IPV6-EP1 823 THEN USE ESP TUNNEL MODE SA: 824 outer source = IPv4-TEP2 825 outer dest = IPV4-TEP1 827 Host2's SPD IN: 829 IF SRC = IPV6-EP1 && DST = IPV6-EP2 830 THEN USE ESP TUNNEL MODE SA: 831 outer source = IPv4-TEP1 832 outer dest = IPV4-TEP2 834 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 835 as phase 2 identities. With IKEv2, the traffic selectors are used to 836 carry the same information. 838 A.2 Specific SPD for Host-to-Router scenario 840 The following SPD entries assume that the host has the IPv6 address 841 IPV6-EP1 and the tunnel end points of the host and router are IPV4- 842 TEP1 and IPV4-TEP2 respectively. If the tunnel is between a router 843 and a host where the router has allocated a IPV6-PREF/48 to the host, 844 the corresponding SPD entries can be derived by substituting IPV6-EP1 845 by IPV6-PREF/48. 847 Please note the bypass entry for host's outbound SPD, and the 848 corresponding router's inbound SPD. While this might be an 849 implementation matter for host-to-router tunneling, having a similar 850 entry, "SRC=IPV6-PREF/48 & destination=IPV6-PREF/48" would be 851 critical for site-to-router tunneling. 853 Host's SPD OUT: 855 IF SRC=IPV6-EP1 & destination = IPV6-EP1 856 THEN BYPASS 858 IF SRC = IPV6-EP1 & destination = any 859 THEN USE ESP TUNNEL MODE SA: 860 outer source = IPv4-TEP1 861 outer dest = IPV4-TEP2 863 Host's SPD IN: 865 IF SRC = any && DST = IPV6-EP1 866 THEN use ESP TUNNEL MODE SA 867 outer source = IPV4-TEP2 868 outer dest = IPV4-TEP1 870 Router's SPD OUT: 872 IF SRC = any & destination = IPV6-EP1 873 THEN USE ESP TUNNEL MODE SA: 874 outer source = IPv4-TEP2 875 outer dest = IPV4-TEP1 877 Router's SPD IN: 879 IF SRC=IPV6-EP1 & destination = IPV6-EP1 880 THEN BYPASS 882 IF SRC = IPV6-EP1 && DST = any 883 THEN use ESP TUNNEL MODE SA 884 outer source = IPV4-TEP1 885 outer dest = IPV4-TEP2 887 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and 888 ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity. 889 The starting address is zero IP address and the end address is all 890 ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address 891 and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With 892 IKEv2, the traffic selectors are used to carry the same information. 894 Intellectual Property Statement 896 The IETF takes no position regarding the validity or scope of any 897 Intellectual Property Rights or other rights that might be claimed to 898 pertain to the implementation or use of the technology described in 899 this document or the extent to which any license under such rights 900 might or might not be available; nor does it represent that it has 901 made any independent effort to identify any such rights. Information 902 on the procedures with respect to rights in RFC documents can be 903 found in BCP 78 and BCP 79. 905 Copies of IPR disclosures made to the IETF Secretariat and any 906 assurances of licenses to be made available, or the result of an 907 attempt made to obtain a general license or permission for the use of 908 such proprietary rights by implementers or users of this 909 specification can be obtained from the IETF on-line IPR repository at 910 http://www.ietf.org/ipr. 912 The IETF invites any interested party to bring to its attention any 913 copyrights, patents or patent applications, or other proprietary 914 rights that may cover technology that may be required to implement 915 this standard. Please address the information to the IETF at 916 ietf-ipr@ietf.org. 918 Disclaimer of Validity 920 This document and the information contained herein are provided on an 921 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 922 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 923 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 924 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 925 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 926 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 928 Copyright Statement 930 Copyright (C) The Internet Society (2005). This document is subject 931 to the rights, licenses and restrictions contained in BCP 78, and 932 except as set forth therein, the authors retain all their rights. 934 Acknowledgment 936 Funding for the RFC Editor function is currently provided by the 937 Internet Society.