idnits 2.17.1 draft-tschofenig-v6ops-secure-tunnels-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1041. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1047. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 335: '... implementations MUST implement ESP an...' RFC 2119 keyword, line 367: '...t implementation MUST NOT allow instan...' RFC 2119 keyword, line 610: '...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 (October 24, 2004) is 7124 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 624, but not defined == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pana-ipsec' is defined on line 956, but no explicit reference was found in the text == Unused Reference: 'I-D.kivinen-mobike-design' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 978, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-09 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-03 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-06 == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-03 == Outdated reference: A later version (-04) exists of draft-blanchet-v6ops-tunnelbroker-tsp-01 == Outdated reference: A later version (-07) exists of draft-eronen-ipsec-ikev2-eap-auth-02 == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-09 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-03 == Outdated reference: A later version (-11) exists of draft-ietf-ipsec-rfc2402bis-08 == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-04 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 8 errors (**), 0 flaws (~~), 18 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations WG R. Graveman 3 Internet-Draft RFG Security, LLC 4 Expires: April 24, 2005 M. Parthasarathy 5 Nokia 6 P. Savola 7 CSC/FUNET 8 H. Tschofenig 9 Siemens 10 October 24, 2004 12 Using IPsec to Secure IPv6-over-IPv4 Tunnels 13 draft-tschofenig-v6ops-secure-tunnels-02.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 24, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). 46 Abstract 48 This document gives guidance on securing IPv6-in-IPv4 tunnels using 49 IPsec. No additional protocol extensions are described beyond those 50 available with the revised IPsec framework. IKEv2 is extensively 51 used as an authentication and key exchange protocol to cover address 52 configuration procedures, and the usage of the Extensible 53 Authentication Procotol and NAT traversal capabilities is also 54 described. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3 60 2.1 IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4 61 2.2 IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 4 62 3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5 63 3.1 Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 5 64 3.2 Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 5 65 3.3 Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 7 66 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 9 68 5.1 IPsec Transport mode . . . . . . . . . . . . . . . . . . . 9 69 5.2 IPsec Tunnel mode . . . . . . . . . . . . . . . . . . . . 9 70 5.2.1 SPD for Host-to-Host Scenario . . . . . . . . . . . . 9 71 5.2.2 SPD for Host-to-Router scenario . . . . . . . . . . . 10 72 6. Dynamic Address Configuration . . . . . . . . . . . . . . . . 12 73 7. Extensible Authentication Support . . . . . . . . . . . . . . 13 74 8. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . . . 16 76 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 11. Security Considerations . . . . . . . . . . . . . . . . . . 17 78 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 18 79 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 80 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 81 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 15.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 83 15.2 Informative References . . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 85 Intellectual Property and Copyright Statements . . . . . . . . 24 87 1. Introduction 89 The IPv6 operations (v6ops) working group has selected IPv6-in-IPv4 90 tunneling [I-D.ietf-v6ops-mech-v2] as one of the IPv6 transition 91 mechanisms for IPv6 deployment. A number of threats have been 92 identified with possible solutions to mitigate them 93 [I-D.ietf-v6ops-mech-v2]. One of the solutions is the use of IPsec 94 protected tunnels, but there is little detail on how IPsec would 95 actually be used in an interoperable manner. This memo describes the 96 use of IPsec in detail. 98 First this document analyses the threats that can be addressed by 99 IPsec. Next, this document discusses some of the assumptions made by 100 this document for successful IPsec SA establishment. Then, it gives 101 the details of IKE/IPsec exchange with packet formats and SPD 102 entries. Finally, it discusses the usage of IPsec NAT-traversal 103 mechanism that can be used with configured tunnels in some scenarios. 105 2. Threats and the Use of IPsec 107 Following threats have been identified in [I-D.ietf-v6ops-mech-v2]: 109 1. IPv4 address of the encapsulating ("outer") packet can be 110 spoofed. 112 2. IPv6 address of the encapsualted ("inner") packet can be spoofed. 114 The reason for threat (1) is due to the lack of widespread deployment 115 of IPv4 ingress filtering in the network. The reason for threat (2) 116 is that the IPv6 packet is encapsulated in IPv4 and hence escapes 117 IPv6 ingress filtering. [I-D.ietf-v6ops-mech-v2] specifies following 118 strict address checks as mitigating measures. 120 To mitigate threat (1), the decapsulator verifies that the IPv4 121 source address of the packet is the same as the address of the 122 configured tunnel endpoint. The decapsulator may also implement IPv4 123 ingress filtering, i.e., checks whether the packet is received on a 124 legitimate interface. 126 To mitigate threat (2), the decapsulator verifies whether the inner 127 IPv6 address is a valid IPv6 address and also applies IPv6 ingress 128 filtering before accepting the IPv6 packet. 130 This memo proposes using IPsec for providing stronger security in 131 preventing these threats. IPsec can be used in two ways, in 132 transport and tunnel mode. 134 2.1 IPsec in Transport Mode 136 In transport mode, the IPsec security association (SA) is established 137 to protect the traffic defined by (IPv4-source, IPv4-dest, protocol = 138 41). On receiving such an IPsec packet, the receiver first applies 139 the IPsec transform (ESP) and then matches the packet against the 140 inbound selectors associated with the SA to verify that the packet is 141 appropriate for the SA via which it was received. The successful 142 verification implies that the packet came from the right IPv4 143 endpoint as the SA is bound to the IPv4 source address. 145 This prevents threat (1) but not the threat (2). IPsec in transport 146 mode does not verify the contents of the payload itself where the 147 IPv6 addresses are carried, that is, two nodes that are using IPsec 148 transport mode to secure the tunnel can spoof the inner payload. The 149 packet will be decapsulated successfully and accepted. 151 The shortcoming can be mitigated by IPv6 ingress filtering i.e., 152 check that the packet is arriving from the interface in the direction 153 of the route towards the tunnel end-point, similar to a Strict 154 Reverse Path Forwarding (RPF) check [RFC3704]. 156 For performing ingress filtering, it is assumed that the tunnel is 157 modelled as an interface and the traffic of the tunnel is protected 158 using IPsec transport mode SA. 160 2.2 IPsec in Tunnel Mode 162 In tunnel mode, the IPsec SA is established to protect the traffic 163 defined by (IPv6-source, IPv6-destination). On receiving such an 164 IPsec packet, the receiver first applies the IPsec transform (ESP) 165 and then matches the packet against the inbound selectors associated 166 with the SA to verify that the packet is appropriate for the SA via 167 which it was received. The successful verification implies that the 168 packet came from the right IPv6 endpoint as the SA is bound to the 169 IPv6 source address. 171 The IPv4 addresses may be spoofed and IPsec cannot detect it in this 172 mode, that is, two nodes that are using IPsec tunnel mode to secure 173 the tunnel with a common tunnel endpoint can spoof each other's IPv4 174 address. But, the packet will not be accepted by IPsec as the IPv6 175 address bound to the SA will not match the address in the spoofed 176 packet. Thus, the outer address spoofing is irrelevant as long as 177 the inner IPv6 packet can be verified to come from the right IPv6 178 endpoint. 180 It may not be possible to always verify the IPv6 address -- for 181 example with link-local addresses. The additional issues with 182 address verification are discussed in each of the scenarios section 183 appropriately. 185 3. Scenarios and Overview 187 There are roughly three kinds of scenarios: (generic) 188 router-to-router tunnels, site-to-router/router-to-site tunnels (a 189 generalization of host-to-router/router-to-host scenarios, 190 respectively), and host-to-host tunnels. 192 3.1 Router-to-Router Tunnels 194 IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of 195 IPv4 routing topology by encapsulating them within IPv4 packets. 196 Tunneling can be used in a variety of ways. 198 .--------. _----_ .--------. 199 |v6-in-v4| _( IPv4 )_ |v6-in-v4| 200 | Router | <======( Internet )=====> | Router | 201 | A | (_ _) | B | 202 '--------' '----' '--------' 203 ^ IPsec tunnel between ^ 204 | Router A and Router B | 205 V V 206 .--------. .-------. 207 | End | | End | 208 | Host | | Host | 209 '--------' '--------' 211 Figure 1: Router-to-Router Scenario 213 IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel 214 IPv6 packets between themselves. In this case, the tunnel spans one 215 segment of the end-to-end path that the IPv6 packet takes. 217 The source and destination addresses of the IPv6 packets traversing 218 the tunnel could come from a wide range of IPv6 prefixes. It is not 219 scalable to establish IPsec tunnel mode SAs for all such packets. 220 Hence, IPsec transport mode SA is recommended for this scenario. 221 IPv6 ingress filtering should be performed to mitigate the IPv6 222 address spoofing threat. 224 A specific case of router-to-router tunnels, when one router resides 225 at an end site, is described in the next section. 227 3.2 Site-to-Router/Router-to-Site Tunnels 229 This is a generalization of site-to-router and router-to-site 230 tunneling, because the issues when connecting a whole site (using a 231 router), and connecting a single host are roughly equal. 233 _----_ .---------. IPsec _----_ IPsec .-------. 234 _( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 | 235 ( Internet )<--->| Router |<=======( Internet )=======>| Site B | 236 (_ _) | A | (_ _) '--------' 237 '----' '---------' '----' 238 ^ 239 | 240 V 241 .--------. 242 | Native | 243 | IPv6 | 244 | node | 245 '--------' 247 Figure 2: Router-to-Site Scenario 249 IPv6/IPv4 routers can tunnel IPv6 packets to their final destination 250 IPv6/IPv4 host. This tunnel spans only the last segment of the 251 end-to-end path. 253 This is the same as the Site-to-Router case. 255 +---------------------+ 256 | IPv6 Network | 257 | | 258 .--------. _----_ | .--------. | 259 | V6/V4 | _( IPv4 )_ | |v6-in-v4| | 260 | Site B |<====( Internet )==========>| Router | | 261 '--------' (_ _) | | A | | 262 '----' | '--------' | 263 IPsec tunnel between | ^ | 264 V6 Site and Router A | | | 265 | V | 266 | .-------. | 267 | | V6 | | 268 | | Host | | 269 | '--------' | 270 +---------------------+ 272 Figure 3: Site-to-Router Scenario 274 IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 275 router that is reachable via an IPv4 infrastructure. This type of 276 tunnel spans the first segment of the packet's end-to-end path. 278 In this case, the host(s) originate the packet with source address 279 coming from a well known prefix whereas the destination address could 280 be any node on the internet. In this case, the IPsec tunnel mode SA 281 can be bound to the prefix that was allocated to the router at Site B 282 and router A can verify that the source address of the packet matches 283 the prefix. Site B will not be able to do a similar verification for 284 the packets it receives. This may be quite reasonable for most of 285 the deployment cases, for example, the ISP allocating a /48 to a 286 customer. The CPE (where the tunnel is terminated) "trusts" (in a 287 weak sense) the ISP's router and the ISP's router can verify that the 288 Site B is the only one that can originate packets within the /48. 289 IPsec tunnel mode SA is recommended for this case, though similar 290 amount of protection can be obtained with transport mode SA with 291 strict ingress filtering as well. 293 3.3 Host-to-Host Tunnels 295 .--------. _----_ .--------. 296 | V6/V4 | _( IPv4 )_ | V6/V4 | 297 | Host | <======( Internet )=====> | Host | 298 | A | (_ _) | B | 299 '--------' '----' '--------' 300 IPsec tunnel between 301 Host A and Host B 303 Figure 4: Host-to-Host Scenario 305 IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can 306 tunnel IPv6 packets between themselves. In this case, the tunnel 307 spans the entire end-to-end path that the packet takes. 309 In this case, the source and the destination IPv6 address are known a 310 priori. A tunnel mode SA can be bound to the specific address. The 311 address verification prevents IPv6 address spoofing completely. 313 4. Assumptions 315 Throughout this document we make a few assumptions which are briefly 316 listed here. The following documents are used as a basis: 318 o Revised 'Security Architecture for the Internet Protocol' as 319 described in [I-D.ietf-ipsec-rfc2401bis]. 321 o IKEv2 as described in [I-D.ietf-ipsec-ikev2] and the accompanying 322 documents for cipher suites and cryptgraphic algorithms (see 323 [I-D.ietf-ipsec-ikev2-algorithms], [I-D.ietf-ipsec-ikev2-iana] and 324 [I-D.ietf-ipsec-ui-suites]). 326 o 'IP Encapsulating Security Payload (ESP)' as described in 327 [I-D.ietf-ipsec-esp-v3] 329 o 'UDP Encapsulation of IPsec Packets' as described in 330 [I-D.ietf-ipsec-udp-encaps] for the purpose of NAT traversal. 332 Please note that we do not consider the usage of the IP 333 Authentication Header (AH) [I-D.ietf-ipsec-rfc2402bis] since Section 334 3.2 of [I-D.ietf-ipsec-rfc2401bis] specifies that IPsec 335 implementations MUST implement ESP and MAY implement AH with the 336 reasoning that ESP provides security services (such as integrity 337 protection without confidentiality protection using 'NULL' 338 encryption) which are comparable with AH. 340 Furthermore, we focus on IKEv2 since [I-D.ietf-ipsec-rfc2401bis] 341 assumes use of IKEv2 as a key and security association management 342 system and not IKEv1 with its extensions. 344 The decision to focus on IKEv2 and newer IPsec documents is based on 345 the premise that doing so allows using "mixed-mode" transforms as 346 described below. This is useful for Transport mode SAs. Some 347 implementations might, however, support these SAs already, at least 348 using manual configuration. 350 The support of IPv4/IPv6 transition capabilities with IPsec is 351 possible with [RFC2401] and with [I-D.ietf-ipsec-rfc2401bis] (see 352 Section 5.1.2 of [I-D.ietf-ipsec-rfc2401bis]). IPsec allows the IP 353 version of the encapsulating header to be different from that of the 354 inner header. 356 The IPsec framework does not allow IKEv1/IKEv2 to be used to create 357 tunnels which do not experience cryptographic protection although 358 this functionality might be useful in some environments. IKEv2 would 359 then migrate into a secure signaling protocol for tunnel 360 establishment (without implementing data traffic protection) in a 361 fashion similar to the 'IPv6 Tunnel Broker with the Tunnel Setup 362 Protocol (TSP)' [I-D.blanchet-v6ops-tunnelbroker-tsp] protocol 363 proposal. Section 4.2 of [I-D.ietf-ipsec-rfc2401bis], however, 364 prohibits this functionality by stating: 366 " 367 A compliant implementation MUST NOT allow instantiation of an ESP SA 368 that employs both NULL encryption and no integrity algorithm. 369 " 371 Regarding the usage of the Explicit Congestion Notification (ECN), it 372 appears that the ECN bits in the IPv4 and IPv6 headers have exactly 373 the same semantics, so the bits just need to be copied from the outer 374 IPv4 header to the inner IPv6 header on tunnel exit. 376 5. IPsec Configuration Details 378 This section describes details about the IPsec tunnel establishment 379 for protection of IPv4/IPv6 data traffic. 381 5.1 IPsec Transport mode 383 This is typically used in Router-to-Router scenario. 385 The following SPD entries assume that there are two routers Router1 386 and Router2, whose tunnel endpoint's IPv4 address is denoted by 387 IPV4-TEP1 and IPV4-TEP2 respectively. 389 Router1's SPD OUT : 391 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 392 THEN USE ESP TRANSPORT MODE SA 394 Router1's SPD IN: 396 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 397 THEN USE ESP TRANSPORT MODE SA 399 Router2's SPD OUT: 401 IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 402 THEN USE ESP TRANSPORT MODE SA 404 Router2's SPD IN: 406 IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 407 THEN USE ESP TRANSPORT MODE SA 409 The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2 410 and protocol value 41 as phase 2 identities. With IKEv2, the traffic 411 selectors are used to carry the same information. 413 5.2 IPsec Tunnel mode 415 5.2.1 SPD for Host-to-Host Scenario 417 The following SPD entries assume that there are two hosts Host1 and 418 Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2 and 419 IPV4 addresses of the tunnel endpoints are denoted by IPV4-TEP1 and 420 IPV4-TEP2 respectively. 422 Host1's SPD OUT : 424 IF SRC = IPV6-EP1 && DST = IPV6-EP2 425 THEN USE ESP TUNNEL MODE SA: 426 outer source = IPv4-TEP1 427 outer dest = IPV4-TEP2 429 Host1's SPD IN: 431 IF SRC = IPV6-EP2 && DST = IPV6-EP1 432 THEN USE ESP TUNNEL MODE SA 433 outer source = IPV4-TEP2 434 outer dest = IPV4-TEP1 436 Host2's SPD OUT: 438 IF SRC = IPV6-EP2 && DST = IPV6-EP1 439 THEN USE ESP TUNNEL MODE SA 440 outer source = IPV4-TEP2 441 outer dest = IPV4-TEP1 443 Host2's SPD IN: 445 IF SRC = IPV6-EP1 && DST = IPV6-EP2 446 THEN USE ESP TUNNEL MODE SA: 447 outer source = IPv4-TEP1 448 outer dest = IPV4-TEP2 450 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 451 as phase 2 identities. With IKEv2, the traffic selectors are used to 452 carry the same information. 454 5.2.2 SPD for Host-to-Router scenario 456 The following SPD entries assume that the host has the IPv6 address 457 IPV6-EP1 and the tunnel end points of the host and router are 458 IPV4-TEP1 and IPV4-TEP2 respectively. If the tunnel is between a 459 router and a host where the router has allocated a IPV6-PREF/48 to 460 the host, the corresponding SPD entries can be derived by 461 substituting IPV6-EP1 by IPV6-PREF/48. 463 Host's SPD OUT: 465 IF SRC = IPV6-EP1 && DST = any 466 THEN use ESP TUNNEL MODE SA 467 outer source = IPV4-TEP1 468 outer dest = IPV4-TEP2 470 Host's SPD IN: 472 IF SRC = any && DST = IPV6-EP1 473 THEN use ESP TUNNEL MODE SA 474 outer source = IPV4-TEP1 475 outer dest = IPV4-TEP2 477 Router's SPD OUT: 479 IF SRC = any && DST = IPV6-EP1 480 THEN use ESP TUNNEL MODE SA 481 outer source = IPV4-TEP1 482 outer dest = IPV4-TEP2 484 Router's SPD IN: 486 IF SRC = IPV6-EP1 && DST = any 487 THEN use ESP TUNNEL MODE SA 488 outer source = IPV4-TEP1 489 outer dest = IPV4-TEP2 491 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and 492 ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity. 493 The starting address is zero IP address and the end address is all 494 ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address 495 and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With 496 IKEv2, the traffic selectors are used to carry the same information. 498 To describe the packet format the following acronyms are used 499 throughout this document: 501 o IPV4-TEP1 and IPV4-TEP2 denote the IPv4 address of the tunnel 502 endpoints. 504 o IPV6-EP1 and IPV6-EP2 denote the IPv6 address of the two IPv6 505 endpoints of the communication. 507 The packet format is the same for both transport mode and tunnel mode 508 as shown in Figure 9. 510 IPv4 header (source = IPV4-TEP1, 511 destination = IPV4-TEP2) 512 ESP header 513 IPv6 header (source = IPV6-EP1, 514 destination = IPV6-EP2) 516 Figure 9: Packet Format for transport and tunnel mode 518 This type of layering may not be valid with [RFC2401] since, with a 519 strict definition, IP does not meet the definition of a "higher layer 520 protocol" being the next protocol after an IP header. 522 With [I-D.ietf-ipsec-rfc2401bis] the definition about the "next layer 523 protocol" was explicitly expanded and hence this type of layering is 524 valid. 526 6. Dynamic Address Configuration 528 With the exchange of protected configuration payloads, IKEv2 is able 529 to provide the IKEv2 peer with DHCP-like information payloads. These 530 configuration payloads are exchanged between the IKEv2 initiator and 531 the responder with the help of the CFG_REQUEST/CFG_REPLY and 532 CFG_SET/CFG_ACK payloads. The former is used to request information 533 and the latter allows pushing configuration data. Configuration 534 information (e.g., a temporary address) can be carried in any request 535 to create a CHILD_SA by including a CP payload. 537 These configuration payloads are primiarly used for bootstrapping the 538 IKEv2 peer. Although these payloads are extensible they are not used 539 as a generic purpose management. 541 The following example exchange illustrates the usage of configuration 542 payloads: 544 Initiator Responder 545 ------------- -------------- 546 HDR, SAi1, KEi, Ni --> 548 <-- HDR(A,0), N(COOKIE) 550 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 552 <-- HDR, SAr1, KEr, Nr,[CERTREQ] 554 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 555 AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> 557 <-- HDR, SK {IDr, [CERT,] AUTH, 558 CP(CFG_REPLY), SAr2, TSi, TSr} 560 Figure 10: IKEv2 Configuration payload payload exchange 562 The example message exchange shown in Figure 10 shows IKEv2 with a 563 denial of service protection enabled exchange and a CFG_REQUEST in 564 message 5 and the corresponding response in message 6. The content 565 of these payloads, for example, contains (as given in Section 2.19 of 566 [I-D.ietf-ipsec-ikev2]): 568 CP(CFG_REQUEST)= 569 INTERNAL_ADDRESS(0.0.0.0) 570 INTERNAL_NETMASK(0.0.0.0) 571 INTERNAL_DNS(0.0.0.0) 572 TSi = (0, 0-65536,0.0.0.0-255.255.255.255) 573 TSr = (0, 0-65536,0.0.0.0-255.255.255.255) 575 CP(CFG_REPLY)= 576 INTERNAL_ADDRESS(10.168.219.202) 577 INTERNAL_NETMASK(255.255.255.0) 578 INTERNAL_SUBNET(10.168.219.0/255.255.255.0) 579 TSi = (0, 0-65536,10.168.219.202-10.168.219.202) 580 TSr = (0, 0-65536,10.168.219.0-10.168.219.255) 582 7. Extensible Authentication Support 584 In addition to the authentication mechanisms provided in IKEv2 the 585 Extensible Authentication Protocol (EAP) [I-D.ietf-eap-rfc2284bis] is 586 included which provides some flexibility for authentication 587 mechanisms. Figure 12 shows an example IKEv2 exchange with EAP 588 support. The usage of EAP offers two interesting features: 590 o User authentication is terminated at a different entity other than 591 the IKEv2 responder. This allows users' security credentials to 592 be kept in a central place (e.g., AAA server) and to terminate the 593 EAP method at this entity instead at the IKEv2 responder. 594 Authorization can also be executed at the same entity. 596 o A number of authentication and key exchange protocols are 597 supported via EAP method (such as EAP-AKA, EAP-SIM, SRP, etc.). 598 Each EAP methods provides its own properties and usage 599 environment. This provides a certain degree of flexibility. 601 Note that IKEv2 with EAP authentication still requires public key 602 based authentication of the IKEv2 responder outside the EAP 603 authentication. In most deployments this requires a server-side 604 public-key based authentication to protect the EAP exchange with a 605 uni-lateral authenticated tunnel. With the extensions proposed in 606 [I-D.eronen-ipsec-ikev2-eap-auth] only EAP authentication is used by 607 omitting the IKEv2 responder authentication. 609 Please note that Section 3.16 of [I-D.ietf-ipsec-ikev2] indicates 610 that the EAP Identity-Request/Identity-Response payload SHOULD NOT be 611 used. The IDr payload (message 3 in Figure 12) carries this identity 612 instead. As a consequence active user identity confidentiality for 613 the IKEv2 initiator is not provided. Special purpose EAP methods 614 must be used instead if this features is desired. 616 Figure 12 shows an example IKEv2 message exchange with EAP-AKA as an 617 EAP method. Note that the interaction between the IKEv2 responder 618 and the AAA infrastructure is not shown. 620 Initiator Responder 621 ------------- -------------- 622 HDR, SAi1, KEi, Ni --> 624 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 626 HDR, SK {IDi, [CERTREQ,] [IDr,] 627 SAi2, TSi, TSr} --> 629 <-- HDR, SK {IDr, [CERT,] AUTH, 630 EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) } 632 HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)} --> 634 <-- HDR, SK {EAP-Success, AUTH} 636 HDR, SK { AUTH } --> 638 <-- HDR, SK { SAr2, TSi, TSr } 640 Figure 12: EAP usage in IKEv2 with EAP-AKA 642 EAP will typically be used with a backend AAA server which raises 643 some security concerns. See [I-D.ietf-eap-keying] for a more 644 complete discussion of these security issues. 646 When a backend server is used, there are actually two authentication 647 exchanges: the EAP method between the client and the AAA server, and 648 another authentication between the AAA server and IKEv2 gateway. The 649 AAA server authenticates the client using the selected EAP method, 650 and they establish a session key. The AAA server then sends this key 651 to the IKEv2 gateway over a connection authenticated using e.g. 652 IPsec or TLS. The protocol used between the IKEv2 responder and the 653 AAA server could be, for instance, Diameter or RADIUS [RFC3579]. 654 RADIUS and Diameter are able to carry EAP payloads as described in 655 [RFC3579] and in [I-D.ietf-aaa-eap], respectively. 657 8. NAT Traversal 659 Network address (and port) translation devices are commonly found in 660 today's networks. A detailed description of the problem of IPsec 661 protected data traffic traversing a NAT including requirements are 662 discussed in [RFC3715]. 664 IKEv2 can detect the presence of a NAT automatically by sending an 665 Informational exchange with NAT_DETECTION_SOURCE_IP and 666 NAT_DETECTION_DESTINATION_IP payloads before establishing an IPsec 667 SA. These payloads are processed the same way as in the initial 668 IKE_SA_INIT exchange. Once a NAT is detected and both end points 669 support IPsec NAT traversal extensions UDP encapsulation can be 670 enabled. 672 More details about UDP encapsulation of IPsec protected IP packets 673 can be found in [I-D.ietf-ipsec-udp-encaps]. 675 For IPv6-over-IPv4 tunneling, NAT traversal is interesting for two 676 reasons: 678 1. One of the tunnel endpoints is often behind a NAT, and configured 679 tunneling, using protocol 41, is not guaranteed to traverse the 680 NAT. Hence, using IPsec tunnels would enable one to both set-up 681 a secure tunnel, and set-up a tunnel where it might not always be 682 possible without other tunneling mechanisms. 684 2. Using NAT traversal allows the outer address to change without 685 having to renegotiate the SAs. This could be very beneficial for 686 a crude form of mobility, and in scenarios the NAT changes the IP 687 addresses frequently. However, as the outer address may change, 688 this might introduce new security issues, and using tunnel mode 689 would be most appropriate. 691 9. Tunnel Endpoint Discovery 693 The IKEv2 initiator needs to know the address of the IKEv2 responder 694 to start IKEv2 signaling. A number of ways can be used to provide 695 the initiator with this information, for example: 697 o Using off-band mechanisms, e.g., from the ISP's web page. 699 o Using DNS to look up a service name by appending it to the DNS 700 search path provided by DHCPv4 (e.g. 701 "tunnel-service.example.com"). 703 o Using a DHCP option. 705 o Using a pre-configured or pre-determined IPv4 anycast address. 707 o Using other, unspecified or proprietary methods such as TED (see 708 [I-D.fluhrer-ted]). 710 For the purpose of this document it is assumed that this address can 711 be obtained somehow. Once the address has been learned, it is 712 configured as the tunnel end-point for the configured IPv6-over-IPv4 713 tunnel. 715 10. Example 717 TBD: Full-fledged example 719 11. Security Considerations 721 When you run IPv6-in-IPv4 tunnels (unsecured) over the Internet, it 722 is possible to "inject" packets in the tunnel by spoofing the source 723 address (data plane security), or if the tunnel is signalled somehow 724 (e.g., some messages where you authenticate to the server, so that 725 you would get a static v6 prefix), someone might be able to spoof the 726 signalling (control plane security). 728 To add security to both, the protocol for tunnel setup and to the 729 data traffic, the IPsec framework plays an important role. 731 IKEv2 is a signaling protocol with optional Denial of Service 732 protection which authenticates both end points (with different 733 identifities) and establishes two types of security associations 734 (CHILD-SAs and IKE-SA). The authentication mechanisms are very 735 flexible due to the built-in support for symmetric and asymmetric 736 cryptography (or even a combination of both) and the Extensible 737 Authentication Protocol support (as desribed in Figure 12). The 738 IKE-SA is used to secure most of the IKEv2 message exchange. In 739 particular the CHILD-SA exchange, Informational exchanges (such as 740 the dead-peer detection mechanisms used for liveness checks) and the 741 exchange of configuration messages are secured. The CHILD-SA 742 exchange leads to the establishment of a IPsec tunnel and the 743 creation of SAD and SPD entries. 745 As a summary, IKEv2 provides a secure signaling protocol for 746 establishing, maintaining and deleting an IPsec tunnel. 748 IPsec, with the Encapsulating Security Payload (ESP), offers 749 integrity and data origin authentication, confidentiality, with 750 optional (at the discretion of the receiver) anti-replay features. 751 The usage of confidentity-only is discouraged. ESP furthermore 752 provides limited traffic flow confidentality. 754 IPsec provides access control mechanisms through the distribution of 755 keys and also through the usage of policies dictated by the Security 756 Policy Database (SPD). Furthermore, through the usage of EAP and the 757 backend AAA infrastructure it is possible to enforce additional 758 authorization mechanisms (at the user level) at entities other than 759 the tunnel end points. 761 The NAT traversal mechanism provided by IKEv2 introduces some 762 weaknesses into IKEv2 and IPsec. These issues are discussed in more 763 detail in [I-D.ietf-ipsec-ikev2]. 765 Please note that the usage of IPsec for the scenarios described in 766 Figure 3, Figure 2 and Figure 1 does not aim to protect the 767 end-to-end communication. It protects just the tunnel part. It is 768 still possible for an IPv6 endpoint that is not attached to the IPsec 769 tunnel to spoof packets. 771 12. Open Issues 773 This section lists some open issues that will be resolved in future 774 versions of this document. 776 o Some text on the usage of IKEv1 might be useful. 778 o Discussion of 'Use of IPsec Transport Mode for Dynamic Routing' 779 [I-D.touch-ipsec-vpn] would be appropriate. 781 o A more detailed description of the address configuration mechanism 782 would be helpful. The configuration example with 783 CFG_REQUEST/CFG_REPLY payloads should contain IPv6 addresses. 785 o The full-fledged example of Section 10 is still missing. A 786 possible example is described below. 788 o Some notes on the implications of mobility interworking are still 789 missing. 791 o Discuss the use of link-local etc. messages with Tunnel mode SAs 792 -- i.e., how many SAs will be needed (and how they are negotiated) 793 if link-local messages will be present as well? 795 o The "Site-to-Router" scenarios separation is a bit weak -- any 796 better ideas how to categorize these would be appreciated. 798 o Better discussion of when transport/tunnel mode SAs make sense and 799 would probably be useful. 801 The following paragraph describes a possible scenario for Section 10. 803 +------------------+ 804 Transition | IPv6 Network | 805 Device | | 806 .--------. _----_ .--------. _----_ | .--------. | 807 | V6/V4 | _( IPv4 )_ | V4/V6 | _( IPv6 )_ | | V6 | | 808 | Host A |<-( Network )--| Router |-( Network )---> | Router | | 809 '--------' (_ _) '--------' (_ _) | | X | | 810 ^ '----' '----' |/>'--------' | 811 | // ^ | 812 | / | | | 813 | / | V | 814 | // | .-------. | 815 | / | | V6 | | 816 +-------------------------------------/ | | Host B | | 817 IPsec tunnel between | '--------' | 818 V6 Host and Router B +------------------+ 820 As noted in the figure above there is an IPv4/IPv6 transition 821 mechanism (which is not further specified) between the IPv4/IPv6 822 network. The following IPsec packet is sent from Host A towards Host 823 B (via router X). 825 Host A (outgoing) 827 IPsec ESP, Tunnel mode 828 Outer Header: 829 Src IP: IPv4 A 830 Dst IP: IPv4 Router X 831 Inner Header: 832 Src IP: IPv6 A 833 Dst IP: IPv6 Host B 835 The transition device then changes the source and destination IP 836 address is replaced (from IPv4 to an IPv6 address): 838 Router (incoming): 840 IPsec ESP, Tunnel mode 841 Outer Header: 842 Src IP: IPv6 NAT-PT box 843 Dst IP: IPv6 Router X (automatic encapsulation of IPv4 in IPv6) 844 Inner Header: 845 Src IP: IPv6 A 846 Dst IP: IPv6 Host B 848 Router X (outgoing towards Host B, packet decapsulated): 850 Header: 851 Src IP: IPv6 A 852 Dst IP: IPv6 Host B 854 The packet then travels the same path backwards experiencing the same 855 procressing. 857 13. Contributors 859 Please note that the authors are listed in alphabetical order. 861 Suresh Satapati also participated in the discussions. 863 14. Acknowledgments 865 The authors would like to thank Stephen Kent and Michael Richardson 866 for their comments. 868 We would like to thank Pasi Eronen for his text contributions. 870 15. References 872 15.1 Normative References 874 [I-D.ietf-eap-rfc2284bis] 875 Blunk, L., "Extensible Authentication Protocol (EAP)", 876 draft-ietf-eap-rfc2284bis-09 (work in progress), February 877 2004. 879 [I-D.ietf-ipsec-esp-v3] 880 Kent, S., "IP Encapsulating Security Payload (ESP)", 881 draft-ietf-ipsec-esp-v3-09 (work in progress), October 882 2004. 884 [I-D.ietf-ipsec-ikev2] 885 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 886 draft-ietf-ipsec-ikev2-17 (work in progress), October 887 2004. 889 [I-D.ietf-ipsec-ikev2-algorithms] 890 Schiller, J., "Cryptographic Algorithms for use in the 891 Internet Key Exchange Version 2", 892 draft-ietf-ipsec-ikev2-algorithms-05 (work in progress), 893 April 2004. 895 [I-D.ietf-ipsec-rfc2401bis] 896 Kent, S. and K. Seo, "Security Architecture for the 897 Internet Protocol", draft-ietf-ipsec-rfc2401bis-03 (work 898 in progress), September 2004. 900 [I-D.ietf-ipsec-udp-encaps] 901 Huttunen, A., "UDP Encapsulation of IPsec Packets", 902 draft-ietf-ipsec-udp-encaps-09 (work in progress), May 903 2004. 905 [I-D.ietf-ipsec-ui-suites] 906 Hoffman, P., "Cryptographic Suites for IPsec", 907 draft-ietf-ipsec-ui-suites-06 (work in progress), April 908 2004. 910 [I-D.ietf-v6ops-mech-v2] 911 Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 912 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06 913 (work in progress), September 2004. 915 15.2 Informative References 917 [I-D.bellovin-useipsec] 918 Bellovin, S., "Guidelines for Mandating the Use of IPsec", 919 draft-bellovin-useipsec-03 (work in progress), March 2004. 921 [I-D.blanchet-v6ops-tunnelbroker-tsp] 922 Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the 923 Tunnel Setup Protocol(TSP)", 924 draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in 925 progress), June 2004. 927 [I-D.eronen-ipsec-ikev2-eap-auth] 928 Eronen, P., "Extension for EAP Authentication in IKEv2", 929 draft-eronen-ipsec-ikev2-eap-auth-02 (work in progress), 930 October 2004. 932 [I-D.fluhrer-ted] 933 Fluhrer, S., "Tunnel Endpoint Discovery", 934 draft-fluhrer-ted-00 (work in progress), November 2001. 936 [I-D.ietf-aaa-eap] 937 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 938 Authentication Protocol (EAP) Application", 939 draft-ietf-aaa-eap-09 (work in progress), August 2004. 941 [I-D.ietf-eap-keying] 942 Aboba, B., "Extensible Authentication Protocol (EAP) Key 943 Management Framework", draft-ietf-eap-keying-03 (work in 944 progress), July 2004. 946 [I-D.ietf-ipsec-ikev2-iana] 947 Richardson, M., "Initial IANA registry contents", 948 draft-ietf-ipsec-ikev2-iana-02 (work in progress), April 949 2004. 951 [I-D.ietf-ipsec-rfc2402bis] 952 Kent, S., "IP Authentication Header", 953 draft-ietf-ipsec-rfc2402bis-08 (work in progress), October 954 2004. 956 [I-D.ietf-pana-ipsec] 957 Parthasarathy, M., "PANA enabling IPsec based Access 958 Control", draft-ietf-pana-ipsec-04 (work in progress), 959 September 2004. 961 [I-D.kivinen-mobike-design] 962 Kivinen, T., "Design of the MOBIKE protocol", 963 draft-kivinen-mobike-design-00 (work in progress), March 964 2004. 966 [I-D.touch-ipsec-vpn] 967 Touch, J., Eggert, L. and Y. Wang, "Use of IPsec Transport 968 Mode for Dynamic Routing", draft-touch-ipsec-vpn-07 (work 969 in progress), March 2004. 971 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 972 Internet Protocol", RFC 2401, November 1998. 974 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 975 Translator (NAT) Terminology and Considerations", RFC 976 2663, August 1999. 978 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 979 "Remote Authentication Dial In User Service (RADIUS)", RFC 980 2865, June 2000. 982 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 983 Dial In User Service) Support For Extensible 984 Authentication Protocol (EAP)", RFC 3579, September 2003. 986 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 987 Networks", BCP 84, RFC 3704, March 2004. 989 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 990 (NAT) Compatibility Requirements", RFC 3715, March 2004. 992 Authors' Addresses 994 Richard Graveman 995 RFG Security, LLC 996 15 Park Avenue 997 Morristown, New Jersey 07960 998 USA 1000 EMail: rfg@acm.org 1002 Mohan Parthasarathy 1003 Nokia 1004 313 Fairchild Drive 1005 Mountain View CA-94043 1006 USA 1008 EMail: mohanp@sbcglobal.net 1010 Pekka Savola 1011 CSC/FUNET 1012 Espoo 1013 Finnland 1015 EMail: psavola@funet.fi 1017 Hannes Tschofenig 1018 Siemens 1019 Otto-Hahn-Ring 6 1020 Munich, Bayern 81739 1021 Germany 1023 EMail: Hannes.Tschofenig@siemens.com 1025 Intellectual Property Statement 1027 The IETF takes no position regarding the validity or scope of any 1028 Intellectual Property Rights or other rights that might be claimed to 1029 pertain to the implementation or use of the technology described in 1030 this document or the extent to which any license under such rights 1031 might or might not be available; nor does it represent that it has 1032 made any independent effort to identify any such rights. Information 1033 on the procedures with respect to rights in RFC documents can be 1034 found in BCP 78 and BCP 79. 1036 Copies of IPR disclosures made to the IETF Secretariat and any 1037 assurances of licenses to be made available, or the result of an 1038 attempt made to obtain a general license or permission for the use of 1039 such proprietary rights by implementers or users of this 1040 specification can be obtained from the IETF on-line IPR repository at 1041 http://www.ietf.org/ipr. 1043 The IETF invites any interested party to bring to its attention any 1044 copyrights, patents or patent applications, or other proprietary 1045 rights that may cover technology that may be required to implement 1046 this standard. Please address the information to the IETF at 1047 ietf-ipr@ietf.org. 1049 Disclaimer of Validity 1051 This document and the information contained herein are provided on an 1052 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1053 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1054 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1055 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1056 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1057 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1059 Copyright Statement 1061 Copyright (C) The Internet Society (2004). This document is subject 1062 to the rights, licenses and restrictions contained in BCP 78, and 1063 except as set forth therein, the authors retain all their rights. 1065 Acknowledgment 1067 Funding for the RFC Editor function is currently provided by the 1068 Internet Society.