idnits 2.17.1 draft-ietf-mobike-protocol-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1579. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 20, 2005) is 6692 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: 'CERT' is mentioned on line 497, but not defined == Missing Reference: 'IDr' is mentioned on line 491, but not defined == Outdated reference: A later version (-08) exists of draft-dupont-ikev2-addrmgmt-07 == Outdated reference: A later version (-05) exists of draft-dupont-mipv6-3bombing-02 == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-17 == Outdated reference: A later version (-03) exists of draft-ietf-dna-hosts-02 == Outdated reference: A later version (-08) exists of draft-ietf-mobike-design-04 -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. 'MIP4') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'MIP6') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. 'STUN') (Obsoleted by RFC 5389) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MOBIKE Working Group P. Eronen, Ed. 3 Internet-Draft Nokia 4 Expires: June 23, 2006 December 20, 2005 6 IKEv2 Mobility and Multihoming Protocol (MOBIKE) 7 draft-ietf-mobike-protocol-07.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on June 23, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes the MOBIKE protocol, a mobility and 41 multihoming extension to Internet Key Exchange (IKEv2). MOBIKE 42 allows the IP addresses associated with IKEv2 and tunnel mode IPsec 43 Security Associations to change. A mobile VPN client could use 44 MOBIKE to keep the connection with the VPN gateway active while 45 moving from one address to another. Similarly, a multihomed host 46 could use MOBIKE to move the traffic to a different interface if, for 47 instance, the one currently being used stops working. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 5 54 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5 55 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 56 2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6 57 2.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 7 58 2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 10 59 3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 11 60 3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 11 61 3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 11 62 3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 12 63 3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 12 64 3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 13 65 3.6. Updating Additional Addresses . . . . . . . . . . . . . . 16 66 3.7. Return Routability Check . . . . . . . . . . . . . . . . . 18 67 3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18 68 3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19 69 3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20 70 3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 21 71 3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 21 72 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 22 73 4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 22 74 4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . 22 75 4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . 22 76 4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 22 77 4.2.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . 22 78 4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS 79 Notify Payloads . . . . . . . . . . . . . . . . . . . 22 80 4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . 23 81 4.2.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . 23 82 4.2.5. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . 23 83 4.2.6. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . 23 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 85 5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 25 86 5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 25 87 5.3. Denial-of-Service Attacks Against Third Parties . . . . . 26 88 5.4. Spoofing Network Connectivity Indications . . . . . . . . 27 89 5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 94 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 95 Appendix A. Implementation Considerations . . . . . . . . . . . . 31 96 A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31 97 A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 32 98 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 33 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 100 Intellectual Property and Copyright Statements . . . . . . . . . . 37 102 1. Introduction 104 1.1. Motivation 106 IKEv2 is used for performing mutual authentication, as well as 107 establishing and maintaining IPsec Security Associations (SAs). In 108 the base IKEv2 protocol, the IPsec and IKE SAs are created implicitly 109 between the IP addresses that are used when the IKE_SA is 110 established. These IP addresses are then used as the outer (tunnel 111 header) addresses for tunnel mode IPsec packets. Currently, it is 112 not possible to change these addresses after the IKE_SA has been 113 created. 115 There are scenarios where these IP addresses might change. One 116 example is mobility: a host changes its point of network attachment, 117 and receives a new IP address. Another example is a multihoming host 118 that would like to change to a different interface if, for instance, 119 the currently used interface stops working for some reason. 121 Although the problem can be solved by creating new IKE and IPsec SAs 122 when the addresses need to be changed, this may not be optimal for 123 several reasons. In some cases, creating a new IKE_SA may require 124 user interaction for authentication, such as entering a code from a 125 token card. Creating new SAs often involves expensive calculations 126 and possibly a large number of round-trips. For these reasons, a 127 mechanism for updating the IP addresses of existing IKE and IPsec SAs 128 is needed. The MOBIKE protocol described in this document provides 129 such a mechanism. 131 The main scenario for MOBIKE is enabling a remote access VPN user to 132 move from one address to another without re-establishing all security 133 associations with the VPN gateway. For instance, a user could start 134 from fixed Ethernet in the office and then disconnect the laptop and 135 move to the office's wireless LAN. When leaving the office the 136 laptop could start using GPRS; when the user arrives home, the laptop 137 could switch the the home wireless LAN. MOBIKE updates only the 138 outer (tunnel header) addresses of IPsec SAs, and the addresses and 139 other traffic selectors used inside the tunnel stay unchanged. Thus, 140 mobility can be (mostly) invisible to applications and their 141 connections using the VPN. 143 MOBIKE also supports more complex scenarios where the VPN gateway 144 also has several network interfaces: these interfaces could be 145 connected to different networks or ISPs, they may be a mix of IPv4 146 and IPv6 addresses, and the addresses may change over time. 147 Furthermore, both parties could be VPN gateways relaying traffic for 148 other parties. 150 1.2. Scope and Limitations 152 This document focuses on the main scenario outlined above, and 153 supports only tunnel mode IPsec SAs. 155 The mobility support in MOBIKE allows both parties to move, but does 156 not provide a "rendezvous" mechanism that would allow simultaneous 157 movement of both parties, or discovering the addresses when the 158 IKE_SA is first established. Therefore, MOBIKE is best suited for 159 situations where the address of at least one endpoint is relatively 160 stable, and can be discovered using existing mechanisms such as DNS 161 (see Section 3.1). 163 MOBIKE allows both parties to be multihomed; however, only one pair 164 of addresses is used for an SA at a time. In particular, load 165 balancing is beyond the scope of this specification. 167 MOBIKE follows the IKEv2 practice where a response message is sent to 168 the same address and port from which the request was received. This 169 implies that MOBIKE does not work over address pairs that provide 170 only unidirectional connectivity. 172 NATs introduce additional limitations beyond those listed above. For 173 details, refer to Section 2.3. 175 The base version of the MOBIKE protocol does not cover all potential 176 future use scenarios, such as transport mode, application to securing 177 SCTP, or optimizations desirable in specific circumstances. Future 178 extensions may be defined later to support additional requirements. 179 Please consult the MOBIKE design document [Design] for further 180 information and rationale behind these limitations. 182 1.3. Terminology and Notation 184 When messages containing IKEv2 payloads are described, optional 185 payloads are shown in brackets (for instance, "[FOO]"), and a plus 186 sign indicates that a payload can be repeated one or more times (for 187 instance, "FOO+"). To provide context, some diagrams also show what 188 existing IKEv2 payloads would typically be included in the exchanges. 189 These payloads are shown for illustrative purposes only; see [IKEv2] 190 for an authoritative description. 192 When this document talks about updating the source/destination 193 addresses of an IPsec SA, it means updating IPsec-related state so 194 that outgoing ESP/AH packets use those addresses in the tunnel 195 header. Depending on how the nominal division between Security 196 Association Database (SAD), Security Policy Database (SPD), and Peer 197 Authorization Database (PAD) described in [IPsecArch] is actually 198 implemented, an implementation can have several different places that 199 have to be updated. 201 In this document, the term "initiator" means the party who originally 202 initiated the first IKE_SA (in a series of possibly several rekeyed 203 IKE_SAs); "responder" is the other peer. During the lifetime of the 204 IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA 205 exchanges; in this case, the terms "exchange initiator" and "exchange 206 responder" are used. The term "original initiator" (which in [IKEv2] 207 refers to the party who started the latest IKE_SA rekeying) is not 208 used in this document. 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [KEYWORDS]. 214 2. Protocol Overview 216 2.1. Basic Operation 218 MOBIKE allows both parties to have several addresses, and there are 219 up to N*M pairs of IP addresses that could potentially be used. The 220 decision of which of these pairs to use has to take into account 221 several factors. First, the parties may have preferences about which 222 interface should be used due to, for instance, performance and cost 223 reasons. Second, the decision is constrained by the fact that some 224 of the pairs may not work at all due to incompatible IP versions, 225 outages in the network, problems at the local link at either end, and 226 so on. 228 MOBIKE solves this problem by taking a simple approach: the party 229 that initiated the IKE_SA (the "client" in a remote access VPN 230 scenario) is responsible for deciding which address pair is used for 231 the IPsec SAs and for collecting the information it needs to make 232 this decision (such as determining which address pairs work or do not 233 work). The other party (the "gateway" in a remote access VPN 234 scenario) simply tells the initiator what addresses it has but does 235 not update the IPsec SAs until it receives a message from the 236 initiator to do so. This approach applies to the addresses in the 237 IPsec SAs; in the IKE_SA case, the exchange initiator can decide 238 which addresses are used. 240 Making the decision at the initiator is consistent with how normal 241 IKEv2 works: the initiator decides which addresses it uses when 242 contacting the responder. It also makes sense, especially when the 243 initiator is a mobile node: it is in a better position to decide 244 which of its network interfaces should be used for both upstream and 245 downstream traffic. 247 The details of exactly how the initiator makes the decision, what 248 information is used in making it, how the information is collected, 249 how preferences affect the decision, and when a decision needs to be 250 changed are largely beyond the scope of MOBIKE. This does not mean 251 that these details are unimportant: on the contrary, they are likely 252 to be crucial in any real system. However, MOBIKE is concerned with 253 these details only to the extent that they are visible in IKEv2/IPsec 254 messages exchanged between the peers (and thus need to be 255 standardized to ensure interoperability). 257 Many of these issues are not specific to MOBIKE, but are common with 258 the use of existing hosts in dynamic environments or with mobility 259 protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms 260 already exist or are being developed to deal with these issues. For 261 instance, link layer and IP layer mechanisms can be used to track the 262 status of connectivity within the local link [RFC2461]; movement 263 detection is being specified for both IPv4 and IPv6 in [DNA4], 264 [DNA6], and so on. 266 Naturally, updating the addresses of IPsec SAs has to take into 267 account several security considerations. MOBIKE includes two 268 features designed to address these considerations. First, a "return 269 routability" check can be used to verify the addresses provided by 270 the peer. This makes it more difficult to flood third parties with 271 large amounts of traffic. Second, a "NAT prohibition" feature 272 ensures that IP addresses have not been modified by NATs, IPv4/IPv6 273 translation agents, or other similar devices. This feature is 274 enabled only when NAT Traversal is not used. 276 2.2. Example Protocol Runs 278 A simple MOBIKE exchange in a mobile scenario is illustrated below: 280 Initiator Responder 281 ----------- ----------- 282 1) (IP_I1:500 -> IP_R1:500) 283 HDR, SAi1, KEi, Ni, 284 N(NAT_DETECTION_SOURCE_IP), 285 N(NAT_DETECTION_DESTINATION_IP) --> 287 <-- (IP_R1:500 -> IP_I1:500) 288 HDR, SAr1, KEr, Nr, 289 N(NAT_DETECTION_SOURCE_IP), 290 N(NAT_DETECTION_DESTINATION_IP) 292 2) (IP_I1:4500 -> IP_R1:4500) 293 HDR, SK { IDi, CERT, AUTH, 294 CP(CFG_REQUEST), 295 SAi2, TSi, TSr, 296 N(MOBIKE_SUPPORTED) } --> 298 <-- (IP_R1:4500 -> IP_I1:4500) 299 HDR, SK { IDr, CERT, AUTH, 300 CP(CFG_REPLY), 301 SAr2, TSi, TSr, 302 N(MOBIKE_SUPPORTED) } 304 (Initiator gets information from lower layers that its attachment 305 point and address have changed.) 307 3) (IP_I2:4500 -> IP_R1:4500) 308 HDR, SK { N(UPDATE_SA_ADDRESSES), 309 N(NAT_DETECTION_SOURCE_IP), 310 N(NAT_DETECTION_DESTINATION_IP) } --> 312 <-- (IP_R1:4500 -> IP_I2:4500) 313 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 314 N(NAT_DETECTION_DESTINATION_IP) } 316 (Responder verifies that the initiator has given it 317 a correct IP address.) 319 4) <-- (IP_R1:4500 -> IP_I2:4500) 320 HDR, SK { N(COOKIE2) } 322 (IP_I2:4500 -> IP_R1:4500) 323 HDR, SK { N(COOKIE2) } --> 325 Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform 326 each other that they support MOBIKE. In step 3, the initiator 327 notices a change in its own address, and informs the responder about 328 this by sending an INFORMATIONAL request containing the 329 UPDATE_SA_ADDRESSES notification. The request is sent using the new 330 IP address. At this point, it also starts to use the new address as 331 a source address in its own outgoing ESP traffic. Upon receiving the 332 UPDATE_SA_ADDRESSES notification the responder records the new 333 address, and if so required by policy, performs a return routability 334 check of the address. When this check (step 4) completes, the 335 responder starts to use the new address as the destination for its 336 outgoing ESP traffic. 338 Another protocol run in a multihoming scenario is illustrated below. 339 In this scenario, the initiator has one address but the responder has 340 two. 342 Initiator Responder 343 ----------- ----------- 344 1) (IP_I1:500 -> IP_R1:500) 345 HDR, SAi1, KEi, Ni, 346 N(NAT_DETECTION_SOURCE_IP), 347 N(NAT_DETECTION_DESTINATION_IP) --> 349 <-- (IP_R1:500 -> IP_I1:500) 350 HDR, SAr1, KEr, Nr, 351 N(NAT_DETECTION_SOURCE_IP), 352 N(NAT_DETECTION_DESTINATION_IP) 354 2) (IP_I1:4500 -> IP_R1:4500) 355 HDR, SK { IDi, CERT, AUTH, 356 CP(CFG_REQUEST), 357 SAi2, TSi, TSr, 358 N(MOBIKE_SUPPORTED) } --> 360 <-- (IP_R1:4500 -> IP_I1:4500) 361 HDR, SK { IDr, CERT, AUTH, 362 CP(CFG_REPLY), 363 SAr2, TSi, TSr, 364 N(MOBIKE_SUPPORTED), 365 N(ADDITIONAL_IP4_ADDRESS) } 367 (The initiator suspects a problem in the currently used address pair, 368 and probes its liveness.) 369 3) (IP_I1:4500 -> IP_R1:4500) 370 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 371 N(NAT_DETECTION_DESTINATION_IP) } --> 373 (IP_I1:4500 -> IP_R1:4500) 374 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 375 N(NAT_DETECTION_DESTINATION_IP) } --> 377 ... 379 (Eventually, the initiator gives up on the current address pair, and 380 tests the other available address pair.) 382 4) (IP_I1:4500 -> IP_R2:4500) 383 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 384 N(NAT_DETECTION_DESTINATION_IP) } 386 <-- (IP_R2:4500 -> IP_I1:4500) 387 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 388 N(NAT_DETECTION_DESTINATION_IP) } 390 (This worked, and the initiator requests the peer to switch to new 391 addresses.) 393 5) (IP_I1:4500 -> IP_R2:4500) 394 HDR, SK { N(UPDATE_SA_ADDRESSES), 395 N(NAT_DETECTION_SOURCE_IP), 396 N(NAT_DETECTION_DESTINATION_IP), 397 N(COOKIE2) } --> 399 <-- (IP_R2:4500 -> IP_I1:4500) 400 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 401 N(NAT_DETECTION_DESTINATION_IP), 402 N(COOKIE2) } 404 2.3. MOBIKE and Network Address Translation (NAT) 406 In some MOBIKE scenarios the network may contain NATs or stateful 407 packet filters (for brevity, the rest of this document talks simply 408 about NATs). The NAT Traversal feature specified in [IKEv2] allows 409 IKEv2 to work through NATs in many cases, and MOBIKE can leverage 410 this functionality: when the addresses used for IPsec SAs are 411 changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed. 413 Nevertheless, there are some limitations because NATs usually 414 introduce an asymmetry in the network: only packets coming from the 415 "inside" cause state to be created. This asymmetry leads to 416 restrictions on what MOBIKE can do. To give a concrete example, 417 consider a situation where both peers have only a single address, and 418 the initiator is behind a NAT. If the responder's address now 419 changes, it needs to send a packet to the initiator using its new 420 address. However, if the NAT is, for instance, of the common 421 "restricted cone" type (see [STUN] for one description of different 422 NAT types), this is not possible: the NAT will drop packets sent from 423 the new address (unless the initiator has previously sent a packet to 424 that address -- which it cannot do until it knows the address). 426 For simplicity, MOBIKE does not attempt to handle all possible NAT- 427 related scenarios. Instead, MOBIKE assumes that if NATs are present, 428 the initiator is the party "behind" the NAT, and does not fully 429 support the case where the responder's addresses change, meaning that 430 no special effort is made to support this functionality. Responders 431 may also be unaware of NATs or specific types of NATs they are 432 behind. However, when a change has occurred that will cause a loss 433 of connectivity, MOBIKE responders will still attempt to inform the 434 initiator of the change. Depending on, for instance, the exact type 435 of NAT, it may or may not succeed. However, analyzing the exact 436 circumstances when this will or will not work is not done in this 437 document. 439 3. Protocol Exchanges 441 3.1. Initial IKE Exchange 443 The initiator is responsible for finding a working pair of addresses 444 so that the initial IKE exchange can be carried out. Any information 445 from MOBIKE extensions will only be available later, when the 446 exchange has progressed far enough. Exactly how the addresses used 447 for the initial exchange are discovered is beyond the scope of this 448 specification; typical sources of information include local 449 configuration and DNS. 451 If either or both of the peers have multiple addresses, some 452 combinations may not work. Thus, the initiator SHOULD try various 453 source and destination address combinations when retransmitting the 454 IKE_SA_INIT request. 456 3.2. Signaling Support for MOBIKE 458 Implementations that wish to use MOBIKE for a particular IKE_SA MUST 459 include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in 460 case of multiple IKE_AUTH exchanges, in the message containing the SA 461 payload). 463 The format of the MOBIKE_SUPPORTED notification is described in 464 Section 4. 466 3.3. Initial Tunnel Header Addresses 468 When an IPsec SA is created, the tunnel header IP addresses (and 469 port, if doing UDP encapsulation) are taken from the IKE_SA, not the 470 IP header of the IKEv2 message requesting the IPsec SA. The 471 addresses in the IKE_SA are initialized from the IP header of the 472 first IKE_AUTH request. 474 The addresses are taken from the IKE_AUTH request because IKEv2 475 requires changing from port 500 to 4500 if a NAT is discovered. To 476 simplify things, implementations that support both this specification 477 and NAT Traversal MUST change to port 4500 if the correspondent also 478 supports both, even if no NAT was detected between them (this way, 479 there is no need to change the ports later if a a NAT is detected on 480 some other path). 482 3.4. Additional Addresses 484 Both the initiator and responder MAY include one or more 485 ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in 486 the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the 487 message containing the SA payload). 489 Initiator Responder 490 ----------- ----------- 491 HDR, SK { IDi, [CERT], [IDr], AUTH, 492 [CP(CFG_REQUEST)] 493 SAi2, TSi, TSr, 494 N(MOBIKE_SUPPORTED), 495 [N(ADDITIONAL_*_ADDRESS)+] } --> 497 <-- HDR, SK { IDr, [CERT], AUTH, 498 [CP(CFG_REPLY)], 499 SAr2, TSi, TSr, 500 N(MOBIKE_SUPPORTED) 501 [N(ADDITIONAL_*_ADDRESS)+] } 503 The recipient stores this information, but no other action is taken 504 at this time. 506 Although both the initiator and responder maintain a set of peer 507 addresses (logically associated with the IKE_SA), it is important to 508 note that they use this information for slightly different purposes. 510 The initiator uses the set of responder addresses as an input to its 511 address selection policy; it may, at some later point, decide to move 512 the IPsec traffic to one of these addresses using the procedure 513 described in Section 3.5. The responder normally does not use the 514 set of initiator addresses for anything: the addresses are used only 515 when the responder's own addresses change (see Section 3.6). 517 The set of addresses available to the peers can change during the 518 lifetime of the IKE_SA. The procedure for updating this information 519 is described in Section 3.6. 521 Note that if some of the initiator's interfaces are behind a NAT 522 (from the responder's point of view), the addresses received by the 523 responder will be incorrect. This means the procedure for changing 524 responder addresses described in Section 3.6 does not fully work when 525 the initiator is behind a NAT. For the same reason, the peers also 526 SHOULD NOT use this information for any other purpose than what is 527 explicitly described either in this document or a future 528 specification updating it. 530 3.5. Changing Addresses in IPsec SAs 532 In MOBIKE, the initiator decides what addresses are used in the IPsec 533 SAs. That is, the responder does not normally update any IPsec SAs 534 without receiving an explicit UPDATE_SA_ADDRESSES request from the 535 initiator. (As described below, the responder can, however, update 536 the IKE_SA in some circumstances.) 538 The reasons why the initiator wishes to change the addresses are 539 largely beyond the scope of MOBIKE. Typically, triggers include 540 information received from lower layers, such as changes in IP 541 addresses or link-down indications. Some of this information can be 542 unreliable: for instance, ICMP messages could be spoofed by an 543 attacker. Unreliable information SHOULD be treated only as a hint 544 that there might be a problem, and the initiator SHOULD trigger dead 545 peer detection (that is, send an INFORMATIONAL request) to determine 546 if the current path is still usable. 548 Changing addresses can also be triggered by events within IKEv2. At 549 least the following events can cause the initiator to re-evaluate its 550 local address selection policy, possibly leading to changing the 551 addresses. 553 o An IKEv2 request has been re-transmitted several times, but no 554 valid reply has been received. This suggests the current path is 555 no longer working. 557 o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS, 558 ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is 559 received. This means the peer's addresses may have changed. This 560 is particularly important if the announced set of address no 561 longer contains the currently used address. 563 o An UNACCEPTABLE_ADDRESSES notification is received as a response 564 to address update request (described below). 566 o The initiator receives a NAT_DETECTION_DESTINATION_IP notification 567 that does not match the previous UPDATE_SA_ADDRESSES response (see 568 Section 3.8 for a more detailed description). 570 The description in the rest of this section assumes that the 571 initiator has already decided what the new addresses should be. When 572 this decision has been made, the initiator: 574 o Updates the IKE_SA with the new addresses, and sets the 575 "pending_update" flag in the IKE_SA. 577 o Updates the IPsec SAs associated with this IKE_SA with the new 578 addresses (unless the initiator's policy requires a return 579 routability check before updating the IPsec SAs, and the check has 580 not been done for this responder address yet). 582 o If the IPsec SAs were updated in the previous step: If NAT 583 Traversal is not enabled, and the responder supports NAT Traversal 584 (as indicated by NAT detection payloads in the IKE_SA_INIT 585 exchange), and the initiator either suspects or knows that a NAT 586 is likely to be present, enables NAT Traversal (that is, enables 587 UDP encapsulation of outgoing ESP packets and sending of NAT- 588 Keepalive packets). 590 o If there are outstanding IKEv2 requests (requests for which the 591 initiator has not yet received a reply), continues retransmitting 592 them using the addresses in the IKE_SA (the new addresses). 594 o When the window size allows, sends an INFORMATIONAL request 595 containing the UPDATE_SA_ADDRESSES notification (which does not 596 contain any data), and clears the "pending_update" flag. The 597 request will be as follows: 599 Initiator Responder 600 ----------- ----------- 601 HDR, SK { N(UPDATE_SA_ADDRESSES), 602 [N(NAT_DETECTION_SOURCE_IP), 603 N(NAT_DETECTION_DESTINATION_IP)], 604 [N(NO_NATS_ALLOWED)], 605 [N(COOKIE2)] } --> 607 o If a new address change occurs while waiting for the response, 608 starts again from the first step (and ignores responses to this 609 UPDATE_SA_ADDRESSES request). 611 When processing an INFORMATIONAL request containing the 612 UPDATE_SA_ADDRESSES notification, the responder: 614 o Determines whether it has already received a newer 615 UPDATE_SA_ADDRESSES request than this one (if the responder uses a 616 window size greater than one, it is possible that requests are 617 received out of order). If it has, a normal response message 618 (described below) is sent, but no other action is taken. 620 o If the NO_NATS_ALLOWED notification is present, processes it as 621 described in Section 3.9. 623 o Checks that the (source IP address, destination IP address) pair 624 in the IP header is acceptable according to local policy. If it 625 is not, replies with a message containing the 626 UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). 628 o Updates the IP addresses in the IKE_SA with the values from the IP 629 header. (Using the address from the IP header is consistent with 630 normal IKEv2, and allows IKEv2 to work with NATs without needing 631 unilateral self-address fixing [UNSAF].) 633 o Replies with an INFORMATIONAL response: 635 Initiator Responder 636 ----------- ----------- 637 <-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP), 638 N(NAT_DETECTION_DESTINATION_IP)], 639 [N(COOKIE2)] } 641 o If necessary, initiates a return routability check for the new 642 initiator address (see Section 3.7) and waits until the check is 643 completed. 645 o Updates the IPsec SAs associated with this IKE_SA with the new 646 addresses. 648 o If NAT Traversal is supported and NAT detection payloads were 649 included, enables or disables NAT Traversal. 651 When the initiator receives the reply: 653 o If an address change has occurred after the request was first 654 sent, no MOBIKE processing is done for the reply message because a 655 new UPDATE_SA_ADDRESSES is going to be sent (or has already been 656 sent, if window size greater than one is in use). 658 o If the response contains the UNEXPECTED_NAT_DETECTED notification, 659 it processes the response as described in Section 3.9. 661 o If the response contains an UNACCEPTABLE_ADDRESSES notification, 662 the initiator MAY select another addresses and retry the exchange, 663 keep on using the previously used addresses, or disconnect. 665 o It updates the IPsec SAs associated with this IKE_SA with the new 666 addresses (unless this was already done earlier before sending the 667 request; this is the case when no return routability check was 668 required). 670 o If NAT Traversal is supported and NAT detection payloads were 671 included, it enables or disables NAT Traversal. 673 There is one exception to the rule that the responder never updates 674 any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If 675 the source address that the responder is currently using becomes 676 unavailable (i.e., sending packets using that source address is no 677 longer possible), the responder is allowed to update the IPsec SAs to 678 use some other address (in addition to initiating the procedure 679 described in the next section). 681 3.6. Updating Additional Addresses 683 As described in Section 3.4, both the initiator and responder can 684 send a list of additional addresses in the IKE_AUTH exchange. This 685 information can be updated by sending an INFORMATIONAL exchange 686 request message that contains either one or more 687 ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the 688 NO_ADDITIONAL_ADDRESSES notification. 690 If the exchange initiator has only a single IP address, it is placed 691 in the IP header, and the message contains the 692 NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has 693 several addresses, one of them is placed in the IP header, and the 694 rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications. 695 The new list of addresses replaces the old information (in other 696 words, there are no separate add/delete operations; instead, the 697 complete list is sent every time these notifications are used). 699 The message exchange will look as follows: 701 Initiator Responder 702 ----------- ----------- 703 HDR, SK { [N(ADDITIONAL_*_ADDRESS)+], 704 [N(NO_ADDITIONAL_ADDRESSES)], 705 [N(NO_NATS_ALLOWED)], 706 [N(COOKIE2)] } --> 708 <-- HDR, SK { [N(COOKIE2)] } 710 When a request containing an ADDITIONAL_IP4_ADDRESS, 711 ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is 712 received, the exchange responder: 714 o Determines whether it has already received a newer request to 715 update the addresses (if a window size greater than one is used, 716 it is possible that the requests are received out of order). If 717 it has, a response message is sent, but the address set is not 718 updated. 720 o If the NO_NATS_ALLOWED notification is present, processes it as 721 described in Section 3.9. 723 o Updates the set of peer addresses based on the IP header and the 724 ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS and 725 NO_ADDITIONAL_ADDRESSES notifications. 727 o Sends a response. 729 The initiator MAY include these notifications in the same request as 730 UPDATE_SA_ADDRESSES. 732 If the request to update the addresses is retransmitted using several 733 different source addresses, a new INFORMATIONAL request MUST be sent. 735 There is one additional complication: when the responder wants to 736 update the address set, the currently used addresses may no longer 737 work. In this case, the responder uses the additional address list 738 received from the initiator, and the list of its own addresses, to 739 determine which addresses to use for sending the INFORMATIONAL 740 request. This is the only time the responder uses the additional 741 address list received from the initiator. 743 Note that both peers can have their own policies about what addresses 744 are acceptable to use, and certain types of policies may simplify 745 implementation. For instance, if the responder has a single fixed 746 address, it does not need to process the ADDITIONAL_IP4_ADDRESS and 747 ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring 748 unrecognized status notifications as already required in [IKEv2]). 750 Furthermore, if the initiator has a policy saying that only the 751 responder address specified in local configuration is acceptable, it 752 does not have to send its own additional addresses to the responder 753 (since the responder does not need them except when changing its own 754 address). 756 3.7. Return Routability Check 758 Both parties can optionally verify that the other party can actually 759 receive packets at the claimed address. By default, this "return 760 routability check" SHOULD be performed. In environments where the 761 peer is expected to be well-behaved (many corporate VPNs, for 762 instance), or the address can be verified by some other means (e.g., 763 a certificate issued by an authority trusted for this purpose), the 764 return routability check MAY be omitted. 766 The check can be done before updating the IPsec SAs, immediately 767 after updating them, or continuously during the connection. By 768 default, the return routability check SHOULD be done before updating 769 the IPsec SAs, but in some environments it MAY be postponed until 770 after the IPsec SAs have been updated. 772 Any INFORMATIONAL exchange can be used for return routability 773 purposes, with one exception (described later in this section): when 774 a valid response is received, we know the other party can receive 775 packets at the claimed address. 777 To ensure that the peer cannot generate the correct INFORMATIONAL 778 response without seeing the request, a new payload is added to 779 INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY 780 include a COOKIE2 notification, and if included, the recipient of an 781 INFORMATIONAL request MUST copy the notification as-is to the 782 response. When processing the response, the original sender MUST 783 verify that the value is the same one as sent. If the values do not 784 match, the IKE_SA MUST be closed. (See also Section 4.2.5 for the 785 format of the COOKIE2 notification.) 787 The exception mentioned earlier is as follows: If the same 788 INFORMATIONAL request has been sent to several different addresses 789 (i.e., the destination address in the IKE_SA has been updated after 790 the request was first sent), receiving the INFORMATIONAL response 791 does not tell which address is the working one. In this case, a new 792 INFORMATIONAL request needs to be sent to check return routability. 794 3.8. Changes in NAT Mappings 796 IKEv2 performs Dead Peer Detection (DPD) if there has recently been 797 only outgoing traffic on all of the SAs associated with the IKE_SA. 799 In MOBIKE, these messages can also be used to detect if NAT mappings 800 have changed (for example, if the keepalive interval is too long, or 801 the NAT box is rebooted). More specifically, if both peers support 802 both this specification and NAT Traversal, the 803 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 804 notifications MAY be included in any INFORMATIONAL request; if the 805 request includes them, the responder MUST also include them in the 806 response (but no other action is taken, unless otherwise specified). 808 When the initiator is behind a NAT (as detected earlier using the 809 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 810 notifications), it SHOULD include these notifications in DPD 811 messages, and compare the received NAT_DETECTION_DESTINATION_IP 812 notifications with the value from the previous UPDATE_SA_ADDRESSES 813 response (or the IKE_SA_INIT response). If the values do not match, 814 the IP address and/or port seen by the responder has changed, and the 815 initiator SHOULD send UPDATE_SA_ADDRESSES as described in 816 Section 3.5. If the initiator suspects that the NAT mapping has 817 changed, it MAY also skip the detection step and send 818 UPDATE_SA_ADDRESSES immediately. This saves one roundtrip if the NAT 819 mapping has indeed changed. 821 Note that this approach to detecting NAT mapping changes may cause an 822 extra address update when the IKE_SA is rekeyed. This is because the 823 NAT_DETECTION_DESTINATION_IP hash also includes the IKE SPIs, which 824 change when performing rekeying. This unnecessary update is 825 harmless, however. 827 When MOBIKE is in use, the dynamic updates specified in [IKEv2] 828 Section 2.23 (where the peer address and port are updated from the 829 last valid authenticated packet) work in a slightly different 830 fashion. The host not behind a NAT MUST NOT use these dynamic 831 updates for IKEv2 packets, but MAY use them for ESP packets. This 832 ensures that an INFORMATIONAL exchange that does not contain 833 UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be 834 used for, e.g., testing whether a particular path works. 836 3.9. NAT Prohibition 838 Basic IKEv2/IPsec without NAT Traversal support may work across some 839 types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in 840 tunnel mode. This is because the IKEv2 integrity checksum does not 841 cover the addresses in the IP header. This may be considered a 842 problem in some circumstances, because in some sense any modification 843 of the IP addresses can be considered an attack. 845 This specification addresses the issue by protecting the IP addresses 846 when NAT Traversal has not been explicitly enabled. This means that 847 MOBIKE without NAT Traversal support will not work if the paths 848 contain NATs, IPv4/IPv6 translation agents, or other nodes that 849 modify the addresses in the IP header. This feature is mainly 850 intended for IPv6 and site-to-site VPN cases, where the 851 administrators may know beforehand that NATs are not present, and 852 thus any modification to the packet can be considered an attack. 854 More specifically, when NAT Traversal is not enabled, all messages 855 that can update the addresses associated with the IKE_SA and/or IPsec 856 SAs (the first IKE_AUTH request and all INFORMATIONAL requests that 857 contain any of the following notifications: UPDATE_SA_ADDRESSES, 858 ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, 859 NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED 860 notification. The exchange responder MUST verify that the contents 861 of the NO_NATS_ALLOWED notification match the addresses in the IP 862 header. If they do not match, a response containing an 863 UNEXPECTED_NAT_DETECTED notification is sent. The response message 864 is sent to the address and port that the corresponding request came 865 from, not to the address contained in the NO_NATS_ALLOWED 866 notification. 868 If the exchange initiator receives an UNEXPECTED_NAT_DETECTED 869 notification in response to its INFORMATIONAL request, it SHOULD 870 retry the operation several times using new INFORMATIONAL requests. 871 Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the 872 IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several 873 times, starting from a new IKE_SA_INIT request. This ensures that an 874 attacker who is able to modify only a single packet does not 875 unnecessarily cause a path to remain unused. 877 If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange 878 responder MUST NOT use the contents of the NO_NATS_ALLOWED 879 notification for any other purpose than possibly logging the 880 information for troubleshooting purposes. 882 3.10. Path Testing 884 IKEv2 Dead Peer Detection allows the peers to detect if the currently 885 used path has stopped working. However, if either of the peers has 886 several addresses, Dead Peer Detection alone does not tell which of 887 the other paths might work. 889 If required by its address selection policy, the initiator can use 890 normal IKEv2 INFORMATIONAL request/response messages to test whether 891 a certain path works. Implementations MAY do path testing even if 892 the path currently being used is working to, for example, detect when 893 a better (but previously unavailable) path becomes available. 895 3.11. Failure Recovery and Timeouts 897 In MOBIKE, the initiator is responsible for detecting and recovering 898 from most failures. 900 To give the initiator enough time to detect the error, the responder 901 SHOULD use relatively long timeout intervals when, for instance, 902 retransmitting IKEv2 requests or deciding whether to initiate dead 903 peer detection. While no specific timeout lengths are required, it 904 is suggested that responders continue retransmitting IKEv2 requests 905 for at least five minutes before giving up. 907 3.12. Dead Peer Detection 909 MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but 910 as addresses may change, it is not sufficient to just verify that the 911 peer is alive, but also that it is synchronized with the address 912 updates and has not, for instance, ignored an address update due to 913 failure to complete return routability test. This means that when 914 there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the 915 addresses used in those packets and determine that they correspond to 916 those that should be employed. If they do not, such packets SHOULD 917 NOT be used as evidence that the peer is able to communicate with 918 this node and or that the peer has received all address updates. 920 4. Payload Formats 922 This specification defines several new IKEv2 Notify payload types. 923 See [IKEv2] Section 3.10 for a general description of the Notify 924 payload. 926 4.1. Notify Messages - Error Types 928 4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload 930 The responder can include this notification in an INFORMATIONAL 931 exchange response to indicate that the address change in the 932 corresponding request message (which contained an UPDATE_SA_ADDRESSES 933 notification) was not carried out. 935 The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA6. 936 The Protocol ID and SPI Size fields are set to zero. There is no 937 data associated with this Notify type. 939 4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload 941 See Section 3.9 for a description of this notification. 943 The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9. 944 The Protocol ID and SPI Size fields are set to zero. There is no 945 data associated with this Notify type. 947 4.2. Notify Messages - Status Types 949 4.2.1. MOBIKE_SUPPORTED Notify Payload 951 The MOBIKE_SUPPORTED notification is included in the IKE_AUTH 952 exchange to indicate that the implementation supports this 953 specification. 955 The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The 956 Protocol ID and SPI Size fields are set to zero. The notification 957 data field MUST be left empty (zero-length) when sending, and its 958 contents (if any) MUST be ignored when this notification is received. 959 This allows the field to be used by future versions of this protocol. 961 4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify 962 Payloads 964 Both parties can include ADDITIONAL_IP4_ADDRESS and/or 965 ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and 966 INFORMATIONAL exchange request messages; see Section 3.4 and 967 Section 3.6 for more detailed description. 969 The Notify Message Types for ADDITIONAL_IP4_ADDRESS and 970 ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA2 and TBD-BY-IANA3, 971 respectively. The Protocol ID and SPI Size fields are set to zero. 972 The data associated with these Notify types is either a four-octet 973 IPv4 address or a 16-octet IPv6 address. 975 4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload 977 The NO_ADDITIONAL_ADDRESSES notification can be included in an 978 INFORMATIONAL exchange request message to indicate that the exchange 979 initiator does not have addresses beyond the one used in the exchange 980 (see Section 3.6 for more detailed description). 982 The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-IANA4. 983 The Protocol ID and SPI Size fields are set to zero. There is no 984 data associated with this Notify type. 986 4.2.4. UPDATE_SA_ADDRESSES Notify Payload 988 This notification is included in INFORMATIONAL exchange requests sent 989 by the initiator to update addresses of the IKE_SA and IPsec SAs (see 990 Section 3.5). 992 The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA5. The 993 Protocol ID and SPI Size fields are set to zero. There is no data 994 associated with this Notify type. 996 4.2.5. COOKIE2 Notify Payload 998 This notification MAY be included in any INFORMATIONAL request for 999 return routability check purposes (see Section 3.7). If the 1000 INFORMATIONAL request includes COOKIE2, the exchange responder MUST 1001 copy the notification to the response message. 1003 The data associated with this notification MUST be between 8 and 64 1004 octets in length (inclusive), and MUST be chosen by the exchange 1005 initiator in a way that is unpredictable to the exchange responder. 1006 The Notify Message Type for this message is TBD-BY-IANA7. The 1007 Protocol ID and SPI Size fields are set to zero. 1009 4.2.6. NO_NATS_ALLOWED Notify Payload 1011 See Section 3.9 for a description of this notification. 1013 The Notify Message Type for this message is TBD-BY-IANA8. The 1014 notification data contains the IP addresses and ports from/to which 1015 the packet was sent. For IPv4, the notification data is 12 octets 1016 long and is defined as follows: 1018 1 2 3 1019 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 ! Source IPv4 address ! 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 ! Destination IPv4 address ! 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 ! Source port ! Destination port ! 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 For IPv6, the notification data is 36 octets long and is defined as 1029 follows: 1031 1 2 3 1032 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 ! ! 1035 ! Source IPv6 address ! 1036 ! ! 1037 ! ! 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 ! ! 1040 ! Destination IPv6 address ! 1041 ! ! 1042 ! ! 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 ! Source port ! Destination port ! 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 The Protocol ID and SPI Size fields are set to zero. 1049 5. Security Considerations 1051 The main goals of this specification are to maintain the security 1052 offered by usual IKEv2 procedures and to counter mobility-related 1053 threats in an appropriate manner. This section describes new 1054 security considerations introduced by MOBIKE. See [IKEv2] for 1055 security considerations for IKEv2 in general. 1057 5.1. Traffic Redirection and Hijacking 1059 MOBIKE payloads relating to updating addresses are encrypted, 1060 integrity protected, and replay protected using the IKE_SA. This 1061 assures that no one except the participants can, for instance, give a 1062 control message to change the addresses. 1064 However, as with normal IKEv2, the actual IP addresses in the IP 1065 header are not covered by the integrity protection. This means that 1066 a NAT between the parties (or an attacker acting as a NAT) can modify 1067 the addresses and cause incorrect tunnel header (outer) IP addresses 1068 to be used for IPsec SAs. The scope of this attack is limited mainly 1069 to denial-of-service because all traffic is protected using IPsec. 1071 This attack can only be launched by on-path attackers that are 1072 capable of modifying IKEv2 messages carrying NAT detection payloads 1073 (such as Dead Peer Detection messages). By modifying the IP header 1074 of these packets, the attackers can lead the peers to believe a new 1075 NAT or a changed NAT binding exists between them. The attack can 1076 continue as long as the attacker is on the path, modifying the IKEv2 1077 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms 1078 designed to detect NAT mapping changes will eventually recognize that 1079 the intended traffic is not getting through, and will update the 1080 addresses appropriately. 1082 MOBIKE introduces the NO_NATS_ALLOWED notification that is used to 1083 detect modification, by outsiders, of the addresses in the IP header. 1084 When this notification is used, communication through NATs and other 1085 address translators is impossible, so it is sent only when not doing 1086 NAT Traversal. This feature is mainly intended for IPv6 and site-to- 1087 site VPN cases, where the administrators may know beforehand that 1088 NATs are not present. 1090 5.2. IPsec Payload Protection 1092 The use of IPsec protection on payload traffic protects the 1093 participants against disclosure of the contents of the traffic, 1094 should the traffic end up in an incorrect destination or be 1095 eavesdropped along the way. 1097 However, security associations originally created for the protection 1098 of a specific flow between specific addresses may be updated by 1099 MOBIKE later on. This has to be taken into account if the level of 1100 required protection depends on, for instance, the current location of 1101 the VPN client. 1103 It is recommended that security policies, for peers that are allowed 1104 to use MOBIKE, are configured in a manner that takes into account 1105 that a single security association can be used at different times 1106 through paths of varying security properties. 1108 5.3. Denial-of-Service Attacks Against Third Parties 1110 Traffic redirection may be performed not just to gain access to the 1111 traffic or to deny service to the peers, but also to cause a denial- 1112 of-service attack for a third party. For instance, a high-speed TCP 1113 session or a multimedia stream may be redirected towards a victim 1114 host, causing its communications capabilities to suffer. 1116 The attackers in this threat can be either outsiders or even one of 1117 the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers 1118 can be easily dealt with if the authentication performed in the 1119 initial IKEv2 negotiation can be traced to persons who can be held 1120 responsible for the attack. This may not be the case in all 1121 scenarios, particularly with opportunistic approaches to security. 1123 If the attack is launched by an outsider, the traffic flow would 1124 normally stop soon due to the lack of responses (such as transport 1125 layer acknowledgements). However, if the original recipient of the 1126 flow is malicious, it could maintain the traffic flow for an extended 1127 period of time, since it often would be able to send the required 1128 acknowledgements (see [Aura02] for more discussion). 1130 It should also be noted, as shown in [Bombing], that without ingress 1131 filtering in the attacker's network, such attacks are already 1132 possible simply by sending spoofed packets from the attacker to the 1133 victim directly. Furthermore, if the attacker's network has ingress 1134 filtering, this attack is largely prevented for MOBIKE as well. 1135 Consequently, it makes little sense to protect against attacks of 1136 similar nature in MOBIKE. However, it still makes sense to limit the 1137 amplification capabilities provided to attackers, so that they cannot 1138 use stream redirection to send a large number of packets to the 1139 victim by sending just a few packets themselves. 1141 This specification includes return routability tests to limit the 1142 duration of any "third party bombing" attacks by off-path (relative 1143 to the victim) attackers. The tests are authenticated messages that 1144 the peer has to respond to, and can be performed either before the 1145 address change takes effect, immediately afterwards, or even 1146 periodically during the session. The tests contain unpredictable 1147 data, and only someone who has the keys associated with the IKE SA 1148 and has seen the request packet can properly respond to the test. 1150 The duration of the attack can also be limited if the victim reports 1151 the unwanted traffic to the originating IPsec tunnel endpoint using 1152 ICMP error messages or INVALID_SPI notifications. As described in 1153 [IKEv2] Section 2.21, this SHOULD trigger a liveness test, which also 1154 doubles as a return routability check if the COOKIE2 notification is 1155 included. 1157 5.4. Spoofing Network Connectivity Indications 1159 Attackers may spoof various indications from lower layers and the 1160 network in an effort to confuse the peers about which addresses are 1161 or are not working. For example, attackers may spoof link-layer 1162 error messages in an effort to cause the parties to move their 1163 traffic elsewhere or even to disconnect. Attackers may also spoof 1164 information related to network attachments, router discovery, and 1165 address assignments in an effort to make the parties believe they 1166 have Internet connectivity when, in reality, they do not. 1168 This may cause use of non-preferred addresses or even denial-of- 1169 service. 1171 MOBIKE does not provide any protection of its own for indications 1172 from other parts of the protocol stack. These vulnerabilities can be 1173 mitigated through the use of techniques specific to the other parts 1174 of the stack, such as validation of ICMP errors [ICMPAttacks], link 1175 layer security, or the use of [SEND] to protect IPv6 Router and 1176 Neighbor Discovery. 1178 Ultimately, MOBIKE depends on the delivery of IKEv2 messages to 1179 determine which paths can be used. If IKEv2 messages sent using a 1180 particular source and destination addresses reach the recipient and a 1181 reply is received, MOBIKE will usually consider the path working; if 1182 no reply is received even after retransmissions, MOBIKE will suspect 1183 the path is broken. An attacker who can consistently control the 1184 delivery or non-delivery of the IKEv2 messages in the network can 1185 thus influence which addresses actually get used. 1187 5.5. Address and Topology Disclosure 1189 MOBIKE address updates and the ADDITIONAL_IP4_ADDRESS/ 1190 ADDITIONAL_IP6_ADDRESS notifications reveal information about which 1191 networks the peers are connected to. 1193 For example, consider a host A with two network interfaces: a 1194 cellular connection and a wired Ethernet connection to a company LAN. 1195 If host A now contacts host B using IKEv2 and sends 1196 ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications, host B 1197 receives additional information it might not otherwise know. If host 1198 A used the cellular connection for the IKEv2 traffic, host B can also 1199 see the company LAN address (and perhaps further guess that host A is 1200 used by an employee of that company). If host A used the company LAN 1201 to make the connection, host B can see that host A has a subscription 1202 from this particular cellular operator. 1204 These additional addresses can also disclose more accurate location 1205 information than just a single address. Suppose that host A uses its 1206 cellular connection for IKEv2 traffic, but also sends an 1207 ADDITIONAL_IP4_ADDRESS notification containing an IP address 1208 corresponding to, say, a wireless LAN at a particular coffee shop 1209 location. It is likely that host B can now make a much better guess 1210 at A's location than would be possible based on the cellular IP 1211 address alone. 1213 Furthermore, as described in Section 3.4, some of the addresses could 1214 also be private addresses behind a NAT. 1216 In many environments, disclosing address information is not a problem 1217 (and indeed it cannot be avoided if the hosts wish to use those 1218 addresses for IPsec traffic). For instance, a remote access VPN 1219 client could consider the corporate VPN gateway sufficiently 1220 trustworthy for this purpose. Furthermore, the 1221 ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are 1222 sent encrypted, so the addresses are not visible to eavesdroppers 1223 (unless, of course, they are later used for sending IKEv2/IPsec 1224 traffic). 1226 However, if MOBIKE is used in some more opportunistic approach, it 1227 can be desirable to limit the information that is sent. Naturally, 1228 the peers do not have to disclose any addresses they do not want to 1229 use for IPsec traffic. Also, as noted in Section 3.6, an initiator 1230 whose policy is to always use the locally configured responder 1231 address does not have to send any ADDITIONAL_IP4_ADDRESS/ 1232 ADDITIONAL_IP6_ADDRESS payloads. 1234 6. IANA Considerations 1236 This document does not create any new namespaces to be maintained by 1237 IANA, but it requires new values in namespaces that have been defined 1238 in the IKEv2 base specification [IKEv2]. 1240 This document defines several new IKEv2 notifications whose values 1241 are to be allocated from the "IKEv2 Notify Message Types" namespace. 1243 Notify Messages - Error Types Value 1244 ----------------------------- ----- 1245 UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) 1246 UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) 1248 Notify Messages - Status Types Value 1249 ------------------------------ ----- 1250 MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) 1251 ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) 1252 ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) 1253 NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) 1254 UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) 1255 COOKIE2 TBD-BY-IANA7 (16396..40959) 1256 NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) 1258 These notifications are described in Section 4. 1260 7. Acknowledgements 1262 This document is a collaborative effort of the entire MOBIKE WG. We 1263 would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo 1264 Bagnulo, Stephane Beaulieu, Lakshminath Dondeti, Francis Dupont, Paul 1265 Hoffman, James Kempf, Tero Kivinen, Pete McCann, Mohan Parthasarathy, 1266 Pekka Savola, Bill Sommerfeld, Maureen Stillman, Shinta Sugimoto, 1267 Sami Vaarala, and Hannes Tschofenig. This document also incorporates 1268 ideas and text from earlier MOBIKE-like protocol proposals, including 1269 [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design 1270 document [Design]. 1272 8. References 1274 8.1. Normative References 1276 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1277 draft-ietf-ipsec-ikev2-17 (work in progress), 1278 October 2004. 1280 [IPsecArch] 1281 Kent, S. and K. Seo, "Security Architecture for the 1282 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work 1283 in progress), March 2005. 1285 [KEYWORDS] 1286 Bradner, S., "Key words for use in RFCs to Indicate 1287 Requirement Levels", RFC 2119, March 1997. 1289 8.2. Informative References 1291 [AddrMgmt] 1292 Dupont, F., "Address Management for IKE version 2", 1293 draft-dupont-ikev2-addrmgmt-07 (work in progress), 1294 May 2005. 1296 [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 1297 Location Management", Proc. 18th Annual Computer Security 1298 Applications Conference (ACSAC), December 2002. 1300 [Bombing] Dupont, F., "A note about 3rd party bombing in Mobile 1301 IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), 1302 June 2005. 1304 [DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1305 Network Attachment (DNA) in IPv4", 1306 draft-ietf-dhc-dna-ipv4-17 (work in progress), 1307 October 2005. 1309 [DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting 1310 Network Attachment in IPv6 - Best Current Practices for 1311 hosts", draft-ietf-dna-hosts-02 (work in progress), 1312 October 2005. 1314 [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE 1315 protocol", draft-ietf-mobike-design-04 (work in progress), 1316 October 2005. 1318 [ICMPAttacks] 1319 Gont, F., "ICMP attacks against TCP", 1320 draft-gont-tcpm-icmp-attacks-05 (work in progress), 1321 October 2005. 1323 [Kivinen] Kivinen, T., "MOBIKE protocol", 1324 draft-kivinen-mobike-protocol-00 (work in progress), 1325 February 2004. 1327 [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1328 August 2002. 1330 [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1331 in IPv6", RFC 3775, June 2004. 1333 [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO- 1334 IKE)", draft-eronen-mobike-mopo-02 (work in progress), 1335 February 2005. 1337 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1338 Discovery for IP Version 6 (IPv6)", RFC 2461, 1339 December 1998. 1341 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1342 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1344 [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and 1345 Multihoming Extensions for IKEv2 (SMOBIKE)", 1346 draft-eronen-mobike-simple-00 (work in progress), 1347 March 2004. 1349 [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1350 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1351 Through Network Address Translators (NATs)", RFC 3489, 1352 March 2003. 1354 [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- 1355 Address Fixing (UNSAF) Across Network Address 1356 Translation", RFC 3424, November 2002. 1358 Appendix A. Implementation Considerations 1360 A.1. Links from SPD Cache to Outbound SAD Entries 1362 [IPsecArch] Section 4.4.2 says that "For outbound processing, each 1363 SAD entry is pointed to by entries in the SPD-S part of the SPD 1364 cache". The document does not specify how exactly this "pointing" is 1365 done, since this is an implementation detail that does not have to be 1366 standardized. 1368 However, it is clear that the links between the SPD cache and the SAD 1369 have to be done correctly to ensure that outbound packets are sent 1370 over the right SA. Some implementations are known to have problems 1371 in this area. 1373 In particular, simply storing the (remote tunnel header IP address, 1374 remote SPI) pair in the SPD cache is not sufficient, since the pair 1375 does not always uniquely identify a single SAD entry. For instance, 1376 two hosts behind the same NAT can accidentally happen to choose the 1377 same SPI value. The situation can also occur when a host is assigned 1378 an IP address previously used by some other host, and the SAs 1379 associated with the old host have not yet been deleted by dead peer 1380 detection. This may lead to packets being sent over the wrong SA or, 1381 if the key management daemon ensures the pair is unique, denying the 1382 creation of otherwise valid SAs. 1384 Storing the remote tunnel header IP address in the SPD cache may also 1385 complicate the implementation of MOBIKE, since the address can change 1386 during the lifetime of the SA. Thus, we recommend implementing the 1387 links between the SPD cache and the SAD in a way that does not 1388 require modification when the tunnel header IP address is updated by 1389 MOBIKE. 1391 A.2. Creating Outbound SAs 1393 When an outbound packet requires IPsec processing but no suitable SA 1394 exists, a new SA will be created. In this case, the host has to 1395 determine (1) who is the right peer for this SA, (2) whether the host 1396 already has an IKE_SA with this peer, and (3) if no IKE_SA exists, 1397 the IP address(es) of the peer for contacting it. 1399 Neither [IPsecArch] nor MOBIKE specifies how exactly these three 1400 steps are carried out. [IPsecArch] Section 4.4.3.4 says: 1402 For example, assume that IKE A receives an outbound packet 1403 destined for IP address X, a host served by a security 1404 gateway. RFC 2401 and 2401bis do not specify how A determines 1405 the address of the IKE peer serving X. However, any peer 1406 contacted by A as the presumed representative for X must be 1407 registered in the PAD in order to allow the IKE exchange to be 1408 authenticated. Moreover, when the authenticated peer asserts 1409 that it represents X in its traffic selector exchange, the PAD 1410 will be consulted to determine if the peer in question is 1411 authorized to represent X. 1413 In step 1, there may be more than one possible peer (e.g., several 1414 security gateways that are allowed to represent X). In step 3, the 1415 host may need to consult a directory such as DNS to determine the 1416 peer IP address(es). 1418 When performing these steps, implementations may use information 1419 contained in the SPD, the PAD, and possibly some other 1420 implementation-specific databases. Regardless of how exactly the 1421 steps are implemented, it is important to remember that IP addresses 1422 can change, and that an IP address alone does not always uniquely 1423 identify a single IKE peer (for the same reasons as why the 1424 combination of the remote IP address and SPI does not uniquely 1425 identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 1426 and 2 it may be easier to identify the "right peer" using its 1427 authenticated identity instead of its current IP address. However, 1428 these implementation details are beyond the scope of this 1429 specification. 1431 Appendix B. Changelog 1433 (This section should be removed by the RFC editor.) 1435 Changes from -06 to -07: 1437 o Editorial fixes from AD evaluation. 1439 Changes from -06.a to -06: 1441 o Clarified text about certificates and omitting RR (issue 54). 1443 o Take initial addresses from IKE_AUTH even when not doing NAT-T 1444 (issue 60). 1446 o Added text about dead peer detection (issue 71). 1448 o Fixed port numbers in examples (issue 73). 1450 o Updated acknowledgements list and references. 1452 Changes from -05 to -06.a: 1454 o Clarified third-party DoS security considerations (issue 45). 1456 o Clarified the use of ADDITIONAL_*_ADDRESS/NO_ADDITIONAL_ADDRESSES 1457 notifications and deleting addresses (issues 46 and 58). 1459 o Better separation of error and status types (issue 59). 1461 o Changed order of fields in NO_NATS_ALLOWED and provided a bit 1462 diagram (issue 59). 1464 o Added implementation considerations appendix (issues 51 and 70). 1466 o Editorial fixes and clarifications (issues 54, 56, 59, 64, 72). 1468 Changes from -04 to -05: 1470 o Editorial fixes and clarifications (issue 44, 47, 48, 49, 50, 53, 1471 62, 66, 67, 68, 69). 1473 o Ignore data in MOBIKE_SUPPORTED (issue 61). 1475 Changes from -03 to -04: 1477 o Copy-editing done by the RFC editor. 1479 Changes from -02 to -03: 1481 o Editorial fixes and clarifications (issues 42 and 43). 1483 o Clarified IANA considerations (issue 42). 1485 o Added security considerations about address and topology 1486 disclosure (issue 42). 1488 o Added a suggestion about retransmission timeout (issue 42). 1490 o Change dynamic address updates: MUST NOT do them based on IKEv2 1491 packets, MAY do based on ESP (issue 34). 1493 o Mandate NAT prohibition if not doing NAT traversal (issue 41). 1495 o Clarified security considerations related to NATs (issue 41). 1497 o Don't use SHA-1 in NO_NATS_ALLOWED, just send the addresses (issue 1498 42). 1500 o Added a short section about path testing. 1502 o Added an example protocol run in Section 1. 1504 Changes from -01 to -02: 1506 o Moved MOBIKE_SUPPORTED from IKE_SA_INIT to IKE_AUTH (issues 35, 1507 37). 1509 o Changed terminology related to NAT prohibition (issues 22, 24). 1511 o Rewrote much of the ADDITIONAL_*_ADDRESS text, added 1512 NO_ADDITIONAL_ADDRESSES notification. 1514 o Use NAT detection payloads to detect changes in NAT mappings 1515 (issue 34). 1517 o Removed separate PATH_TEST message (issue 34). 1519 o Clarified processing of UNACCEPTABLE_ADDRESSES when request has 1520 been sent using several different addresses (issue 36). 1522 o Clarified changing of ports 500/4500 (issue 33). 1524 o Updated security considerations (issues 27 and 28). 1526 o No need to include COOKIE2 in non-RR messages (issue 32). 1528 o Many editorial fixes and clarifications (issue 38, 40). 1530 o Use the terms initiator and responder more consistently. 1532 o Clarified that this document does not solve all problems in MOBIKE 1533 WG charter (issue 40). 1535 Changes from -00 to -01: 1537 o Editorial fixes and small clarifications (issues 21, 25, 26, 29). 1539 o Use Protocol ID zero for notifications (issue 30). 1541 o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue 1542 23). 1544 o Use the word "path" only in senses that include the route taken 1545 (issue 29). 1547 Author's Address 1549 Pasi Eronen (editor) 1550 Nokia Research Center 1551 P.O. Box 407 1552 FIN-00045 Nokia Group 1553 Finland 1555 Email: pasi.eronen@nokia.com 1557 Intellectual Property Statement 1559 The IETF takes no position regarding the validity or scope of any 1560 Intellectual Property Rights or other rights that might be claimed to 1561 pertain to the implementation or use of the technology described in 1562 this document or the extent to which any license under such rights 1563 might or might not be available; nor does it represent that it has 1564 made any independent effort to identify any such rights. Information 1565 on the procedures with respect to rights in RFC documents can be 1566 found in BCP 78 and BCP 79. 1568 Copies of IPR disclosures made to the IETF Secretariat and any 1569 assurances of licenses to be made available, or the result of an 1570 attempt made to obtain a general license or permission for the use of 1571 such proprietary rights by implementers or users of this 1572 specification can be obtained from the IETF on-line IPR repository at 1573 http://www.ietf.org/ipr. 1575 The IETF invites any interested party to bring to its attention any 1576 copyrights, patents or patent applications, or other proprietary 1577 rights that may cover technology that may be required to implement 1578 this standard. Please address the information to the IETF at 1579 ietf-ipr@ietf.org. 1581 Disclaimer of Validity 1583 This document and the information contained herein are provided on an 1584 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1585 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1586 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1587 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1588 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1589 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1591 Copyright Statement 1593 Copyright (C) The Internet Society (2005). This document is subject 1594 to the rights, licenses and restrictions contained in BCP 78, and 1595 except as set forth therein, the authors retain all their rights. 1597 Acknowledgment 1599 Funding for the RFC Editor function is currently provided by the 1600 Internet Society.