idnits 2.17.1 draft-tschofenig-v6ops-secure-tunnels-01.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 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1014. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 991. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 998. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1004. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1020), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 332: '... implementations MUST implement ESP an...' RFC 2119 keyword, line 364: '...t implementation MUST NOT allow instan...' RFC 2119 keyword, line 607: '...dentity-Response payload SHOULD NOT be...' 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 19, 2004) is 7214 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) == Missing Reference: 'CERTREQ' is mentioned on line 621, but not defined == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 861, but no explicit reference was found in the text == Unused Reference: 'I-D.dupont-ikev2-addrmgmt' is defined on line 872, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pana-ipsec' is defined on line 908, but no explicit reference was found in the text == Unused Reference: 'I-D.kivinen-mobike-design' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 928, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 932, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-07 == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-08 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-13 == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-ikev2-algorithms-04 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-01 == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-08 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-ui-suites-04 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-02 == 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-00 == Outdated reference: A later version (-08) exists of draft-dupont-ikev2-addrmgmt-04 == Outdated reference: A later version (-07) exists of draft-eronen-ipsec-ikev2-eap-auth-00 == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-03 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-01 == Outdated reference: A later version (-02) exists of draft-ietf-ipsec-ikev2-iana-01 == Outdated reference: A later version (-11) exists of draft-ietf-ipsec-rfc2402bis-07 == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-02 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 9 errors (**), 0 flaws (~~), 26 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Operations WG R. Graveman 2 Internet-Draft RFG Security, LLC 3 Expires: January 17, 2005 M. Parthasarathy 4 Nokia 5 P. Savola 6 CSC/FUNET 7 H. Tschofenig 8 Siemens 9 July 19, 2004 11 Using IPsec to Secure IPv6-over-IPv4 Tunnels 12 draft-tschofenig-v6ops-secure-tunnels-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 17, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This document gives guidance on securing IPv6-in-IPv4 tunnels using 46 IPsec. No additional protocol extensions are described beyond those 47 available with the revised IPsec framework. IKEv2 is extensively 48 used as an authentication and key exchange protocol to cover address 49 configuration procedures, and the usage of the Extensible 50 Authentication Procotol and NAT traversal capabilities is also 51 described. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3 57 2.1 IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4 58 2.2 IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 4 59 3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5 60 3.1 Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 5 61 3.2 Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 5 62 3.3 Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 7 63 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 9 65 5.1 IPsec Transport mode . . . . . . . . . . . . . . . . . . . 9 66 5.2 IPsec Tunnel mode . . . . . . . . . . . . . . . . . . . . 9 67 5.2.1 SPD for Host-to-Host Scenario . . . . . . . . . . . . 9 68 5.2.2 SPD for Host-to-Router scenario . . . . . . . . . . . 10 69 6. Dynamic Address Configuration . . . . . . . . . . . . . . . . 12 70 7. Extensible Authentication Support . . . . . . . . . . . . . . 13 71 8. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 15 72 9. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . . . 16 73 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 11. Security Considerations . . . . . . . . . . . . . . . . . . 17 75 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 18 76 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 77 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 78 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 15.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 80 15.2 Informative References . . . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 82 Intellectual Property and Copyright Statements . . . . . . . . 23 84 1. Introduction 86 The IPv6 operations (v6ops) working group has selected IPv6-in-IPv4 87 tunneling [I-D.ietf-v6ops-mech-v2] as one of the IPv6 transition 88 mechanisms for IPv6 deployment. A number of threats have been 89 identified with possible solutions to mitigate them 90 [I-D.ietf-v6ops-mech-v2]. One of the solutions is the use of IPsec 91 protected tunnels, but there is little detail on how IPsec would 92 actually be used in an interoperable manner. This memo describes the 93 use of IPsec in detail. 95 First this document analyses the threats that can be addressed by 96 IPsec. Next, this document discusses some of the assumptions made by 97 this document for successful IPsec SA establishment. Then, it gives 98 the details of IKE/IPsec exchange with packet formats and SPD 99 entries. Finally, it discusses the usage of IPsec NAT-traversal 100 mechanism that can be used with configured tunnels in some scenarios. 102 2. Threats and the Use of IPsec 104 Following threats have been identified in [I-D.ietf-v6ops-mech-v2]: 106 1. IPv4 address of the encapsulating ("outer") packet can be 107 spoofed. 109 2. IPv6 address of the encapsualted ("inner") packet can be spoofed. 111 The reason for threat (1) is due to the lack of widespread deployment 112 of IPv4 ingress filtering in the network. The reason for threat (2) 113 is that the IPv6 packet is encapsulated in IPv4 and hence escapes 114 IPv6 ingress filtering. [I-D.ietf-v6ops-mech-v2] specifies following 115 strict address checks as mitigating measures. 117 To mitigate threat (1), the decapsulator verifies that the IPv4 118 source address of the packet is the same as the address of the 119 configured tunnel endpoint. The decapsulator may also implement IPv4 120 ingress filtering, i.e., checks whether the packet is received on a 121 legitimate interface. 123 To mitigate threat (2), the decapsulator verifies whether the inner 124 IPv6 address is a valid IPv6 address and also applies IPv6 ingress 125 filtering before accepting the IPv6 packet. 127 This memo proposes using IPsec for providing stronger security in 128 preventing these threats. IPsec can be used in two ways, in 129 transport and tunnel mode. 131 2.1 IPsec in Transport Mode 133 In transport mode, the IPsec security association (SA) is established 134 to protect the traffic defined by (IPv4-source, IPv4-dest, protocol = 135 41). On receiving such an IPsec packet, the receiver first applies 136 the IPsec transform (ESP) and then matches the packet against the 137 inbound selectors associated with the SA to verify that the packet is 138 appropriate for the SA via which it was received. The successful 139 verification implies that the packet came from the right IPv4 140 endpoint as the SA is bound to the IPv4 source address. 142 This prevents threat (1) but not the threat (2). IPsec in transport 143 mode does not verify the contents of the payload itself where the 144 IPv6 addresses are carried, that is, two nodes that are using IPsec 145 transport mode to secure the tunnel can spoof the inner payload. The 146 packet will be decapsulated successfully and accepted. 148 The shortcoming can be mitigated by IPv6 ingress filtering i.e., 149 check that the packet is arriving from the interface in the direction 150 of the route towards the tunnel end-point, similar to a Strict 151 Reverse Path Forwarding (RPF) check [RFC3704]. 153 For performing ingress filtering, it is assumed that the tunnel is 154 modelled as an interface and the traffic of the tunnel is protected 155 using IPsec transport mode SA. 157 2.2 IPsec in Tunnel Mode 159 In tunnel mode, the IPsec SA is established to protect the traffic 160 defined by (IPv6-source, IPv6-destination). On receiving such an 161 IPsec packet, the receiver first applies the IPsec transform (ESP) 162 and then matches the packet against the inbound selectors associated 163 with the SA to verify that the packet is appropriate for the SA via 164 which it was received. The successful verification implies that the 165 packet came from the right IPv6 endpoint as the SA is bound to the 166 IPv6 source address. 168 The IPv4 addresses may be spoofed and IPsec cannot detect it in this 169 mode, that is, two nodes that are using IPsec tunnel mode to secure 170 the tunnel with a common tunnel endpoint can spoof each other's IPv4 171 address. But, the packet will not be accepted by IPsec as the IPv6 172 address bound to the SA will not match the address in the spoofed 173 packet. Thus, the outer address spoofing is irrelevant as long as 174 the inner IPv6 packet can be verified to come from the right IPv6 175 endpoint. 177 It may not be possible to always verify the IPv6 address -- for 178 example with link-local addresses. The additional issues with 179 address verification are discussed in each of the scenarios section 180 appropriately. 182 3. Scenarios and Overview 184 There are roughly three kinds of scenarios: (generic) 185 router-to-router tunnels, site-to-router/router-to-site tunnels (a 186 generalization of host-to-router/router-to-host scenarios, 187 respectively), and host-to-host tunnels. 189 3.1 Router-to-Router Tunnels 191 IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of 192 IPv4 routing topology by encapsulating them within IPv4 packets. 193 Tunneling can be used in a variety of ways. 195 .--------. _----_ .--------. 196 |v6-in-v4| _( IPv4 )_ |v6-in-v4| 197 | Router | <======( Internet )=====> | Router | 198 | A | (_ _) | B | 199 '--------' '----' '--------' 200 ^ IPsec tunnel between ^ 201 | Router A and Router B | 202 V V 203 .--------. .-------. 204 | End | | End | 205 | Host | | Host | 206 '--------' '--------' 208 Figure 1: Router-to-Router Scenario 210 IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel 211 IPv6 packets between themselves. In this case, the tunnel spans one 212 segment of the end-to-end path that the IPv6 packet takes. 214 The source and destination addresses of the IPv6 packets traversing 215 the tunnel could come from a wide range of IPv6 prefixes. It is not 216 scalable to establish IPsec tunnel mode SAs for all such packets. 217 Hence, IPsec transport mode SA is recommended for this scenario. 218 IPv6 ingress filtering should be performed to mitigate the IPv6 219 address spoofing threat. 221 A specific case of router-to-router tunnels, when one router resides 222 at an end site, is described in the next section. 224 3.2 Site-to-Router/Router-to-Site Tunnels 226 This is a generalization of site-to-router and router-to-site 227 tunneling, because the issues when connecting a whole site (using a 228 router), and connecting a single host are roughly equal. 230 _----_ .---------. IPsec _----_ IPsec .-------. 231 _( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 | 232 ( Internet )<--->| Router |<=======( Internet )=======>| Site B | 233 (_ _) | A | (_ _) '--------' 234 '----' '---------' '----' 235 ^ 236 | 237 V 238 .--------. 239 | Native | 240 | IPv6 | 241 | node | 242 '--------' 244 Figure 2: Router-to-Site Scenario 246 IPv6/IPv4 routers can tunnel IPv6 packets to their final destination 247 IPv6/IPv4 host. This tunnel spans only the last segment of the 248 end-to-end path. 250 This is the same as the Site-to-Router case. 252 +---------------------+ 253 | IPv6 Network | 254 | | 255 .--------. _----_ | .--------. | 256 | V6/V4 | _( IPv4 )_ | |v6-in-v4| | 257 | Site B |<====( Internet )==========>| Router | | 258 '--------' (_ _) | | A | | 259 '----' | '--------' | 260 IPsec tunnel between | ^ | 261 V6 Site and Router A | | | 262 | V | 263 | .-------. | 264 | | V6 | | 265 | | Host | | 266 | '--------' | 267 +---------------------+ 269 Figure 3: Site-to-Router Scenario 271 IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 272 router that is reachable via an IPv4 infrastructure. This type of 273 tunnel spans the first segment of the packet's end-to-end path. 275 In this case, the host(s) originate the packet with source address 276 coming from a well known prefix whereas the destination address could 277 be any node on the internet. In this case, the IPsec tunnel mode SA 278 can be bound to the prefix that was allocated to the router at Site B 279 and router A can verify that the source address of the packet matches 280 the prefix. Site B will not be able to do a similar verification for 281 the packets it receives. This may be quite reasonable for most of 282 the deployment cases, for example, the ISP allocating a /48 to a 283 customer. The CPE (where the tunnel is terminated) "trusts" (in a 284 weak sense) the ISP's router and the ISP's router can verify that the 285 Site B is the only one that can originate packets within the /48. 286 IPsec tunnel mode SA is recommended for this case, though similar 287 amount of protection can be obtained with transport mode SA with 288 strict ingress filtering as well. 290 3.3 Host-to-Host Tunnels 292 .--------. _----_ .--------. 293 | V6/V4 | _( IPv4 )_ | V6/V4 | 294 | Host | <======( Internet )=====> | Host | 295 | A | (_ _) | B | 296 '--------' '----' '--------' 297 IPsec tunnel between 298 Host A and Host B 300 Figure 4: Host-to-Host Scenario 302 IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can 303 tunnel IPv6 packets between themselves. In this case, the tunnel 304 spans the entire end-to-end path that the packet takes. 306 In this case, the source and the destination IPv6 address are known a 307 priori. A tunnel mode SA can be bound to the specific address. The 308 address verification prevents IPv6 address spoofing completely. 310 4. Assumptions 312 Throughout this document we make a few assumptions which are briefly 313 listed here. The following documents are used as a basis: 315 o Revised 'Security Architecture for the Internet Protocol' as 316 described in [I-D.ietf-ipsec-rfc2401bis]. 318 o IKEv2 as described in [I-D.ietf-ipsec-ikev2] and the accompanying 319 documents for cipher suites and cryptgraphic algorithms (see 320 [I-D.ietf-ipsec-ikev2-algorithms], [I-D.ietf-ipsec-ikev2-iana] and 321 [I-D.ietf-ipsec-ui-suites]). 323 o 'IP Encapsulating Security Payload (ESP)' as described in 324 [I-D.ietf-ipsec-esp-v3] 326 o 'UDP Encapsulation of IPsec Packets' as described in 327 [I-D.ietf-ipsec-udp-encaps] for the purpose of NAT traversal. 329 Please note that we do not consider the usage of the IP 330 Authentication Header (AH) [I-D.ietf-ipsec-rfc2402bis] since Section 331 3.2 of [I-D.ietf-ipsec-rfc2401bis] specifies that IPsec 332 implementations MUST implement ESP and MAY implement AH with the 333 reasoning that ESP provides security services (such as integrity 334 protection without confidentiality protection using 'NULL' 335 encryption) which are comparable with AH. 337 Furthermore, we focus on IKEv2 since [I-D.ietf-ipsec-rfc2401bis] 338 assumes use of IKEv2 as a key and security association management 339 system and not IKEv1 with its extensions. 341 The decision to focus on IKEv2 and newer IPsec documents is based on 342 the premise that doing so allows using "mixed-mode" transforms as 343 described below. This is useful for Transport mode SAs. Some 344 implementations might, however, support these SAs already, at least 345 using manual configuration. 347 The support of IPv4/IPv6 transition capabilities with IPsec is 348 possible with [RFC2401] and with [I-D.ietf-ipsec-rfc2401bis] (see 349 Section 5.1.2 of [I-D.ietf-ipsec-rfc2401bis]). IPsec allows the IP 350 version of the encapsulating header to be different from that of the 351 inner header. 353 The IPsec framework does not allow IKEv1/IKEv2 to be used to create 354 tunnels which do not experience cryptographic protection although 355 this functionality might be useful in some environments. IKEv2 would 356 then migrate into a secure signaling protocol for tunnel 357 establishment (without implementing data traffic protection) in a 358 fashion similar to the 'IPv6 Tunnel Broker with the Tunnel Setup 359 Protocol (TSP)' [I-D.blanchet-v6ops-tunnelbroker-tsp] protocol 360 proposal. Section 4.2 of [I-D.ietf-ipsec-rfc2401bis], however, 361 prohibits this functionality by stating: 363 " 364 A compliant implementation MUST NOT allow instantiation of an ESP SA 365 that employs both NULL encryption and no integrity algorithm. 366 " 368 Regarding the usage of the Explicit Congestion Notification (ECN), it 369 appears that the ECN bits in the IPv4 and IPv6 headers have exactly 370 the same semantics, so the bits just need to be copied from the outer 371 IPv4 header to the inner IPv6 header on tunnel exit. 373 5. IPsec Configuration Details 375 This section describes details about the IPsec tunnel establishment 376 for protection of IPv4/IPv6 data traffic. 378 5.1 IPsec Transport mode 380 This is typically used in Router-to-Router scenario. 382 The following SPD entries assume that there are two routers Router1 383 and Router2, whose tunnel endpoint's IPv4 address is denoted by 384 IPV4-TEP1 and IPV4-TEP2 respectively. 386 Router1's SPD OUT : 388 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 389 THEN USE ESP TRANSPORT MODE SA 391 Router1's SPD IN: 393 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 394 THEN USE ESP TRANSPORT MODE SA 396 Router2's SPD OUT: 398 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 399 THEN USE ESP TRANSPORT MODE SA 401 Router2's SPD IN: 403 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 404 THEN USE ESP TRANSPORT MODE SA 406 The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2 407 and protocol value 41 as phase 2 identities. With IKEv2, the traffic 408 selectors are used to carry the same information. 410 5.2 IPsec Tunnel mode 412 5.2.1 SPD for Host-to-Host Scenario 414 The following SPD entries assume that there are two hosts Host1 and 415 Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2 and 416 IPV4 addresses of the tunnel endpoints are denoted by IPV4-TEP1 and 417 IPV4-TEP2 respectively. 419 Host1's SPD OUT : 421 IF SRC = IPV6-EP1 && DST = IPV6-EP2 422 THEN USE ESP TUNNEL MODE SA: 423 outer source = IPv4-TEP1 424 outer dest = IPV4-TEP2 426 Host1's SPD IN: 428 IF SRC = IPV6-EP2 && DST = IPV6-EP1 429 THEN USE ESP TUNNEL MODE SA 430 outer source = IPV4-TEP2 431 outer dest = IPV4-TEP1 433 Host2's SPD OUT: 435 IF SRC = IPV6-EP2 && DST = IPV6-EP1 436 THEN USE ESP TUNNEL MODE SA 437 outer source = IPV4-TEP2 438 outer dest = IPV4-TEP1 440 Host2's SPD IN: 442 IF SRC = IPV6-EP1 && DST = IPV6-EP2 443 THEN USE ESP TUNNEL MODE SA: 444 outer source = IPv4-TEP1 445 outer dest = IPV4-TEP2 447 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 448 as phase 2 identities. With IKEv2, the traffic selectors are used to 449 carry the same information. 451 5.2.2 SPD for Host-to-Router scenario 453 The following SPD entries assume that the host has the IPv6 address 454 IPV6-EP1 and the tunnel end points of the host and router are 455 IPV4-TEP1 and IPV4-TEP2 respectively. If the tunnel is between a 456 router and a host where the router has allocated a IPV6-PREF/48 to 457 the host, the corresponding SPD entries can be derived by 458 substituting IPV6-EP1 by IPV6-PREF/48. 460 Host's SPD OUT: 462 IF SRC = IPV6-EP1 && DST = any 463 THEN use ESP TUNNEL MODE SA 464 outer source = IPV4-TEP1 465 outer dest = IPV4-TEP2 467 Host's SPD IN: 469 IF SRC = any && DST = IPV6-EP1 470 THEN use ESP TUNNEL MODE SA 471 outer source = IPV4-TEP1 472 outer dest = IPV4-TEP2 474 Router's SPD OUT: 476 IF SRC = any && DST = IPV6-EP1 477 THEN use ESP TUNNEL MODE SA 478 outer source = IPV4-TEP1 479 outer dest = IPV4-TEP2 481 Router's SPD IN: 483 IF SRC = IPV6-EP1 && DST = any 484 THEN use ESP TUNNEL MODE SA 485 outer source = IPV4-TEP1 486 outer dest = IPV4-TEP2 488 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and 489 ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity. 490 The starting address is zero IP address and the end address is all 491 ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address 492 and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With 493 IKEv2, the traffic selectors are used to carry the same information. 495 To describe the packet format the following acronyms are used 496 throughout this document: 498 o IPV4-TEP1 and IPV4-TEP2 denote the IPv4 address of the tunnel 499 endpoints. 501 o IPV6-EP1 and IPV6-EP2 denote the IPv6 address of the two IPv6 502 endpoints of the communication. 504 The packet format is the same for both transport mode and tunnel mode 505 as shown in Figure 9. 507 IPv4 header (source = IPV4-TEP1, 508 destination = IPV4-TEP2) 509 ESP header 510 IPv6 header (source = IPV6-EP1, 511 destination = IPV6-EP2) 513 Figure 9: Packet Format for transport and tunnel mode 515 This type of layering may not be valid with [RFC2401] since, with a 516 strict definition, IP does not meet the definition of a "higher layer 517 protocol" being the next protocol after an IP header. 519 With [I-D.ietf-ipsec-rfc2401bis] the definition about the "next layer 520 protocol" was explicitly expanded and hence this type of layering is 521 valid. 523 6. Dynamic Address Configuration 525 With the exchange of protected configuration payloads, IKEv2 is able 526 to provide the IKEv2 peer with DHCP-like information payloads. These 527 configuration payloads are exchanged between the IKEv2 initiator and 528 the responder with the help of the CFG_REQUEST/CFG_REPLY and CFG_SET/ 529 CFG_ACK payloads. The former is used to request information and the 530 latter allows pushing configuration data. Configuration information 531 (e.g., a temporary address) can be carried in any request to create a 532 CHILD_SA by including a CP payload. 534 These configuration payloads are primiarly used for bootstrapping the 535 IKEv2 peer. Although these payloads are extensible they are not used 536 as a generic purpose management. 538 The following example exchange illustrates the usage of configuration 539 payloads: 541 Initiator Responder 542 ------------- -------------- 543 HDR, SAi1, KEi, Ni --> 545 <-- HDR(A,0), N(COOKIE) 547 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 549 <-- HDR, SAr1, KEr, Nr,[CERTREQ] 551 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 552 AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> 554 <-- HDR, SK {IDr, [CERT,] AUTH, 555 CP(CFG_REPLY), SAr2, TSi, TSr} 557 Figure 10: IKEv2 Configuration payload payload exchange 559 The example message exchange shown in Figure 10 shows IKEv2 with a 560 denial of service protection enabled exchange and a CFG_REQUEST in 561 message 5 and the corresponding response in message 6. The content 562 of these payloads, for example, contains (as given in Section 2.19 of 563 [I-D.ietf-ipsec-ikev2]): 565 CP(CFG_REQUEST)= 566 INTERNAL_ADDRESS(0.0.0.0) 567 INTERNAL_NETMASK(0.0.0.0) 568 INTERNAL_DNS(0.0.0.0) 569 TSi = (0, 0-65536,0.0.0.0-255.255.255.255) 570 TSr = (0, 0-65536,0.0.0.0-255.255.255.255) 572 CP(CFG_REPLY)= 573 INTERNAL_ADDRESS(10.168.219.202) 574 INTERNAL_NETMASK(255.255.255.0) 575 INTERNAL_SUBNET(10.168.219.0/255.255.255.0) 576 TSi = (0, 0-65536,10.168.219.202-10.168.219.202) 577 TSr = (0, 0-65536,10.168.219.0-10.168.219.255) 579 7. Extensible Authentication Support 581 In addition to the authentication mechanisms provided in IKEv2 the 582 Extensible Authentication Protocol (EAP) [I-D.ietf-eap-rfc2284bis] is 583 included which provides some flexibility for authentication 584 mechanisms. Figure 12 shows an example IKEv2 exchange with EAP 585 support. The usage of EAP offers two interesting features: 587 o User authentication is terminated at a different entity other than 588 the IKEv2 responder. This allows users' security credentials to 589 be kept in a central place (e.g., AAA server) and to terminate the 590 EAP method at this entity instead at the IKEv2 responder. 591 Authorization can also be executed at the same entity. 593 o A number of authentication and key exchange protocols are 594 supported via EAP method (such as EAP-AKA, EAP-SIM, SRP, etc.). 595 Each EAP methods provides its own properties and usage 596 environment. This provides a certain degree of flexibility. 598 Note that IKEv2 with EAP authentication still requires public key 599 based authentication of the IKEv2 responder outside the EAP 600 authentication. In most deployments this requires a server-side 601 public-key based authentication to protect the EAP exchange with a 602 uni-lateral authenticated tunnel. With the extensions proposed in 603 [I-D.eronen-ipsec-ikev2-eap-auth] only EAP authentication is used by 604 omitting the IKEv2 responder authentication. 606 Please note that Section 3.16 of [I-D.ietf-ipsec-ikev2] indicates 607 that the EAP Identity-Request/Identity-Response payload SHOULD NOT be 608 used. The IDr payload (message 3 in Figure 12) carries this identity 609 instead. As a consequence active user identity confidentiality for 610 the IKEv2 initiator is not provided. Special purpose EAP methods 611 must be used instead if this features is desired. 613 Figure 12 shows an example IKEv2 message exchange with EAP-AKA as an 614 EAP method. Note that the interaction between the IKEv2 responder 615 and the AAA infrastructure is not shown. 617 Initiator Responder 618 ------------- -------------- 619 HDR, SAi1, KEi, Ni --> 621 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 623 HDR, SK {IDi, [CERTREQ,] [IDr,] 624 SAi2, TSi, TSr} --> 626 <-- HDR, SK {IDr, [CERT,] AUTH, 627 EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) } 629 HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)} --> 631 <-- HDR, SK {EAP-Success, AUTH} 633 HDR, SK { AUTH } --> 635 <-- HDR, SK { SAr2, TSi, TSr } 637 Figure 12: EAP usage in IKEv2 with EAP-AKA 639 EAP will typically be used with a backend AAA server which raises 640 some security concerns. See [I-D.ietf-eap-keying] for a more 641 complete discussion of these security issues. 643 When a backend server is used, there are actually two authentication 644 exchanges: the EAP method between the client and the AAA server, and 645 another authentication between the AAA server and IKEv2 gateway. The 646 AAA server authenticates the client using the selected EAP method, 647 and they establish a session key. The AAA server then sends this key 648 to the IKEv2 gateway over a connection authenticated using e.g. 649 IPsec or TLS. The protocol used between the IKEv2 responder and the 650 AAA server could be, for instance, Diameter or RADIUS [RFC3579]. 651 RADIUS and Diameter are able to carry EAP payloads as described in 652 [RFC3579] and in [I-D.ietf-aaa-eap], respectively. 654 8. NAT Traversal 656 Network address (and port) translation devices are commonly found in 657 today's networks. A detailed description of the problem of IPsec 658 protected data traffic traversing a NAT including requirements are 659 discussed in [RFC3715]. 661 IKEv2 can detect the presence of a NAT automatically by sending an 662 Informational exchange with NAT_DETECTION_SOURCE_IP and 663 NAT_DETECTION_DESTINATION_IP payloads before establishing an IPsec 664 SA. These payloads are processed the same way as in the initial 665 IKE_SA_INIT exchange. Once a NAT is detected and both end points 666 support IPsec NAT traversal extensions UDP encapsulation can be 667 enabled. 669 More details about UDP encapsulation of IPsec protected IP packets 670 can be found in [I-D.ietf-ipsec-udp-encaps]. 672 For IPv6-over-IPv4 tunneling, NAT traversal is interesting for two 673 reasons: 675 1. One of the tunnel endpoints is often behind a NAT, and configured 676 tunneling, using protocol 41, is not guaranteed to traverse the 677 NAT. Hence, using IPsec tunnels would enable one to both set-up 678 a secure tunnel, and set-up a tunnel where it might not always be 679 possible without other tunneling mechanisms. 681 2. Using NAT traversal allows the outer address to change without 682 having to renegotiate the SAs. This could be very beneficial for 683 a crude form of mobility, and in scenarios the NAT changes the IP 684 addresses frequently. However, as the outer address may change, 685 this might introduce new security issues, and using tunnel mode 686 would be most appropriate. 688 9. Tunnel Endpoint Discovery 690 The IKEv2 initiator needs to know the address of the IKEv2 responder 691 for IKEv2 signaling. A number of ways can be used to provide the 692 initiator with this information, for example: 694 o Using off-band mechanisms, e.g., from the ISP's web page. 696 o Using DNS to look up a service name by appending it to the DNS 697 search path provided by DHCPv4 (e.g. 698 "tunnel-service.example.com"). 700 o Using a DHCP option. 702 o Using a pre-configured or pre-determined IPv4 anycast address. 704 o Using other, unspecified or proprietary methods such as TED (see 705 [I-D.fluhrer-ted]). 707 For the purpose of this document it is assumed that this address can 708 be obtained somehow. Once the address has been learned, it is 709 configured as the tunnel end-point for the configured IPv6-over-IPv4 710 tunnel. 712 10. Example 714 TBD: Full-fledged example 716 11. Security Considerations 718 When you run IPv6-in-IPv4 tunnels (unsecured) over the Internet, it 719 is possible to "inject" packets in the tunnel by spoofing the source 720 address (data plane security), or if the tunnel is signalled somehow 721 (e.g., some messages where you authenticate to the server, so that 722 you would get a static v6 prefix), someone might be able to spoof the 723 signalling (control plane security). 725 To add security to both, the protocol for tunnel setup and to the 726 data traffic, the IPsec framework plays an important role. 728 IKEv2 is a signaling protocol with optional Denial of Service 729 protection which authenticates both end points (with different 730 identifities) and establishes two types of security associations 731 (CHILD-SAs and IKE-SA). The authentication mechanisms are very 732 flexible due to the built-in support for symmetric and asymmetric 733 cryptography (or even a combination of both) and the Extensible 734 Authentication Protocol support (as desribed in Figure 12). The 735 IKE-SA is used to secure most of the IKEv2 message exchange. In 736 particular the CHILD-SA exchange, Informational exchanges (such as 737 the dead-peer detection mechanisms used for liveness checks) and the 738 exchange of configuration messages are secured. The CHILD-SA 739 exchange leads to the establishment of a IPsec tunnel and the 740 creation of SAD and SPD entries. 742 As a summary, IKEv2 provides a secure signaling protocol for 743 establishing, maintaining and deleting an IPsec tunnel. 745 IPsec, with the Encapsulating Security Payload (ESP), offers 746 integrity and data origin authentication, confidentiality, with 747 optional (at the discretion of the receiver) anti-replay features. 748 The usage of confidentity-only is discouraged. ESP furthermore 749 provides limited traffic flow confidentality. 751 IPsec provides access control mechanisms through the distribution of 752 keys and also through the usage of policies dictated by the Security 753 Policy Database (SPD). Furthermore, through the usage of EAP and the 754 backend AAA infrastructure it is possible to enforce additional 755 authorization mechanisms (at the user level) at entities other than 756 the tunnel end points. 758 The NAT traversal mechanism provided by IKEv2 introduces some 759 weaknesses into IKEv2 and IPsec. These issues are discussed in more 760 detail in [I-D.ietf-ipsec-ikev2]. 762 Please note that the usage of IPsec for the scenarios described in 763 Figure 3, Figure 2 and Figure 1 does not aim to protect the 764 end-to-end communication. It protects just the tunnel part. It is 765 still possible for an IPv6 endpoint that is not attached to the IPsec 766 tunnel to spoof packets. 768 12. Open Issues 770 This section lists some open issues that will be resolved in future 771 versions of this document. 773 o Some text on the usage of IKEv1 might be useful. 775 o Discussion of 'Use of IPsec Transport Mode for Dynamic Routing' 776 [I-D.touch-ipsec-vpn] would be appropriate. 778 o A more detailed description of the address configuration mechanism 779 would be helpful. The configuration example with CFG_REQUEST/ 780 CFG_REPLY payloads should contain IPv6 addresses. 782 o The full-fledged example of Section 10 is still missing. 784 o Some notes on the implications of mobility interworking are still 785 missing. 787 o Discuss the use of link-local etc. messages with Tunnel mode SAs 788 -- i.e., how many SAs will be needed (and how they are negotiated) 789 if link-local messages will be present as well? 791 o The "Site-to-Router" scenarios separation is a bit weak -- any 792 better ideas how to categorize these would be appreciated. 794 o Better discussion of when transport/tunnel mode SAs make sense and 795 would probably be useful. 797 13. Contributors 799 Please note that the authors are listed in alphabetical order. 801 Suresh Satapati also participated in the discussions. 803 14. Acknowledgments 805 The authors would like to thank Stephen Kent and Michael Richardson 806 for their comments. 808 We would like to thank Pasi Eronen for his text contributions. 810 15. References 812 15.1 Normative References 814 [I-D.ietf-eap-rfc2284bis] 815 Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H. 816 Levkowetz, "Extensible Authentication Protocol (EAP)", 817 draft-ietf-eap-rfc2284bis-07 (work in progress), December 818 2003. 820 [I-D.ietf-ipsec-esp-v3] 821 Kent, S., "IP Encapsulating Security Payload (ESP)", 822 draft-ietf-ipsec-esp-v3-08 (work in progress), March 2004, 823 . 825 [I-D.ietf-ipsec-ikev2] 826 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 827 draft-ietf-ipsec-ikev2-13 (work in progress), March 2004, 828 . 830 [I-D.ietf-ipsec-ikev2-algorithms] 831 Schiller, J., "Cryptographic Algorithms for use in the 832 Internet Key Exchange Version 2", 833 draft-ietf-ipsec-ikev2-algorithms-04 (work in progress), 834 September 2003, 835 . 837 [I-D.ietf-ipsec-rfc2401bis] 838 Kent, S. and K. Seo, "Security Architecture for the 839 Internet Protocol", draft-ietf-ipsec-rfc2401bis-01 (work 840 in progress), January 2004, 841 . 843 [I-D.ietf-ipsec-udp-encaps] 844 Huttunen, A., "UDP Encapsulation of IPsec Packets", 845 draft-ietf-ipsec-udp-encaps-08 (work in progress), 846 February 2004, . 848 [I-D.ietf-ipsec-ui-suites] 849 Hoffman, P., "Cryptographic Suites for IPsec", 850 draft-ietf-ipsec-ui-suites-04 (work in progress), August 851 2003, . 853 [I-D.ietf-v6ops-mech-v2] 854 Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 855 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 856 (work in progress), February 2004, 857 . 859 15.2 Informative References 861 [I-D.bellovin-useipsec] 862 Bellovin, S., "Guidelines for Mandating the Use of IPsec", 863 draft-bellovin-useipsec-03 (work in progress), March 2004, 864 . 866 [I-D.blanchet-v6ops-tunnelbroker-tsp] 867 Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup 868 Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-00 869 (work in progress), February 2004, 870 . 872 [I-D.dupont-ikev2-addrmgmt] 873 Dupont, F., "Address Management for IKE version 2", 874 draft-dupont-ikev2-addrmgmt-04 (work in progress), 875 February 2004, . 877 [I-D.eronen-ipsec-ikev2-eap-auth] 878 Eronen, P., "Extension for EAP Authentication in IKEv2", 879 draft-eronen-ipsec-ikev2-eap-auth-00 (work in progress), 880 February 2004, 881 . 883 [I-D.fluhrer-ted] 884 Fluhrer, S., "Tunnel Endpoint Discovery", 885 draft-fluhrer-ted-00 (work in progress), November 2001, 886 . 888 [I-D.ietf-aaa-eap] 889 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 890 Authentication Protocol (EAP) Application", 891 draft-ietf-aaa-eap-03 (work in progress), October 2003. 893 [I-D.ietf-eap-keying] 894 Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP Key 895 Management Framework", draft-ietf-eap-keying-01 (work in 896 progress), October 2003. 898 [I-D.ietf-ipsec-ikev2-iana] 899 Richardson, M., "Initial IANA registry contents", 900 draft-ietf-ipsec-ikev2-iana-01 (work in progress), January 901 2004, . 903 [I-D.ietf-ipsec-rfc2402bis] 904 Kent, S., "IP Authentication Header", 905 draft-ietf-ipsec-rfc2402bis-07 (work in progress), March 906 2004, . 908 [I-D.ietf-pana-ipsec] 909 Parthasarathy, M., "PANA enabling IPsec based Access 910 Control", draft-ietf-pana-ipsec-02 (work in progress), 911 February 2004, . 913 [I-D.kivinen-mobike-design] 914 Kivinen, T., "Design of the MOBIKE protocol", 915 draft-kivinen-mobike-design-00 (work in progress), March 916 2004, . 918 [I-D.touch-ipsec-vpn] 919 Touch, J., Eggert, L. and Y. Wang, "Use of IPsec Transport 920 Mode for Dynamic Routing", draft-touch-ipsec-vpn-07 (work 921 in progress), March 2004, 922 . 924 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 925 Internet Protocol", RFC 2401, November 1998, 926 . 928 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 929 Translator (NAT) Terminology and Considerations", RFC 930 2663, August 1999, . 932 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 933 "Remote Authentication Dial In User Service (RADIUS)", RFC 934 2865, June 2000. 936 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 937 Dial In User Service) Support For Extensible 938 Authentication Protocol (EAP)", RFC 3579, September 2003. 940 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 941 Networks", BCP 84, RFC 3704, March 2004, 942 . 944 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 945 (NAT) Compatibility Requirements", RFC 3715, March 2004, 946 . 948 Authors' Addresses 950 Richard Graveman 951 RFG Security, LLC 952 15 Park Avenue 953 Morristown, New Jersey 07960 954 USA 956 EMail: rfg@acm.org 958 Mohan Parthasarathy 959 Nokia 960 313 Fairchild Drive 961 Mountain View CA-94043 962 USA 964 EMail: mohanp@sbcglobal.net 966 Pekka Savola 967 CSC/FUNET 969 Espoo 970 Finnland 972 EMail: psavola@funet.fi 974 Hannes Tschofenig 975 Siemens 976 Otto-Hahn-Ring 6 977 Munich, Bayern 81739 978 Germany 980 EMail: Hannes.Tschofenig@siemens.com 982 Intellectual Property Statement 984 The IETF takes no position regarding the validity or scope of any 985 Intellectual Property Rights or other rights that might be claimed to 986 pertain to the implementation or use of the technology described in 987 this document or the extent to which any license under such rights 988 might or might not be available; nor does it represent that it has 989 made any independent effort to identify any such rights. Information 990 on the procedures with respect to rights in RFC documents can be 991 found in BCP 78 and BCP 79. 993 Copies of IPR disclosures made to the IETF Secretariat and any 994 assurances of licenses to be made available, or the result of an 995 attempt made to obtain a general license or permission for the use of 996 such proprietary rights by implementers or users of this 997 specification can be obtained from the IETF on-line IPR repository at 998 http://www.ietf.org/ipr. 1000 The IETF invites any interested party to bring to its attention any 1001 copyrights, patents or patent applications, or other proprietary 1002 rights that may cover technology that may be required to implement 1003 this standard. Please address the information to the IETF at 1004 ietf-ipr@ietf.org. 1006 Disclaimer of Validity 1008 This document and the information contained herein are provided on an 1009 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1010 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1011 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1012 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1013 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1014 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1016 Copyright Statement 1018 Copyright (C) The Internet Society (2004). This document is subject 1019 to the rights, licenses and restrictions contained in BCP 78, and 1020 except as set forth therein, the authors retain all their rights. 1022 Acknowledgment 1024 Funding for the RFC Editor function is currently provided by the 1025 Internet Society.