idnits 2.17.1 draft-tschofenig-v6ops-secure-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 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1024. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1008. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1014. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1030), 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 == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 9) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages 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.) ** 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 370: '...t implementation MUST NOT allow instan...' RFC 2119 keyword, line 613: '...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 (June 11, 2004) is 7260 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 627, but not defined == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'I-D.dupont-ikev2-addrmgmt' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pana-ipsec' is defined on line 918, but no explicit reference was found in the text == Unused Reference: 'I-D.kivinen-mobike-design' is defined on line 923, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 942, 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: 8 errors (**), 0 flaws (~~), 28 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: December 10, 2004 M. Parthasarathy 4 Nokia 5 P. Savola 6 CSC/FUNET 7 H. Tschofenig 8 Siemens 9 June 11, 2004 11 Using IPsec to Secure IPv6-over-IPv4 Tunnels 12 draft-tschofenig-v6ops-secure-tunnels-00.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 December 10, 2004. 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 . . . . . . . . . . . . . . . . . . . . 10 67 5.2.1 SPD for Host-to-Host Scenario . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 19 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 the 121 expected 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 to use 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 accompagning 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 XXX TBD: the issue may be revisited, and/or "legacy" considerations 348 added in an Appendix, etc. 350 In supporting IPv4/IPv6 transition the following functionality 351 described in section 5.1.2 of [I-D.ietf-ipsec-rfc2401bis] is 352 particularly useful: 354 " 355 o IPsec allows the IP version of the encapsulating header to be 356 different from that of the inner header. 357 " 359 The IPsec framework does not allow IKEv1/IKEv2 to be used to create 360 tunnels which do not experience cryptographic protection although 361 this functionality might be useful in some environments. IKEv2 would 362 then migrate into a secure signaling protocol for tunnel 363 establishment (without implementing data traffic protection) in a 364 fashion similar to the 'IPv6 Tunnel Broker with the Tunnel Setup 365 Protocol (TSP)' [I-D.blanchet-v6ops-tunnelbroker-tsp] protocol 366 proposal. Section 4.2 of [I-D.ietf-ipsec-rfc2401bis], however, 367 prohibits this functionality by stating: 369 " 370 A compliant implementation MUST NOT allow instantiation of an ESP SA 371 that employs both NULL encryption and no integrity algorithm. 372 " 374 Regarding the usage of the Explicit Congestion Notification (ECN), it 375 appears that the ECN bits in the IPv4 and IPv6 headers have exactly 376 the same semantics, so the bits just need to be copied from the outer 377 IPv4 header to the inner IPv6 header on tunnel exit. 379 5. IPsec Configuration Details 381 This section describes details about the IPsec tunnel establishment 382 for protection of IPv4/IPv6 data traffic. 384 5.1 IPsec Transport mode 386 This is typically used in Router-to-Router scenario. 388 The following SPD entries assume that there are two routers Router1 389 and Router2, whose tunnel endpoint's IPv4 address is denoted by 390 IPV4-TEP1 and IPV4-TEP2 respectively. 392 Router1's SPD OUT : 394 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 395 THEN USE ESP TRANSPORT MODE SA 397 Router1's SPD IN: 399 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 400 THEN USE ESP TRANSPORT MODE SA 402 Router2's SPD OUT: 404 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 405 THEN USE ESP TRANSPORT MODE SA 407 Router2's SPD IN: 409 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 410 THEN USE ESP TRANSPORT MODE SA 412 The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2 413 and protocol value 41 as phase 2 identities. With IKEv2, the traffic 414 selectors are used to carry the same information. 416 5.2 IPsec Tunnel mode 418 5.2.1 SPD for Host-to-Host Scenario 420 The following SPD entries assume that there are two hosts Host1 and 421 Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2 and 422 IPV4 addresses of the tunnel endpoints are denoted by IPV4-TEP1 and 423 IPV4-TEP2 respectively. 425 Host1's SPD OUT : 427 IF SRC = IPV6-EP1 && DST = IPV6-EP2 428 THEN USE ESP TUNNEL MODE SA: 429 outer source = IPv4-TEP1 430 outer dest = IPV4-TEP2 432 Host1's SPD IN: 434 IF SRC = IPV4-EP2 && DST = IPV6-EP1 435 THEN USE ESP TUNNEL MODE SA 436 outer source = IPV4-TEP2 437 outer dest = IPV4-TEP1 439 Host2's SPD OUT: 441 IF SRC = IPV4-EP2 && DST = IPV6-EP1 442 THEN USE ESP TUNNEL MODE SA 443 outer source = IPV4-TEP2 444 outer dest = IPV4-TEP1 446 Host2's SPD IN: 448 IF SRC = IPV6-EP1 && DST = IPV6-EP2 449 THEN USE ESP TUNNEL MODE SA: 450 outer source = IPv4-TEP1 451 outer dest = IPV4-TEP2 453 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 454 as phase 2 identities. With IKEv2, the traffic selectors are used to 455 carry the same information. 457 5.2.2 SPD for Host-to-Router scenario 459 The following SPD entries assume that the host has the IPv6 address 460 IPV6-EP1 and the tunnel end points of the host and router are 461 IPV4-TEP1 and IPV4-TEP2 respectively. If the tunnel is between a 462 router and a CPE device where the router has allocated a IPV6-PREF/48 463 to the CPE device, the corresponding SPD entries can be derived by 464 substituting IPV6-EP1 by IPV6-PREF/48. 466 Host's SPD OUT: 468 IF SRC = IPV6-EP1 && DST = any 469 THEN use ESP TUNNEL MODE SA 470 outer source = IPV4-TEP1 471 outer dest = IPV4-TEP2 473 Host's SPD IN: 475 IF SRC = any && DST = IPV6-EP1 476 THEN use ESP TUNNEL MODE SA 477 outer source = IPV4-TEP1 478 outer dest = IPV4-TEP2 480 Router's SPD OUT: 482 IF SRC = any && DST = IPV6-EP1 483 THEN use ESP TUNNEL MODE SA 484 outer source = IPV4-TEP1 485 outer dest = IPV4-TEP2 487 Router's SPD IN: 489 IF SRC = IPV6-EP1 && DST = any 490 THEN use ESP TUNNEL MODE SA 491 outer source = IPV4-TEP1 492 outer dest = IPV4-TEP2 494 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and 495 ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity. 496 The starting address is zero IP address and the end address is all 497 ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address 498 and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With 499 IKEv2, the traffic selectors are used to carry the same information. 501 To describe the packet format the following acronyms are used 502 throughout this document: 504 o IPV4-TEP1 and IPV4-TEP2 denote the IPv4 address of the tunnel 505 endpoints. 507 o IPV6-EP1 and IPV6-EP2 denote the IPv6 address of the two IPv6 508 endpoints of the communication. 510 The packet format is the same for both transport mode and tunnel mode 511 as shown in Figure 10. 513 IPv4 header (source = IPV4-TEP1, 514 destination = IPV4-TEP2) 515 ESP header 516 IPv6 header (source = IPV6-EP1, 517 destination = IPV6-EP2) 519 Figure 10: Packet Format for transport and tunnel mode 521 This type of layering may not be valid with [RFC2401] since, with a 522 strict definition, IP does not meet the definition of a "higher layer 523 protocol" being the next protocol after an IP header. 525 With [I-D.ietf-ipsec-rfc2401bis] the definition about the "next layer 526 protocol" was explicitly expanded and hence this type of layering is 527 valid. 529 6. Dynamic Address Configuration 531 With the exchange of protected configuration payloads, IKEv2 is able 532 to provide the IKEv2 peer with DHCP-like information payloads. These 533 configuration payloads are exchanged between the IKEv2 initiator and 534 the responder with the help of the CFG_REQUEST/CFG_REPLY and CFG_SET/ 535 CFG_ACK payloads. The former is used to request information and the 536 latter allows to push configuration data. Configuration information 537 (e.g., a temporary address) can be carried in any request to create a 538 CHILD_SA by including a CP payload. 540 These configuration payloads are primiarly used for bootstrapping the 541 IKEv2 peer. Although these payloads are extensible they are not used 542 as a generic purpose management. 544 The following example exchange illustrates the usage of configuration 545 payloads: 547 Initiator Responder 548 ------------- -------------- 549 HDR, SAi1, KEi, Ni --> 551 <-- HDR(A,0), N(COOKIE) 553 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 555 <-- HDR, SAr1, KEr, Nr,[CERTREQ] 557 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 558 AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> 560 <-- HDR, SK {IDr, [CERT,] AUTH, 561 CP(CFG_REPLY), SAr2, TSi, TSr} 563 Figure 11: IKEv2 Configuration payload payload exchange 565 The example message exchange shown in Figure 11 shows IKEv2 with a 566 denial of service protection enabled exchange and a CFG_REQUEST in 567 message 5 and the corresponding response in message 6. The content 568 of these payloads, for example, contains (as given in Section 2.19 of 569 [I-D.ietf-ipsec-ikev2]): 571 CP(CFG_REQUEST)= 572 INTERNAL_ADDRESS(0.0.0.0) 573 INTERNAL_NETMASK(0.0.0.0) 574 INTERNAL_DNS(0.0.0.0) 575 TSi = (0, 0-65536,0.0.0.0-255.255.255.255) 576 TSr = (0, 0-65536,0.0.0.0-255.255.255.255) 578 CP(CFG_REPLY)= 579 INTERNAL_ADDRESS(10.168.219.202) 580 INTERNAL_NETMASK(255.255.255.0) 581 INTERNAL_SUBNET(10.168.219.0/255.255.255.0) 582 TSi = (0, 0-65536,10.168.219.202-10.168.219.202) 583 TSr = (0, 0-65536,10.168.219.0-10.168.219.255) 585 7. Extensible Authentication Support 587 In addition to the authentication mechanisms provided in IKEv2 the 588 Extensible Authentication Protocol (EAP) [I-D.ietf-eap-rfc2284bis] is 589 included which provides some flexibility for authentication 590 mechanisms. Figure 13 shows an example IKEv2 exchange with EAP 591 support. The usage of EAP offers two interesting features: 593 o User authentication is terminated at a different entity other than 594 the IKEv2 responder. This allows users' security credentials to 595 be kept in a central place (e.g., AAA server) and to terminate the 596 EAP method at this entity instead at the IKEv2 responder. 597 Authorization can also be executed at the same entity. 599 o A number of authentication and key exchange protocols are 600 supported via EAP method (such as EAP-AKA, EAP-SIM, SRP, etc.). 601 Each EAP methods provides its own properties and usage 602 environment. This provides a certain degree of flexibility. 604 Note that IKEv2 with EAP authentication still requires public key 605 based authentication of the IKEv2 responder outside the EAP 606 authentication. In most deployments this requires a server-side 607 public-key based authentication to protect the EAP exchange with a 608 uni-lateral authenticated tunnel. With the extensions proposed in 609 [I-D.eronen-ipsec-ikev2-eap-auth] only EAP authentication is used by 610 omitting the IKEv2 responder authentication. 612 Please note that Section 3.16 of [I-D.ietf-ipsec-ikev2] indicates 613 that the EAP Identity-Request/Identity-Response payload SHOULD NOT be 614 used. The IDr payload (message 3 in Figure 13) carries this identity 615 instead. As a consequence active user identity confidentiality for 616 the IKEv2 initiator is not provided. Special purpose EAP methods 617 must be used instead if this features is desired. 619 Figure 13 shows an example IKEv2 message exchange with EAP-AKA as an 620 EAP method. Note that the interaction between the IKEv2 responder 621 and the AAA infrastructure is not shown. 623 Initiator Responder 624 ------------- -------------- 625 HDR, SAi1, KEi, Ni --> 627 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 629 HDR, SK {IDi, [CERTREQ,] [IDr,] 630 SAi2, TSi, TSr} --> 632 <-- HDR, SK {IDr, [CERT,] AUTH, 633 EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) } 635 HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)} --> 637 <-- HDR, SK {EAP-Success, AUTH} 639 HDR, SK { AUTH } --> 641 <-- HDR, SK { SAr2, TSi, TSr } 643 Figure 13: EAP usage in IKEv2 with EAP-AKA 645 EAP will typically be used with a backend AAA server which raises 646 some security concerns. See [I-D.ietf-eap-keying] for a more 647 complete discussion of these security issues. 649 When a backend server is used, there are actually two authentication 650 exchanges: the EAP method between the client and the AAA server, and 651 another authentication between the AAA server and IKEv2 gateway. The 652 AAA server authenticates the client using the selected EAP method, 653 and they establish a session key. The AAA server then sends this key 654 to the IKEv2 gateway over a connection authenticated using e.g. 655 IPsec or TLS. The protocol used between the IKEv2 responder and the 656 AAA server could be, for instance, Diameter or RADIUS [RFC3579]. 657 RADIUS and Diameter are able to carry EAP payloads as described in 658 [RFC3579] and in [I-D.ietf-aaa-eap], respectively. 660 8. NAT Traversal 662 Network address (and port) translation devices are commonly found in 663 today's networks. A detailed description of the problem of IPsec 664 protected data traffic traversing a NAT including requirements are 665 discussed in [RFC3715]. 667 IKEv2 can detect the presence of a NAT automatically by sending an 668 Informational exchange with NAT_DETECTION_SOURCE_IP and 669 NAT_DETECTION_DESTINATION_IP payloads before establishing an IPsec 670 SA. These payloads are processed the same way as in the initial 671 IKE_SA_INIT exchange. Once a NAT is detected and both end points 672 support IPsec NAT traversal extensions UDP encapsulation can be 673 enabled. 675 More details about UDP encapsulation of IPsec protected IP packets 676 can be found in [I-D.ietf-ipsec-udp-encaps]. 678 For IPv6-over-IPv4 tunneling, NAT traversal is interesting for two 679 reasons: 681 1. One of the tunnel endpoints is often behind a NAT, and configured 682 tunneling, using protocol 41, is not guaranteed to traverse the 683 NAT. Hence, using IPsec tunnels would enable one to both set-up 684 a secure tunnel, and set-up a tunnel where it might not always be 685 possible without other tunneling mechanisms. 687 2. Using NAT traversal allows the outer address to change without 688 having to renegotiate the SAs. This could be very beneficial for 689 a crude form of mobility, and in scenarios the NAT changes the IP 690 addresses frequently. However, as the outer address may change, 691 this might introduce new security issues, and using tunnel mode 692 would be most appropriate. 694 XXX: can you force the use of NAT traversal so that you don't need to 695 renegotiate SAs even if you aren't behind a NAT -- could be useful 696 for MOBIKE applications. 698 9. Tunnel Endpoint Discovery 700 The IKEv2 initiator needs to know the address of the IKEv2 responder 701 for IKEv2 signaling. A number of ways can be used to provide the 702 initiator with this information, for example: 704 o Using off-band mechanisms, e.g., from the ISP's web page. 706 o Using DNS to look up a service name by appending it to the DNS 707 search path provided by DHCPv4 (e.g. 708 "tunnel-service.example.com"). 710 o Using a DHCP option. 712 o Using a pre-configured or pre-determined IPv4 anycast address. 714 o Using other, unspecified or proprietary methods such as TED (see 715 [I-D.fluhrer-ted]). 717 For the purpose of this document it is assumed that this address can 718 be obtained somehow. Once the address has been learned, it is 719 configured as the tunnel end-point for the configured IPv6-over-IPv4 720 tunnel. 722 10. Example 724 TBD: Full-fledged example 726 11. Security Considerations 728 When you run IPv6-in-IPv4 tunnels (unsecured) over the Internet, it 729 is possible to "inject" packets in the tunnel by spoofing the source 730 address (data plane security), or if the tunnel is signalled somehow 731 (e.g., some messages where you authenticate to the server, so that 732 you would get a static v6 prefix), someone might be able to spoof the 733 signalling (control plane security). 735 To add security to both, the protocol for tunnel setup and to the 736 data traffic, the IPsec framework plays an important role. 738 IKEv2 is a signaling protocol with optional Denial of Service 739 protection which authenticates both end points (with different 740 identifities) and establishes two types of security associations 741 (CHILD-SAs and IKE-SA). The authentication mechanisms are very 742 flexible due to the built-in support for symmetric and asymmetric 743 cryptography (or even a combination of both) and the Extensible 744 Authentication Protocol support (as desribed in Figure 13). The 745 IKE-SA is used to secure most of the IKEv2 message exchange. In 746 particular the CHILD-SA exchange, Informational exchanges (such as 747 the dead-peer detection mechanisms used for liveness checks) and the 748 exchange of configuration messages are secured. The CHILD-SA 749 exchange leads to the establishment of a IPsec tunnel and the 750 creation of SAD and SPD entries. 752 As a summary, IKEv2 provides a secure signaling protocol for 753 establishing, maintaining and deleting an IPsec tunnel. 755 IPsec, with the Encapsulating Security Payload (ESP), offers 756 integrity and data origin authentication, confidentiality, with 757 optional (at the discretion of the receiver) anti-replay features. 758 The usage of confidentity-only is discouraged. ESP furthermore 759 provides limited traffic flow confidentality. 761 IPsec provides access control mechanisms through the distribution of 762 keys and also through the usage of policies dictated by the Security 763 Policy Database (SPD). Furthermore, through the usage of EAP and the 764 backend AAA infrastructure it is possible to enforce additional 765 authorization mechanisms (at the user level) at entities other than 766 the tunnel end points. 768 The NAT traversal mechanism provided by IKEv2 introduces some 769 weaknesses into IKEv2 and IPsec. These issues are discussed in more 770 detail in [I-D.ietf-ipsec-ikev2]. 772 Please note that the usage of IPsec for the scenarios described in 773 Figure 3, Figure 2 and Figure 1 does not aim to protect the 774 end-to-end communication. It protects just the tunnel part. It is 775 still possible for an IPv6 endpoint that is not attached to the IPsec 776 tunnel to spoof packets. 778 12. Open Issues 780 This section lists some open issues that will be resolved in future 781 versions of this document. 783 o More considerations of IKEv1 might be useful. 785 o Discussion of 'Use of IPsec Transport Mode for Dynamic Routing' 786 [I-D.touch-ipsec-vpn] would be appropriate. 788 o A more detailed description of the address configuration mechanism 789 would be helpful. The configuration example with CFG_REQUEST/ 790 CFG_REPLY payloads should contain IPv6 addresses. 792 o The full-fledged example of Section 10 is still missing. 794 o Some notes on the implications of mobility interworking are still 795 missing. 797 o Discuss the use of link-local etc. messages with Tunnel mode SAs 798 -- i.e., how many SAs will be needed (and how they are negotiated) 799 if link-local messages will be present as well? 801 o The "Site-to-Router" scenarios separation is a bit weak -- any 802 better ideas how to categorize these would be appreciated. 804 o Better discussion of when transport/tunnel mode SAs make more 805 sense would probably be useful. 807 13. Contributors 809 Please note that the authors are listed in alphabetical order. 811 Suresh Satapati also participated in the discussions. 813 14. Acknowledgments 815 The authors would like to thank Stephen Kent and Michael Richardson 816 for their comments. 818 We would like to thank Pasi Eronen for his text contributions. 820 15. References 822 15.1 Normative References 824 [I-D.ietf-eap-rfc2284bis] 825 Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H. 826 Levkowetz, "Extensible Authentication Protocol (EAP)", 827 draft-ietf-eap-rfc2284bis-07 (work in progress), December 828 2003. 830 [I-D.ietf-ipsec-esp-v3] 831 Kent, S., "IP Encapsulating Security Payload (ESP)", 832 draft-ietf-ipsec-esp-v3-08 (work in progress), March 2004, 833 . 835 [I-D.ietf-ipsec-ikev2] 836 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 837 draft-ietf-ipsec-ikev2-13 (work in progress), March 2004, 838 . 840 [I-D.ietf-ipsec-ikev2-algorithms] 841 Schiller, J., "Cryptographic Algorithms for use in the 842 Internet Key Exchange Version 2", 843 draft-ietf-ipsec-ikev2-algorithms-04 (work in progress), 844 September 2003, 845 . 847 [I-D.ietf-ipsec-rfc2401bis] 848 Kent, S. and K. Seo, "Security Architecture for the 849 Internet Protocol", draft-ietf-ipsec-rfc2401bis-01 (work 850 in progress), January 2004, 851 . 853 [I-D.ietf-ipsec-udp-encaps] 854 Huttunen, A., "UDP Encapsulation of IPsec Packets", 855 draft-ietf-ipsec-udp-encaps-08 (work in progress), 856 February 2004, . 858 [I-D.ietf-ipsec-ui-suites] 859 Hoffman, P., "Cryptographic Suites for IPsec", 860 draft-ietf-ipsec-ui-suites-04 (work in progress), August 861 2003, . 863 [I-D.ietf-v6ops-mech-v2] 864 Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 865 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 866 (work in progress), February 2004, 867 . 869 15.2 Informative References 871 [I-D.bellovin-useipsec] 872 Bellovin, S., "Guidelines for Mandating the Use of IPsec", 873 draft-bellovin-useipsec-03 (work in progress), March 2004, 874 . 876 [I-D.blanchet-v6ops-tunnelbroker-tsp] 877 Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup 878 Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-00 879 (work in progress), February 2004, 880 . 882 [I-D.dupont-ikev2-addrmgmt] 883 Dupont, F., "Address Management for IKE version 2", 884 draft-dupont-ikev2-addrmgmt-04 (work in progress), 885 February 2004, . 887 [I-D.eronen-ipsec-ikev2-eap-auth] 888 Eronen, P., "Extension for EAP Authentication in IKEv2", 889 draft-eronen-ipsec-ikev2-eap-auth-00 (work in progress), 890 February 2004, 891 . 893 [I-D.fluhrer-ted] 894 Fluhrer, S., "Tunnel Endpoint Discovery", 895 draft-fluhrer-ted-00 (work in progress), November 2001, 896 . 898 [I-D.ietf-aaa-eap] 899 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 900 Authentication Protocol (EAP) Application", 901 draft-ietf-aaa-eap-03 (work in progress), October 2003. 903 [I-D.ietf-eap-keying] 904 Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP Key 905 Management Framework", draft-ietf-eap-keying-01 (work in 906 progress), October 2003. 908 [I-D.ietf-ipsec-ikev2-iana] 909 Richardson, M., "Initial IANA registry contents", 910 draft-ietf-ipsec-ikev2-iana-01 (work in progress), January 911 2004, . 913 [I-D.ietf-ipsec-rfc2402bis] 914 Kent, S., "IP Authentication Header", 915 draft-ietf-ipsec-rfc2402bis-07 (work in progress), March 916 2004, . 918 [I-D.ietf-pana-ipsec] 919 Parthasarathy, M., "PANA enabling IPsec based Access 920 Control", draft-ietf-pana-ipsec-02 (work in progress), 921 February 2004, . 923 [I-D.kivinen-mobike-design] 924 Kivinen, T., "Design of the MOBIKE protocol", 925 draft-kivinen-mobike-design-00 (work in progress), March 926 2004, . 928 [I-D.touch-ipsec-vpn] 929 Touch, J., Eggert, L. and Y. Wang, "Use of IPsec Transport 930 Mode for Dynamic Routing", draft-touch-ipsec-vpn-07 (work 931 in progress), March 2004, 932 . 934 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 935 Internet Protocol", RFC 2401, November 1998, 936 . 938 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 939 Translator (NAT) Terminology and Considerations", RFC 940 2663, August 1999, . 942 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 943 "Remote Authentication Dial In User Service (RADIUS)", RFC 944 2865, June 2000. 946 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 947 Dial In User Service) Support For Extensible 948 Authentication Protocol (EAP)", RFC 3579, September 2003. 950 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 951 Networks", BCP 84, RFC 3704, March 2004, 952 . 954 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 955 (NAT) Compatibility Requirements", RFC 3715, March 2004, 956 . 958 Authors' Addresses 960 Richard Graveman 961 RFG Security, LLC 962 15 Park Avenue 963 Morristown, New Jersey 07960 964 USA 966 EMail: rfg@acm.org 968 Mohan Parthasarathy 969 Nokia 970 313 Fairchild Drive 971 Mountain View CA-94043 972 USA 974 EMail: mohanp@sbcglobal.net 976 Pekka Savola 977 CSC/FUNET 979 Espoo 980 Finnland 982 EMail: psavola@funet.fi 984 Hannes Tschofenig 985 Siemens 986 Otto-Hahn-Ring 6 987 Munich, Bayern 81739 988 Germany 990 EMail: Hannes.Tschofenig@siemens.com 992 Intellectual Property Statement 994 The IETF takes no position regarding the validity or scope of any 995 Intellectual Property Rights or other rights that might be claimed to 996 pertain to the implementation or use of the technology described in 997 this document or the extent to which any license under such rights 998 might or might not be available; nor does it represent that it has 999 made any independent effort to identify any such rights. Information 1000 on the procedures with respect to rights in RFC documents can be 1001 found in BCP 78 and BCP 79. 1003 Copies of IPR disclosures made to the IETF Secretariat and any 1004 assurances of licenses to be made available, or the result of an 1005 attempt made to obtain a general license or permission for the use of 1006 such proprietary rights by implementers or users of this 1007 specification can be obtained from the IETF on-line IPR repository at 1008 http://www.ietf.org/ipr. 1010 The IETF invites any interested party to bring to its attention any 1011 copyrights, patents or patent applications, or other proprietary 1012 rights that may cover technology that may be required to implement 1013 this standard. Please address the information to the IETF at 1014 ietf-ipr@ietf.org. 1016 Disclaimer of Validity 1018 This document and the information contained herein are provided on an 1019 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1020 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1021 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1022 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1023 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1024 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1026 Copyright Statement 1028 Copyright (C) The Internet Society (2004). This document is subject 1029 to the rights, licenses and restrictions contained in BCP 78, and 1030 except as set forth therein, the authors retain all their rights. 1032 Acknowledgment 1034 Funding for the RFC Editor function is currently provided by the 1035 Internet Society.