idnits 2.17.1 draft-tschofenig-v6ops-secure-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.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 971. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 961. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages 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 (December 16, 2004) is 7070 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: 'I-D.bellovin-useipsec' is defined on line 866, but no explicit reference was found in the text == Unused Reference: 'I-D.blanchet-v6ops-tunnelbroker-tsp' is defined on line 870, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-09 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-05 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-06 ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-03 == Outdated reference: A later version (-04) exists of draft-blanchet-v6ops-tunnelbroker-tsp-01 == Outdated reference: A later version (-11) exists of draft-ietf-ipsec-rfc2402bis-10 == Outdated reference: A later version (-03) exists of draft-palet-v6ops-tun-auto-disc-02 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations WG R. Graveman 3 Internet-Draft RFG Security, LLC 4 Expires: June 16, 2005 M. Parthasarathy 5 Nokia 6 P. Savola 7 CSC/FUNET 8 H. Tschofenig 9 Siemens 10 December 16, 2004 12 Using IPsec to Secure IPv6-over-IPv4 Tunnels 13 draft-tschofenig-v6ops-secure-tunnels-03.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on June 16, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). 46 Abstract 48 This document gives guidance on securing IPv6-in-IPv4 tunnels using 49 IPsec. No additional protocol extensions are described beyond those 50 available with the IPsec framework. This document describes packet 51 formats, IPsec security policy database for various scenarios, 52 address configuration procedures, and the usage of the Extensible 53 Authentication Procotol. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3 59 2.1 IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4 60 2.2 IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 4 61 3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5 62 3.1 Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 5 63 3.2 Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 5 64 3.3 Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 7 65 4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 7 66 5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 8 67 5.1 IPsec Transport mode . . . . . . . . . . . . . . . . . . . 8 68 5.2 IPsec Tunnel mode . . . . . . . . . . . . . . . . . . . . 9 69 5.2.1 SPD for Host-to-Host Scenario . . . . . . . . . . . . 9 70 5.2.2 SPD for Host-to-Router scenario . . . . . . . . . . . 11 71 6. Dynamic Address Configuration . . . . . . . . . . . . . . . . 14 72 7. Extensible Authentication Support . . . . . . . . . . . . . . 14 73 8. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 15 74 9. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . . . 16 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 76 11. Security Considerations . . . . . . . . . . . . . . . . . . 16 77 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 17 78 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 79 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 80 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 15.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 82 15.2 Informative References . . . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 84 Intellectual Property and Copyright Statements . . . . . . . . 22 86 1. Introduction 88 The IPv6 operations (v6ops) working group has selected IPv6-in-IPv4 89 tunneling [I-D.ietf-v6ops-mech-v2] as one of the IPv6 transition 90 mechanisms for IPv6 deployment. A number of threats have been 91 identified with possible solutions to mitigate them 92 [I-D.ietf-v6ops-mech-v2]. One of the solutions is the use of IPsec 93 protected tunnels, but there is little detail on how IPsec would 94 actually be used in an interoperable manner. This memo describes the 95 use of IPsec in detail. 97 First this document analyses the threats that can be addressed by 98 IPsec. Next, this document discusses some of the assumptions made by 99 this document for successful IPsec SA establishment. Then, it gives 100 the details of IKE/IPsec exchange with packet formats and SPD 101 entries. Finally, it discusses the usage of IPsec NAT-traversal 102 mechanism that can be used with configured tunnels in some scenarios. 104 2. Threats and the Use of IPsec 106 Following threats have been identified in [I-D.ietf-v6ops-mech-v2]: 108 1. IPv4 address of the encapsulating ("outer") packet can be 109 spoofed. 111 2. IPv6 address of the encapsulated ("inner") packet can be spoofed. 113 The reason for threat (1) is due to the lack of widespread deployment 114 of IPv4 ingress filtering. The reason for threat (2) is that the 115 IPv6 packet is encapsulated in IPv4 and hence escapes IPv6 ingress 116 filtering. [I-D.ietf-v6ops-mech-v2] specifies following strict 117 address checks as mitigating measures. 119 To mitigate threat (1), the decapsulator verifies that the IPv4 120 source address of the packet is the same as the address of the 121 configured tunnel endpoint. The decapsulator may also implement IPv4 122 ingress filtering, i.e., checks whether the packet is received on a 123 legitimate interface. 125 To mitigate threat (2), the decapsulator verifies whether the inner 126 IPv6 address is a valid IPv6 address and also applies IPv6 ingress 127 filtering before accepting the IPv6 packet. 129 This memo proposes using IPsec for providing stronger security in 130 preventing these threats. IPsec can be used in two ways, in 131 transport and tunnel mode. 133 2.1 IPsec in Transport Mode 135 In transport mode, the IPsec security association (SA) is established 136 to protect the traffic defined by (IPv4-source, IPv4-dest, protocol = 137 41). On receiving such an IPsec packet, the receiver first applies 138 the IPsec transform (ESP) and then matches the packet against the 139 inbound selectors associated with the SA to verify that the packet is 140 appropriate for the SA via which it was received. The successful 141 verification implies that the packet came from the right IPv4 142 endpoint as the SA is bound to the IPv4 source address. 144 This prevents threat (1) but not the threat (2). IPsec in transport 145 mode does not verify the contents of the payload itself where the 146 IPv6 addresses are carried, that is, two nodes that are using IPsec 147 transport mode to secure the tunnel can spoof the inner payload. The 148 packet will be decapsulated successfully and accepted. 150 The shortcoming can be mitigated by IPv6 ingress filtering i.e., 151 check that the packet is arriving from the interface in the direction 152 of the route towards the tunnel end-point, similar to a Strict 153 Reverse Path Forwarding (RPF) check [RFC3704]. 155 For performing ingress filtering, it is assumed that the tunnel is 156 modelled as an interface and the traffic of the tunnel is protected 157 using IPsec transport mode SA. 159 2.2 IPsec in Tunnel Mode 161 In tunnel mode, the IPsec SA is established to protect the traffic 162 defined by (IPv6-source, IPv6-destination). On receiving such an 163 IPsec packet, the receiver first applies the IPsec transform (ESP) 164 and then matches the packet against the inbound selectors associated 165 with the SA to verify that the packet is appropriate for the SA via 166 which it was received. The successful verification implies that the 167 packet came from the right IPv6 endpoint as the SA is bound to the 168 IPv6 source address. 170 The IPv4 addresses may be spoofed and IPsec cannot detect it in this 171 mode, that is, two nodes that are using IPsec tunnel mode to secure 172 the tunnel with a common tunnel endpoint can spoof each other's IPv4 173 address. But, the packet will not be accepted by IPsec as the IPv6 174 address bound to the SA will not match the address in the spoofed 175 packet. Thus, the outer address spoofing is irrelevant as long as 176 the inner IPv6 packet can be verified to come from the right IPv6 177 endpoint. 179 3. Scenarios and Overview 181 There are roughly three kinds of scenarios: (generic) 182 router-to-router tunnels, site-to-router/router-to-site tunnels (a 183 generalization of host-to-router/router-to-host scenarios, 184 respectively), and host-to-host tunnels. 186 3.1 Router-to-Router Tunnels 188 IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of 189 IPv4 routing topology by encapsulating them within IPv4 packets. 190 Tunneling can be used in a variety of ways. 192 .--------. _----_ .--------. 193 |v6-in-v4| _( IPv4 )_ |v6-in-v4| 194 | Router | <======( Internet )=====> | Router | 195 | A | (_ _) | B | 196 '--------' '----' '--------' 197 ^ IPsec tunnel between ^ 198 | Router A and Router B | 199 V V 201 Figure 1: Router-to-Router Scenario 203 IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel 204 IPv6 packets between themselves. In this case, the tunnel spans one 205 segment of the end-to-end path that the IPv6 packet takes. 207 The source and destination addresses of the IPv6 packets traversing 208 the tunnel could come from a wide range of IPv6 prefixes. It is not 209 scalable to establish IPsec tunnel mode SAs for all such packets. 210 Hence, IPsec transport mode SA is recommended for this scenario. 211 IPv6 ingress filtering should be performed to mitigate the IPv6 212 address spoofing threat. 214 A specific case of router-to-router tunnels, when one router resides 215 at an end site, is described in the next section. 217 3.2 Site-to-Router/Router-to-Site Tunnels 219 This is a generalization of host-to-router and router-to-host 220 tunneling, because the issues when connecting a whole site (using a 221 router), and connecting a single host are roughly equal. 223 _----_ .---------. IPsec _----_ IPsec .-------. 224 _( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 | 225 ( Internet )<--->| Router |<=======( Internet )=======>| Site B | 226 (_ _) | A | (_ _) '--------' 227 '----' '---------' '----' 228 ^ 229 | 230 V 231 .--------. 232 | Native | 233 | IPv6 | 234 | node | 235 '--------' 237 Figure 2: Router-to-Site Scenario 239 IPv6/IPv4 routers can tunnel IPv6 packets to their final destination 240 IPv6/IPv4 site. This tunnel spans only the last segment of the 241 end-to-end path. 243 This is the same as the Site-to-Router case. 245 +---------------------+ 246 | IPv6 Network | 247 | | 248 .--------. _----_ | .--------. | 249 | V6/V4 | _( IPv4 )_ | |v6-in-v4| | 250 | Site B |<====( Internet )==========>| Router | | 251 '--------' (_ _) | | A | | 252 '----' | '--------' | 253 IPsec tunnel between | ^ | 254 V6 Site and Router A | | | 255 | V | 256 | .-------. | 257 | | V6 | | 258 | | Host | | 259 | '--------' | 260 +---------------------+ 262 Figure 3: Site-to-Router Scenario 264 IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 265 router that is reachable via an IPv4 infrastructure. This type of 266 tunnel spans the first segment of the packet's end-to-end path. 268 Here, the hosts in the site originate the packets with source 269 addresses coming from a well known prefix whereas the destination 270 address could be any node on the Internet. 272 In this case, the IPsec tunnel mode SA can be bound to the prefix 273 that was allocated to the router at Site B and router A can verify 274 that the source address of the packet matches the prefix. Site B 275 will not be able to do a similar verification for the packets it 276 receives. This may be quite reasonable for most of the deployment 277 cases, for example, the ISP allocating a /48 to a customer. The CPE 278 (where the tunnel is terminated) "trusts" (in a weak sense) the ISP's 279 router and the ISP's router can verify that the Site B is the only 280 one that can originate packets within the /48. 282 IPsec tunnel mode SA is recommended for this case which prevents 283 spoofing completely, though similar amount of protection can be 284 obtained with transport mode SA with strict ingress filtering (except 285 for link-local addresses) as well. 287 3.3 Host-to-Host Tunnels 289 .--------. _----_ .--------. 290 | V6/V4 | _( IPv4 )_ | V6/V4 | 291 | Host | <======( Internet )=====> | Host | 292 | A | (_ _) | B | 293 '--------' '----' '--------' 294 IPsec tunnel between 295 Host A and Host B 297 Figure 4: Host-to-Host Scenario 299 IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can 300 tunnel IPv6 packets between themselves. In this case, the tunnel 301 spans the entire end-to-end path that the packet takes. 303 In this case, the source and the destination IPv6 address are known a 304 priori. A tunnel mode SA can be bound to the specific address. The 305 address verification prevents IPv6 address spoofing completely. 307 4. IKE and IPsec Versions 309 This section discusses the different versions of the IKE and IPsec 310 security architecture and its applicability to this document. 312 IPsec security architecture is defined in [RFC2401] and 313 [I-D.ietf-ipsec-rfc2401bis]. There are several differences between 314 them. The difference relevants to this document are discussed below. 316 1. [RFC2401] does not allow IP as the next layer protocol in traffic 317 selectors when IPsec SA is negotiated. 318 [I-D.ietf-ipsec-rfc2401bis] allows IP also as the next layer 319 protocol like TCP or UDP in traffic selectors. 321 2. [RFC2401] does not support transport mode SAs between hosts and 322 security gateways. [I-D.ietf-ipsec-rfc2401bis] supports 323 transport mode SA between hosts and security gateway to provide 324 link security e.g., IP-IP tunnel protected with IPsec. 326 3. [I-D.ietf-ipsec-rfc2401bis] assumes IKEv2, as some of the new 327 features cannot be negotiated using IKEv1. It is valid to 328 negotiate multiple traffic selectors for a given IPsec SA in 329 [I-D.ietf-ipsec-rfc2401bis]. This is possible only with 330 [I-D.ietf-ipsec-ikev2]. If [RFC2409] is used, then multiple SAs 331 need to be setup for each of the traffic selector. 333 Note that the existing implementations based on [RFC2409] may already 334 be able to support the [I-D.ietf-ipsec-rfc2401bis] features described 335 in (1) and (2). If appropriate, the deployment may choose to use 336 them. 338 IKE is defined in [RFC2409] (which is referred to as IKE in this 339 document) and in [I-D.ietf-ipsec-ikev2] (which is referred to as 340 IKEv2 in this document). IKEv2 supports features that are useful for 341 configuring and securing tunnels which are not present with IKEv1. 343 1. IKEv2 supports legacy authentication methods by carrying them in 344 EAP payloads. This can be used to authenticate the hosts/sites 345 to the ISP using EAP methods that supports username and password. 347 2. IKEv2 supports dynamic address configuration which may be used to 348 configure the IPv6 address of the host. 350 NAT traversal works with both the old and revised IPsec 351 architectures, but the negotiation is integrated with IKEv2. 353 We do not consider the usage of the IP Authentication Header (AH) 354 [I-D.ietf-ipsec-rfc2402bis] as ESP [I-D.ietf-ipsec-esp-v3] provides 355 security services (such as integrity protection without 356 confidentiality protection using 'NULL' encryption) which are 357 comparable with AH. This is explicitly stated in 358 [I-D.ietf-ipsec-rfc2401bis]. 360 5. IPsec Configuration Details 362 This section describes details about the IPsec tunnel establishment 363 for protection of IPv4/IPv6 data traffic. 365 5.1 IPsec Transport mode 367 This is typically used in Router-to-Router scenario. 369 The following SPD entries assume that there are two routers Router1 370 and Router2, whose tunnel endpoint's IPv4 address is denoted by 371 IPV4-TEP1 and IPV4-TEP2 respectively. The implementations that are 372 strictly conformant to [RFC2401] may not be able to setup the IPsec 373 transport mode SA. 375 Router1's SPD OUT : 377 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 378 THEN USE ESP TRANSPORT MODE SA 380 Router1's SPD IN: 382 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 383 THEN USE ESP TRANSPORT MODE SA 385 Router2's SPD OUT: 387 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 388 THEN USE ESP TRANSPORT MODE SA 390 Router2's SPD IN: 392 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 393 THEN USE ESP TRANSPORT MODE SA 395 The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2 396 and protocol value 41 as phase 2 identities. With IKEv2, the traffic 397 selectors are used to carry the same information. 399 5.2 IPsec Tunnel mode 401 5.2.1 SPD for Host-to-Host Scenario 403 The following SPD entries assume that there are two hosts Host1 and 404 Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2 405 (global addresses) and IPV4 addresses of the tunnel endpoints are 406 denoted by IPV4-TEP1 and IPV4-TEP2 respectively. The first three 407 entries of the following SPD are used for protecting link-local 408 traffic: specifically Neighbor Discovery [RFC2461] (ND) and Multicast 409 Listener Discovery messages (MLD) [RFC2710]. 411 IKEv2 [I-D.ietf-ipsec-ikev2] provides the ability to negotiate a 412 single SA for multiple traffic selectors. It could be used here to 413 negotiate a single SA for global and link-local entries shown below. 415 Host1's SPD OUT : 417 IF SRC = ::/128 & destination = any 418 THEN USE ESP TUNNEL MODE SA: 419 outer source = IPv4-TEP1 420 outer dest = IPV4-TEP2 422 IF SRC = fe80::/10 & destination = any 423 THEN USE ESP TUNNEL MODE SA: 424 outer source = IPv4-TEP1 425 outer dest = IPV4-TEP2 427 IF SRC = any & destination = fe80::/10 428 THEN USE ESP TUNNEL MODE SA: 429 outer source = IPv4-TEP1 430 outer dest = IPV4-TEP2 432 IF SRC = IPV6-EP1 && DST = IPV6-EP2 433 THEN USE ESP TUNNEL MODE SA: 434 outer source = IPv4-TEP1 435 outer dest = IPV4-TEP2 437 Host1's SPD IN: 438 IF SRC = ::/128 & destination = any 439 THEN USE ESP TUNNEL MODE SA: 440 outer source = IPv4-TEP2 441 outer dest = IPV4-TEP1 443 IF SRC = fe80::/10 & destination = any 444 THEN USE ESP TUNNEL MODE SA: 445 outer source = IPv4-TEP2 446 outer dest = IPV4-TEP1 448 IF SRC = any & destination = fe80::/10 449 THEN USE ESP TUNNEL MODE SA: 450 outer source = IPv4-TEP2 451 outer dest = IPV4-TEP1 453 IF SRC = IPV6-EP2 && DST = IPV6-EP1 454 THEN USE ESP TUNNEL MODE SA 455 outer source = IPV4-TEP2 456 outer dest = IPV4-TEP1 458 Host2's SPD OUT: 460 IF SRC = ::/128 & destination = any 461 THEN USE ESP TUNNEL MODE SA: 462 outer source = IPv4-TEP2 463 outer dest = IPV4-TEP1 465 IF SRC = fe80::/10 & destination = any 466 THEN USE ESP TUNNEL MODE SA: 467 outer source = IPv4-TEP2 468 outer dest = IPV4-TEP1 470 IF SRC = any & destination = fe80::/10 471 THEN USE ESP TUNNEL MODE SA: 472 outer source = IPv4-TEP2 473 outer dest = IPV4-TEP1 475 IF SRC = IPV6-EP2 && DST = IPV6-EP1 476 THEN USE ESP TUNNEL MODE SA 477 outer source = IPV4-TEP2 478 outer dest = IPV4-TEP1 480 Host2's SPD IN: 482 IF SRC = ::/128 & destination = any 483 THEN USE ESP TUNNEL MODE SA: 484 outer source = IPv4-TEP1 485 outer dest = IPV4-TEP2 487 IF SRC = fe80::/10 & destination = any 488 THEN USE ESP TUNNEL MODE SA: 489 outer source = IPv4-TEP1 490 outer dest = IPV4-TEP2 492 IF SRC = any & destination = fe80::/10 493 THEN USE ESP TUNNEL MODE SA: 494 outer source = IPv4-TEP1 495 outer dest = IPV4-TEP2 497 IF SRC = IPV6-EP1 && DST = IPV6-EP2 498 THEN USE ESP TUNNEL MODE SA: 499 outer source = IPv4-TEP1 500 outer dest = IPV4-TEP2 502 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 503 or the link-local addresses from the packet headers as phase 2 504 identities. With IKEv2, the traffic selectors are used to carry the 505 same information. 507 5.2.2 SPD for Host-to-Router scenario 509 The following SPD entries assume that the host has the IPv6 address 510 IPV6-EP1 and the tunnel end points of the host and router are 511 IPV4-TEP1 and IPV4-TEP2 respectively. If the tunnel is between a 512 router and a host where the router has allocated a IPV6-PREF/48 to 513 the host, the corresponding SPD entries can be derived by 514 substituting IPV6-EP1 by IPV6-PREF/48. The first three entries of 515 the following SPD are used for protecting link-local traffic: 516 specifically Neighbor Discovery (ND) and Multicast Listener Discovery 517 messages (MLD). 519 IKEv2 [I-D.ietf-ipsec-ikev2] provides the ability to negotiate a 520 single SA for multiple traffic selectors. It could be used here to 521 negotiate a single SA for global and link-local entries shown below. 523 Host's SPD OUT: 525 IF SRC = ::/128 & destination = any 526 THEN USE ESP TUNNEL MODE SA: 527 outer source = IPv4-TEP1 528 outer dest = IPV4-TEP2 530 IF SRC = fe80::/10 & destination = any 531 THEN USE ESP TUNNEL MODE SA: 532 outer source = IPv4-TEP1 533 outer dest = IPV4-TEP2 535 IF SRC = any & destination = fe80::/10 536 THEN USE ESP TUNNEL MODE SA: 537 outer source = IPv4-TEP1 538 outer dest = IPV4-TEP2 540 IF SRC = IPV6-EP1 && DST = any 541 THEN use ESP TUNNEL MODE SA 542 outer source = IPV4-TEP1 543 outer dest = IPV4-TEP2 545 Host's SPD IN: 547 IF SRC = ::/128 & destination = any 548 THEN USE ESP TUNNEL MODE SA: 549 outer source = IPv4-TEP2 550 outer dest = IPV4-TEP1 552 IF SRC = fe80::/10 & destination = any 553 THEN USE ESP TUNNEL MODE SA: 554 outer source = IPv4-TEP2 555 outer dest = IPV4-TEP1 557 IF SRC = any & destination = fe80::/10 558 THEN USE ESP TUNNEL MODE SA: 559 outer source = IPv4-TEP2 560 outer dest = IPV4-TEP1 562 IF SRC = any && DST = IPV6-EP1 563 THEN use ESP TUNNEL MODE SA 564 outer source = IPV4-TEP2 565 outer dest = IPV4-TEP1 567 Router's SPD OUT: 569 IF SRC = ::/128 & destination = any 570 THEN USE ESP TUNNEL MODE SA: 571 outer source = IPv4-TEP2 572 outer dest = IPV4-TEP1 574 IF SRC = fe80::/10 & destination = any 575 THEN USE ESP TUNNEL MODE SA: 576 outer source = IPv4-TEP2 577 outer dest = IPV4-TEP1 579 IF SRC = any & destination = fe80::/10 580 THEN USE ESP TUNNEL MODE SA: 581 outer source = IPv4-TEP2 582 outer dest = IPV4-TEP1 584 IF SRC = any && DST = IPV6-EP1 585 THEN use ESP TUNNEL MODE SA 586 outer source = IPV4-TEP2 587 outer dest = IPV4-TEP1 589 Router's SPD IN: 591 IF SRC = ::/128 & destination = any 592 THEN USE ESP TUNNEL MODE SA: 593 outer source = IPv4-TEP1 594 outer dest = IPV4-TEP2 596 IF SRC = fe80::/10 & destination = any 597 THEN USE ESP TUNNEL MODE SA: 598 outer source = IPv4-TEP1 599 outer dest = IPV4-TEP2 601 IF SRC = any & destination = fe80::/10 602 THEN USE ESP TUNNEL MODE SA: 603 outer source = IPv4-TEP1 604 outer dest = IPV4-TEP2 606 IF SRC = IPV6-EP1 && DST = any 607 THEN use ESP TUNNEL MODE SA 608 outer source = IPV4-TEP1 609 outer dest = IPV4-TEP2 611 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and 612 ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity. 613 The starting address is zero IP address and the end address is all 614 ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address 615 and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. 616 Link-local addresses from the packet would be used if the packet 617 matches the first three selector entries of the SPD. With IKEv2, the 618 traffic selectors are used to carry the same information. 620 The packet format is the same for both transport mode and tunnel mode 621 as shown in Figure 8. 623 IPv4 header (source = IPV4-TEP1, 624 destination = IPV4-TEP2) 625 ESP header 626 IPv6 header (source = IPV6-EP1, 627 destination = IPV6-EP2) 629 Figure 8: Packet Format for transport and tunnel mode 631 6. Dynamic Address Configuration 633 With the exchange of protected configuration payloads, IKEv2 is able 634 to provide the IKEv2 peer with DHCP-like information payloads. These 635 configuration payloads are exchanged between the IKEv2 initiator and 636 the responder. 638 This can be used by the host in the host-to-router scenario to obtain 639 the IPv6 address from the ISP as part of setting up the IPsec tunnel 640 mode SA. 642 7. Extensible Authentication Support 644 In addition to the authentication mechanisms provided in IKEv2 the 645 Extensible Authentication Protocol (EAP) [I-D.ietf-eap-rfc2284bis] is 646 included which provides some flexibility for authentication 647 mechanisms. The usage of EAP offers two interesting features: 649 o User authentication is terminated at a different entity other than 650 the IKEv2 responder. This allows users' security credentials to 651 be kept in a central place (e.g., AAA server) and to terminate the 652 EAP method at this entity instead at the IKEv2 responder. 654 Authorization can also be executed at the same entity. 656 o A number of authentication and key exchange protocols are 657 supported via EAP method (such as EAP-AKA, EAP-SIM, SRP, etc.). 658 Each EAP methods provides its own properties and usage 659 environment. This provides a certain degree of flexibility. 661 Note that IKEv2 with EAP authentication still requires public key 662 based authentication of the IKEv2 responder outside the EAP 663 authentication. In most deployments this requires a server-side 664 public-key based authentication to protect the EAP exchange with a 665 uni-lateral authenticated tunnel. This method can be used in the 666 host-to-router scenario, where the host can use the traditional 667 (username, password) mechanism to authenticate to the router (ISP) 668 without needing additional configuration for IKE. 670 8. NAT Traversal 672 Network address (and port) translation devices are commonly found in 673 today's networks. A detailed description of the problem of IPsec 674 protected data traffic traversing a NAT including requirements are 675 discussed in [RFC3715]. 677 IKEv2 can detect the presence of a NAT automatically by sending an 678 Informational exchange with NAT_DETECTION_SOURCE_IP and 679 NAT_DETECTION_DESTINATION_IP payloads before establishing an IPsec 680 SA. These payloads are processed the same way as in the initial 681 IKE_SA_INIT exchange. Once a NAT is detected and both end points 682 support IPsec NAT traversal extensions UDP encapsulation can be 683 enabled. 685 More details about UDP encapsulation of IPsec protected IP packets 686 can be found in [I-D.ietf-ipsec-udp-encaps]. 688 For IPv6-over-IPv4 tunneling, NAT traversal is interesting for two 689 reasons: 691 1. One of the tunnel endpoints is often behind a NAT, and configured 692 tunneling, using protocol 41, is not guaranteed to traverse the 693 NAT. Hence, using IPsec tunnels would enable one to both set-up 694 a secure tunnel, and set-up a tunnel where it might not always be 695 possible without other tunneling mechanisms. 697 2. Using NAT traversal allows the outer address to change without 698 having to renegotiate the SAs. This could be very beneficial for 699 a crude form of mobility, and in scenarios the NAT changes the IP 700 addresses frequently. However, as the outer address may change, 701 this might introduce new security issues, and using tunnel mode 702 would be most appropriate. 704 9. Tunnel Endpoint Discovery 706 The IKEv2 initiator needs to know the address of the IKEv2 responder 707 to start IKEv2 signaling. A number of ways can be used to provide 708 the initiator with this information, for example: 710 o Using off-band mechanisms, e.g., from the ISP's web page. 712 o Using DNS to look up a service name by appending it to the DNS 713 search path provided by DHCPv4 (e.g. 714 "tunnel-service.example.com"). 716 o Using a DHCP option. 718 o Using a pre-configured or pre-determined IPv4 anycast address. 720 o Using other, unspecified or proprietary methods such as TED (see 721 [I-D.fluhrer-ted]). 723 For the purpose of this document it is assumed that this address can 724 be obtained somehow. Once the address has been learned, it is 725 configured as the tunnel end-point for the configured IPv6-over-IPv4 726 tunnel. 728 This problem is also discussed at more length in 729 [I-D.palet-v6ops-tun-auto-disc]. 731 10. IANA Considerations 733 This memo makes no request to IANA. [[ Please remove this section at 734 publication ]] 736 11. Security Considerations 738 When you run IPv6-in-IPv4 tunnels (unsecured) over the Internet, it 739 is possible to "inject" packets in the tunnel by spoofing the source 740 address (data plane security), or if the tunnel is signalled somehow 741 (e.g., some messages where you authenticate to the server, so that 742 you would get a static v6 prefix), someone might be able to spoof the 743 signalling (control plane security). 745 To add security to both, the protocol for tunnel setup and to the 746 data traffic, the IPsec framework plays an important role. 748 IKE is a signaling protocol with optional Denial of Service 749 protection which authenticates both end points (with different 750 identifities) and establishes two types of security associations 751 (CHILD-SAs and IKE-SA). The authentication mechanisms are very 752 flexible due to the built-in support for symmetric and asymmetric 753 cryptography (or even a combination of both) and the Extensible 754 Authentication Protocol support. The IKE-SA is used to secure most 755 of the IKE message exchange. In particular the CHILD-SA exchange, 756 Informational exchanges (such as the dead-peer detection mechanisms 757 used for liveness checks) and the exchange of configuration messages 758 are secured. The CHILD-SA exchange leads to the establishment of a 759 IPsec tunnel and the creation of SAD and SPD entries. 761 As a summary, IKE provides a secure signaling protocol for 762 establishing, maintaining and deleting an IPsec tunnel. 764 IPsec, with the Encapsulating Security Payload (ESP), offers 765 integrity and data origin authentication, confidentiality, with 766 optional (at the discretion of the receiver) anti-replay features. 767 The usage of confidentity-only is discouraged. ESP furthermore 768 provides limited traffic flow confidentality. 770 IPsec provides access control mechanisms through the distribution of 771 keys and also through the usage of policies dictated by the Security 772 Policy Database (SPD). Furthermore, through the usage of EAP and the 773 backend AAA infrastructure it is possible to enforce additional 774 authorization mechanisms (at the user level) at entities other than 775 the tunnel end points. 777 The NAT traversal mechanism provided by IKE introduces some 778 weaknesses into IKE and IPsec. These issues are discussed in more 779 detail in [I-D.ietf-ipsec-ikev2]. 781 Please note that the usage of IPsec for the scenarios described in 782 Figure 3, Figure 2 and Figure 1 does not aim to protect the 783 end-to-end communication. It protects just the tunnel part. It is 784 still possible for an IPv6 endpoint that is not attached to the IPsec 785 tunnel to spoof packets. 787 12. Open Issues 789 This section lists some open issues for which feedback/text would be 790 especially useful, and will be resolved in one way or another in a 791 future revision. 793 o Discussion of 'Use of IPsec Transport Mode for Dynamic Routing' 794 [I-D.touch-ipsec-vpn] might be appropriate. 796 o A more detailed description of the address configuration mechanism 797 would be helpful. The configuration example with 798 CFG_REQUEST/CFG_REPLY payloads should contain IPv6 addresses. 800 o Some notes on the implications of mobility interworking are still 801 missing. 803 o The "Site-to-Router" scenarios separation is a bit weak -- any 804 better ideas how to categorize these would be appreciated. 806 o More extensive discussion of when transport/tunnel mode SAs make 807 sense and would probably be useful. 809 13. Contributors 811 The authors are listed in alphabetical order. 813 Suresh Satapati also participated in the discussions. 815 14. Acknowledgments 817 The authors would like to thank Stephen Kent and Michael Richardson 818 for their comments. 820 We would like to thank Pasi Eronen for his text contributions. 822 15. References 824 15.1 Normative References 826 [I-D.ietf-eap-rfc2284bis] 827 Blunk, L., "Extensible Authentication Protocol (EAP)", 828 draft-ietf-eap-rfc2284bis-09 (work in progress), February 829 2004. 831 [I-D.ietf-ipsec-esp-v3] 832 Kent, S., "IP Encapsulating Security Payload (ESP)", 833 draft-ietf-ipsec-esp-v3-09 (work in progress), October 834 2004. 836 [I-D.ietf-ipsec-ikev2] 837 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 838 draft-ietf-ipsec-ikev2-17 (work in progress), October 839 2004. 841 [I-D.ietf-ipsec-rfc2401bis] 842 Kent, S. and K. Seo, "Security Architecture for the 843 Internet Protocol", draft-ietf-ipsec-rfc2401bis-05 (work 844 in progress), December 2004. 846 [I-D.ietf-ipsec-udp-encaps] 847 Huttunen, A., "UDP Encapsulation of IPsec Packets", 848 draft-ietf-ipsec-udp-encaps-09 (work in progress), May 849 2004. 851 [I-D.ietf-v6ops-mech-v2] 852 Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 853 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06 854 (work in progress), September 2004. 856 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 857 Discovery for IP Version 6 (IPv6)", RFC 2461, December 858 1998. 860 [RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast 861 Listener Discovery (MLD) for IPv6", RFC 2710, October 862 1999. 864 15.2 Informative References 866 [I-D.bellovin-useipsec] 867 Bellovin, S., "Guidelines for Mandating the Use of IPsec", 868 draft-bellovin-useipsec-03 (work in progress), March 2004. 870 [I-D.blanchet-v6ops-tunnelbroker-tsp] 871 Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the 872 Tunnel Setup Protocol(TSP)", 873 draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in 874 progress), June 2004. 876 [I-D.fluhrer-ted] 877 Fluhrer, S., "Tunnel Endpoint Discovery", 878 draft-fluhrer-ted-00 (work in progress), November 2001. 880 [I-D.ietf-ipsec-rfc2402bis] 881 Kent, S., "IP Authentication Header", 882 draft-ietf-ipsec-rfc2402bis-10 (work in progress), 883 December 2004. 885 [I-D.palet-v6ops-tun-auto-disc] 886 Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point 887 Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-02 888 (work in progress), October 2004. 890 [I-D.touch-ipsec-vpn] 891 Touch, J., Eggert, L. and Y. Wang, "Use of IPsec Transport 892 Mode for Dynamic Routing", draft-touch-ipsec-vpn-07 (work 893 in progress), March 2004. 895 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 896 Internet Protocol", RFC 2401, November 1998. 898 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 899 (IKE)", RFC 2409, November 1998. 901 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 902 Networks", BCP 84, RFC 3704, March 2004. 904 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 905 (NAT) Compatibility Requirements", RFC 3715, March 2004. 907 Authors' Addresses 909 Richard Graveman 910 RFG Security, LLC 911 15 Park Avenue 912 Morristown, New Jersey 07960 913 USA 915 EMail: rfg@acm.org 917 Mohan Parthasarathy 918 Nokia 919 313 Fairchild Drive 920 Mountain View CA-94043 921 USA 923 EMail: mohanp@sbcglobal.net 925 Pekka Savola 926 CSC/FUNET 927 Espoo 928 Finnland 930 EMail: psavola@funet.fi 931 Hannes Tschofenig 932 Siemens 933 Otto-Hahn-Ring 6 934 Munich, Bayern 81739 935 Germany 937 EMail: Hannes.Tschofenig@siemens.com 939 Intellectual Property Statement 941 The IETF takes no position regarding the validity or scope of any 942 Intellectual Property Rights or other rights that might be claimed to 943 pertain to the implementation or use of the technology described in 944 this document or the extent to which any license under such rights 945 might or might not be available; nor does it represent that it has 946 made any independent effort to identify any such rights. Information 947 on the procedures with respect to rights in RFC documents can be 948 found in BCP 78 and BCP 79. 950 Copies of IPR disclosures made to the IETF Secretariat and any 951 assurances of licenses to be made available, or the result of an 952 attempt made to obtain a general license or permission for the use of 953 such proprietary rights by implementers or users of this 954 specification can be obtained from the IETF on-line IPR repository at 955 http://www.ietf.org/ipr. 957 The IETF invites any interested party to bring to its attention any 958 copyrights, patents or patent applications, or other proprietary 959 rights that may cover technology that may be required to implement 960 this standard. Please address the information to the IETF at 961 ietf-ipr@ietf.org. 963 Disclaimer of Validity 965 This document and the information contained herein are provided on an 966 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 967 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 968 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 969 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 970 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 971 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 973 Copyright Statement 975 Copyright (C) The Internet Society (2004). This document is subject 976 to the rights, licenses and restrictions contained in BCP 78, and 977 except as set forth therein, the authors retain all their rights. 979 Acknowledgment 981 Funding for the RFC Editor function is currently provided by the 982 Internet Society.