idnits 2.17.1 draft-ietf-mobike-protocol-08.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 1652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1642. ** 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 (February 22, 2006) is 6630 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 504, but not defined == Missing Reference: 'IDr' is mentioned on line 498, but not defined == Missing Reference: 'RFC2401' is mentioned on line 1452, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) == Outdated reference: A later version (-05) exists of draft-dupont-mipv6-3bombing-03 == Outdated reference: A later version (-09) exists of draft-eronen-ipsec-ikev2-clarifications-07 == 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-07 -- 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: 5 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: August 26, 2006 February 22, 2006 6 IKEv2 Mobility and Multihoming Protocol (MOBIKE) 7 draft-ietf-mobike-protocol-08.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 August 26, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 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 Exchanges . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 28 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 94 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 95 Appendix A. Implementation Considerations . . . . . . . . . . . . 32 96 A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 32 97 A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 32 98 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 33 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 100 Intellectual Property and Copyright Statements . . . . . . . . . . 38 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 [IKEv2], the IKE SAs and tunnel mode IPsec 109 SAs are created implicitly between the IP addresses that are used 110 when the IKE_SA is established. These IP addresses are then used as 111 the outer (tunnel header) addresses for tunnel mode IPsec packets 112 (transport mode IPsec SAs are beyond the scope of this document). 113 Currently, it is not possible to change these addresses after the 114 IKE_SA has been created. 116 There are scenarios where these IP addresses might change. One 117 example is mobility: a host changes its point of network attachment 118 and receives a new IP address. Another example is a multihoming host 119 that would like to change to a different interface if, for instance, 120 the currently used interface stops working for some reason. 122 Although the problem can be solved by creating new IKE and IPsec SAs 123 when the addresses need to be changed, this may not be optimal for 124 several reasons. In some cases, creating a new IKE_SA may require 125 user interaction for authentication, such as entering a code from a 126 token card. Creating new SAs often involves expensive calculations 127 and possibly a large number of round-trips. For these reasons, a 128 mechanism for updating the IP addresses of existing IKE and IPsec SAs 129 is needed. The MOBIKE protocol described in this document provides 130 such a mechanism. 132 The main scenario for MOBIKE is enabling a remote access VPN user to 133 move from one address to another without re-establishing all security 134 associations with the VPN gateway. For instance, a user could start 135 from fixed Ethernet in the office and then disconnect the laptop and 136 move to the office's wireless LAN. When leaving the office the 137 laptop could start using GPRS; when the user arrives home, the laptop 138 could switch to the home wireless LAN. MOBIKE updates only the outer 139 (tunnel header) addresses of IPsec SAs, and the addresses and other 140 traffic selectors used inside the tunnel stay unchanged. Thus, 141 mobility can be (mostly) invisible to applications and their 142 connections using the VPN. 144 MOBIKE also supports more complex scenarios where the VPN gateway 145 also has several network interfaces: these interfaces could be 146 connected to different networks or ISPs, they may be a mix of IPv4 147 and IPv6 addresses, and the addresses may change over time. 148 Furthermore, both parties could be VPN gateways relaying traffic for 149 other parties. 151 1.2. Scope and Limitations 153 This document focuses on the main scenario outlined above, and 154 supports only tunnel mode IPsec SAs. 156 The mobility support in MOBIKE allows both parties to move, but does 157 not provide a "rendezvous" mechanism that would allow simultaneous 158 movement of both parties, or discovering the addresses when the 159 IKE_SA is first established. Therefore, MOBIKE is best suited for 160 situations where the address of at least one endpoint is relatively 161 stable, and can be discovered using existing mechanisms such as DNS 162 (see Section 3.1). 164 MOBIKE allows both parties to be multihomed; however, only one pair 165 of addresses is used for an SA at a time. In particular, load 166 balancing is beyond the scope of this specification. 168 MOBIKE follows the IKEv2 practice where a response message is sent to 169 the same address and port from which the request was received. This 170 implies that MOBIKE does not work over address pairs that provide 171 only unidirectional connectivity. 173 NATs introduce additional limitations beyond those listed above. For 174 details, refer to Section 2.3. 176 The base version of the MOBIKE protocol does not cover all potential 177 future use scenarios, such as transport mode, application to securing 178 SCTP, or optimizations desirable in specific circumstances. Future 179 extensions may be defined later to support additional requirements. 180 Please consult the MOBIKE design document [Design] for further 181 information and rationale behind these limitations. 183 1.3. Terminology and Notation 185 When messages containing IKEv2 payloads are described, optional 186 payloads are shown in brackets (for instance, "[FOO]"), and a plus 187 sign indicates that a payload can be repeated one or more times (for 188 instance, "FOO+"). To provide context, some diagrams also show what 189 existing IKEv2 payloads would typically be included in the exchanges. 190 These payloads are shown for illustrative purposes only; see [IKEv2] 191 for an authoritative description. 193 When this document talks about updating the source/destination 194 addresses of an IPsec SA, it means updating IPsec-related state so 195 that outgoing ESP/AH packets use those addresses in the tunnel 196 header. Depending on how the nominal division between Security 197 Association Database (SAD), Security Policy Database (SPD), and Peer 198 Authorization Database (PAD) described in [IPsecArch] is actually 199 implemented, an implementation can have several different places that 200 have to be updated. 202 In this document, the term "initiator" means the party who originally 203 initiated the first IKE_SA (in a series of possibly several rekeyed 204 IKE_SAs); "responder" is the other peer. During the lifetime of the 205 IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA 206 exchanges; in this case, the terms "exchange initiator" and "exchange 207 responder" are used. The term "original initiator" (which in [IKEv2] 208 refers to the party who started the latest IKE_SA rekeying) is not 209 used in this document. 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [KEYWORDS]. 215 2. Protocol Overview 217 2.1. Basic Operation 219 MOBIKE allows both parties to have several addresses, and there are 220 up to N*M pairs of IP addresses that could potentially be used. The 221 decision of which of these pairs to use has to take into account 222 several factors. First, the parties may have preferences about which 223 interface should be used due to, for instance, performance and cost 224 reasons. Second, the decision is constrained by the fact that some 225 of the pairs may not work at all due to incompatible IP versions, 226 outages in the network, problems at the local link at either end, and 227 so on. 229 MOBIKE solves this problem by taking a simple approach: the party 230 that initiated the IKE_SA (the "client" in a remote access VPN 231 scenario) is responsible for deciding which address pair is used for 232 the IPsec SAs and for collecting the information it needs to make 233 this decision (such as determining which address pairs work or do not 234 work). The other party (the "gateway" in a remote access VPN 235 scenario) simply tells the initiator what addresses it has but does 236 not update the IPsec SAs until it receives a message from the 237 initiator to do so. This approach applies to the addresses in the 238 IPsec SAs; in the IKE_SA case, the exchange initiator can decide 239 which addresses are used. 241 Making the decision at the initiator is consistent with how normal 242 IKEv2 works: the initiator decides which addresses it uses when 243 contacting the responder. It also makes sense, especially when the 244 initiator is a mobile node: it is in a better position to decide 245 which of its network interfaces should be used for both upstream and 246 downstream traffic. 248 The details of exactly how the initiator makes the decision, what 249 information is used in making it, how the information is collected, 250 how preferences affect the decision, and when a decision needs to be 251 changed are largely beyond the scope of MOBIKE. This does not mean 252 that these details are unimportant: on the contrary, they are likely 253 to be crucial in any real system. However, MOBIKE is concerned with 254 these details only to the extent that they are visible in IKEv2/IPsec 255 messages exchanged between the peers (and thus need to be 256 standardized to ensure interoperability). 258 Many of these issues are not specific to MOBIKE, but are common with 259 the use of existing hosts in dynamic environments or with mobility 260 protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms 261 already exist or are being developed to deal with these issues. For 262 instance, link layer and IP layer mechanisms can be used to track the 263 status of connectivity within the local link [RFC2461]; movement 264 detection is being specified for both IPv4 and IPv6 in [DNA4], 265 [DNA6], and so on. 267 Naturally, updating the addresses of IPsec SAs has to take into 268 account several security considerations. MOBIKE includes two 269 features designed to address these considerations. First, a "return 270 routability" check can be used to verify the addresses provided by 271 the peer. This makes it more difficult to flood third parties with 272 large amounts of traffic. Second, a "NAT prohibition" feature 273 ensures that IP addresses have not been modified by NATs, IPv4/IPv6 274 translation agents, or other similar devices. This feature is 275 enabled only when NAT Traversal is not used. 277 2.2. Example Protocol Exchanges 279 A simple MOBIKE exchange in a mobile scenario is illustrated below. 280 The notation is based on [IKEv2] Section 1.2. In addition, the 281 source/destination IP addresses and ports are shown for each packet: 282 here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by 283 the initiator and the responder. 285 Initiator Responder 286 ----------- ----------- 287 1) (IP_I1:500 -> IP_R1:500) 288 HDR, SAi1, KEi, Ni, 289 N(NAT_DETECTION_SOURCE_IP), 290 N(NAT_DETECTION_DESTINATION_IP) --> 292 <-- (IP_R1:500 -> IP_I1:500) 293 HDR, SAr1, KEr, Nr, 294 N(NAT_DETECTION_SOURCE_IP), 295 N(NAT_DETECTION_DESTINATION_IP) 297 2) (IP_I1:4500 -> IP_R1:4500) 298 HDR, SK { IDi, CERT, AUTH, 299 CP(CFG_REQUEST), 300 SAi2, TSi, TSr, 301 N(MOBIKE_SUPPORTED) } --> 303 <-- (IP_R1:4500 -> IP_I1:4500) 304 HDR, SK { IDr, CERT, AUTH, 305 CP(CFG_REPLY), 306 SAr2, TSi, TSr, 307 N(MOBIKE_SUPPORTED) } 309 (Initiator gets information from lower layers that its attachment 310 point and address have changed.) 312 3) (IP_I2:4500 -> IP_R1:4500) 313 HDR, SK { N(UPDATE_SA_ADDRESSES), 314 N(NAT_DETECTION_SOURCE_IP), 315 N(NAT_DETECTION_DESTINATION_IP) } --> 317 <-- (IP_R1:4500 -> IP_I2:4500) 318 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 319 N(NAT_DETECTION_DESTINATION_IP) } 321 (Responder verifies that the initiator has given it 322 a correct IP address.) 324 4) <-- (IP_R1:4500 -> IP_I2:4500) 325 HDR, SK { N(COOKIE2) } 327 (IP_I2:4500 -> IP_R1:4500) 328 HDR, SK { N(COOKIE2) } --> 330 Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform 331 each other that they support MOBIKE. In step 3, the initiator 332 notices a change in its own address, and informs the responder about 333 this by sending an INFORMATIONAL request containing the 334 UPDATE_SA_ADDRESSES notification. The request is sent using the new 335 IP address. At this point, it also starts to use the new address as 336 a source address in its own outgoing ESP traffic. Upon receiving the 337 UPDATE_SA_ADDRESSES notification the responder records the new 338 address, and if so required by policy, performs a return routability 339 check of the address. When this check (step 4) completes, the 340 responder starts to use the new address as the destination for its 341 outgoing ESP traffic. 343 Another protocol run in a multihoming scenario is illustrated below. 344 In this scenario, the initiator has one address but the responder has 345 two. 347 Initiator Responder 348 ----------- ----------- 349 1) (IP_I1:500 -> IP_R1:500) 350 HDR, SAi1, KEi, Ni, 351 N(NAT_DETECTION_SOURCE_IP), 352 N(NAT_DETECTION_DESTINATION_IP) --> 354 <-- (IP_R1:500 -> IP_I1:500) 355 HDR, SAr1, KEr, Nr, 356 N(NAT_DETECTION_SOURCE_IP), 357 N(NAT_DETECTION_DESTINATION_IP) 359 2) (IP_I1:4500 -> IP_R1:4500) 360 HDR, SK { IDi, CERT, AUTH, 361 CP(CFG_REQUEST), 362 SAi2, TSi, TSr, 363 N(MOBIKE_SUPPORTED) } --> 365 <-- (IP_R1:4500 -> IP_I1:4500) 366 HDR, SK { IDr, CERT, AUTH, 367 CP(CFG_REPLY), 368 SAr2, TSi, TSr, 369 N(MOBIKE_SUPPORTED), 370 N(ADDITIONAL_IP4_ADDRESS) } 372 (The initiator suspects a problem in the currently used address pair, 373 and probes its liveness.) 374 3) (IP_I1:4500 -> IP_R1:4500) 375 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 376 N(NAT_DETECTION_DESTINATION_IP) } --> 378 (IP_I1:4500 -> IP_R1:4500) 379 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 380 N(NAT_DETECTION_DESTINATION_IP) } --> 382 ... 384 (Eventually, the initiator gives up on the current address pair, and 385 tests the other available address pair.) 387 4) (IP_I1:4500 -> IP_R2:4500) 388 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 389 N(NAT_DETECTION_DESTINATION_IP) } 391 <-- (IP_R2:4500 -> IP_I1:4500) 392 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 393 N(NAT_DETECTION_DESTINATION_IP) } 395 (This worked, and the initiator requests the peer to switch to new 396 addresses.) 398 5) (IP_I1:4500 -> IP_R2:4500) 399 HDR, SK { N(UPDATE_SA_ADDRESSES), 400 N(NAT_DETECTION_SOURCE_IP), 401 N(NAT_DETECTION_DESTINATION_IP), 402 N(COOKIE2) } --> 404 <-- (IP_R2:4500 -> IP_I1:4500) 405 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 406 N(NAT_DETECTION_DESTINATION_IP), 407 N(COOKIE2) } 409 2.3. MOBIKE and Network Address Translation (NAT) 411 In some MOBIKE scenarios the network may contain NATs or stateful 412 packet filters (for brevity, the rest of this document talks simply 413 about NATs). The NAT Traversal feature specified in [IKEv2] allows 414 IKEv2 to work through NATs in many cases, and MOBIKE can leverage 415 this functionality: when the addresses used for IPsec SAs are 416 changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed. 418 Nevertheless, there are some limitations because NATs usually 419 introduce an asymmetry in the network: only packets coming from the 420 "inside" cause state to be created. This asymmetry leads to 421 restrictions on what MOBIKE can do. To give a concrete example, 422 consider a situation where both peers have only a single address, and 423 the initiator is behind a NAT. If the responder's address now 424 changes, it needs to send a packet to the initiator using its new 425 address. However, if the NAT is, for instance, of the common 426 "restricted cone" type (see [STUN] for one description of different 427 NAT types), this is not possible: the NAT will drop packets sent from 428 the new address (unless the initiator has previously sent a packet to 429 that address -- which it cannot do until it knows the address). 431 For simplicity, MOBIKE does not attempt to handle all possible NAT- 432 related scenarios. Instead, MOBIKE assumes that if NATs are present, 433 the initiator is the party "behind" the NAT, and does not fully 434 support the case where the responder's addresses change, meaning that 435 no special effort is made to support this functionality. Responders 436 may also be unaware of NATs or specific types of NATs they are 437 behind. However, when a change has occurred that will cause a loss 438 of connectivity, MOBIKE responders will still attempt to inform the 439 initiator of the change. Depending on, for instance, the exact type 440 of NAT, it may or may not succeed. However, analyzing the exact 441 circumstances when this will or will not work is not done in this 442 document. 444 3. Protocol Exchanges 446 3.1. Initial IKE Exchange 448 The initiator is responsible for finding a working pair of addresses 449 so that the initial IKE exchange can be carried out. Any information 450 from MOBIKE extensions will only be available later, when the 451 exchange has progressed far enough. Exactly how the addresses used 452 for the initial exchange are discovered is beyond the scope of this 453 specification; typical sources of information include local 454 configuration and DNS. 456 If either or both of the peers have multiple addresses, some 457 combinations may not work. Thus, the initiator SHOULD try various 458 source and destination address combinations when retransmitting the 459 IKE_SA_INIT request. 461 3.2. Signaling Support for MOBIKE 463 Implementations that wish to use MOBIKE for a particular IKE_SA MUST 464 include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in 465 case of multiple IKE_AUTH exchanges, in the message containing the SA 466 payload). 468 The format of the MOBIKE_SUPPORTED notification is described in 469 Section 4. 471 3.3. Initial Tunnel Header Addresses 473 When an IPsec SA is created, the tunnel header IP addresses (and 474 port, if doing UDP encapsulation) are taken from the IKE_SA, not the 475 IP header of the IKEv2 message requesting the IPsec SA. The 476 addresses in the IKE_SA are initialized from the IP header of the 477 first IKE_AUTH request. 479 The addresses are taken from the IKE_AUTH request because IKEv2 480 requires changing from port 500 to 4500 if a NAT is discovered. To 481 simplify things, implementations that support both this specification 482 and NAT Traversal MUST change to port 4500 if the correspondent also 483 supports both, even if no NAT was detected between them (this way, 484 there is no need to change the ports later if a a NAT is detected on 485 some other path). 487 3.4. Additional Addresses 489 Both the initiator and responder MAY include one or more 490 ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in 491 the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the 492 message containing the SA payload). Here "ADDITIONAL_*_ADDRESS" 493 means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS 494 notification. 496 Initiator Responder 497 ----------- ----------- 498 HDR, SK { IDi, [CERT], [IDr], AUTH, 499 [CP(CFG_REQUEST)] 500 SAi2, TSi, TSr, 501 N(MOBIKE_SUPPORTED), 502 [N(ADDITIONAL_*_ADDRESS)+] } --> 504 <-- HDR, SK { IDr, [CERT], AUTH, 505 [CP(CFG_REPLY)], 506 SAr2, TSi, TSr, 507 N(MOBIKE_SUPPORTED) 508 [N(ADDITIONAL_*_ADDRESS)+] } 510 The recipient stores this information, but no other action is taken 511 at this time. 513 Although both the initiator and responder maintain a set of peer 514 addresses (logically associated with the IKE_SA), it is important to 515 note that they use this information for slightly different purposes. 517 The initiator uses the set of responder addresses as an input to its 518 address selection policy; it may, at some later point, decide to move 519 the IPsec traffic to one of these addresses using the procedure 520 described in Section 3.5. The responder normally does not use the 521 set of initiator addresses for anything: the addresses are used only 522 when the responder's own addresses change (see Section 3.6). 524 The set of addresses available to the peers can change during the 525 lifetime of the IKE_SA. The procedure for updating this information 526 is described in Section 3.6. 528 Note that if some of the initiator's interfaces are behind a NAT 529 (from the responder's point of view), the addresses received by the 530 responder will be incorrect. This means the procedure for changing 531 responder addresses described in Section 3.6 does not fully work when 532 the initiator is behind a NAT. For the same reason, the peers also 533 SHOULD NOT use this information for any other purpose than what is 534 explicitly described either in this document or a future 535 specification updating it. 537 3.5. Changing Addresses in IPsec SAs 539 In MOBIKE, the initiator decides what addresses are used in the IPsec 540 SAs. That is, the responder does not normally update any IPsec SAs 541 without receiving an explicit UPDATE_SA_ADDRESSES request from the 542 initiator. (As described below, the responder can, however, update 543 the IKE_SA in some circumstances.) 545 The reasons why the initiator wishes to change the addresses are 546 largely beyond the scope of MOBIKE. Typically, triggers include 547 information received from lower layers, such as changes in IP 548 addresses or link-down indications. Some of this information can be 549 unreliable: for instance, ICMP messages could be spoofed by an 550 attacker. Unreliable information SHOULD be treated only as a hint 551 that there might be a problem, and the initiator SHOULD trigger dead 552 peer detection (that is, send an INFORMATIONAL request) to determine 553 if the current path is still usable. 555 Changing addresses can also be triggered by events within IKEv2. At 556 least the following events can cause the initiator to re-evaluate its 557 local address selection policy, possibly leading to changing the 558 addresses. 560 o An IKEv2 request has been re-transmitted several times, but no 561 valid reply has been received. This suggests the current path is 562 no longer working. 564 o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS, 565 ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is 566 received. This means the peer's addresses may have changed. This 567 is particularly important if the announced set of address no 568 longer contains the currently used address. 570 o An UNACCEPTABLE_ADDRESSES notification is received as a response 571 to address update request (described below). 573 o The initiator receives a NAT_DETECTION_DESTINATION_IP notification 574 that does not match the previous UPDATE_SA_ADDRESSES response (see 575 Section 3.8 for a more detailed description). 577 The description in the rest of this section assumes that the 578 initiator has already decided what the new addresses should be. When 579 this decision has been made, the initiator: 581 o Updates the IKE_SA with the new addresses, and sets the 582 "pending_update" flag in the IKE_SA. 584 o Updates the IPsec SAs associated with this IKE_SA with the new 585 addresses (unless the initiator's policy requires a return 586 routability check before updating the IPsec SAs, and the check has 587 not been done for this responder address yet). 589 o If the IPsec SAs were updated in the previous step: If NAT 590 Traversal is not enabled, and the responder supports NAT Traversal 591 (as indicated by NAT detection payloads in the IKE_SA_INIT 592 exchange), and the initiator either suspects or knows that a NAT 593 is likely to be present, enables NAT Traversal (that is, enables 594 UDP encapsulation of outgoing ESP packets and sending of NAT- 595 Keepalive packets). 597 o If there are outstanding IKEv2 requests (requests for which the 598 initiator has not yet received a reply), continues retransmitting 599 them using the addresses in the IKE_SA (the new addresses). 601 o When the window size allows, sends an INFORMATIONAL request 602 containing the UPDATE_SA_ADDRESSES notification (which does not 603 contain any data), and clears the "pending_update" flag. The 604 request will be as follows: 606 Initiator Responder 607 ----------- ----------- 608 HDR, SK { N(UPDATE_SA_ADDRESSES), 609 [N(NAT_DETECTION_SOURCE_IP), 610 N(NAT_DETECTION_DESTINATION_IP)], 611 [N(NO_NATS_ALLOWED)], 613 [N(COOKIE2)] } --> 615 o If a new address change occurs while waiting for the response, 616 starts again from the first step (and ignores responses to this 617 UPDATE_SA_ADDRESSES request). 619 When processing an INFORMATIONAL request containing the 620 UPDATE_SA_ADDRESSES notification, the responder: 622 o Determines whether it has already received a newer 623 UPDATE_SA_ADDRESSES request than this one (if the responder uses a 624 window size greater than one, it is possible that requests are 625 received out of order). If it has, a normal response message 626 (described below) is sent, but no other action is taken. 628 o If the NO_NATS_ALLOWED notification is present, processes it as 629 described in Section 3.9. 631 o Checks that the (source IP address, destination IP address) pair 632 in the IP header is acceptable according to local policy. If it 633 is not, replies with a message containing the 634 UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). 636 o Updates the IP addresses in the IKE_SA with the values from the IP 637 header. (Using the address from the IP header is consistent with 638 normal IKEv2, and allows IKEv2 to work with NATs without needing 639 unilateral self-address fixing [UNSAF].) 641 o Replies with an INFORMATIONAL response: 643 Initiator Responder 644 ----------- ----------- 645 <-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP), 646 N(NAT_DETECTION_DESTINATION_IP)], 647 [N(COOKIE2)] } 649 o If necessary, initiates a return routability check for the new 650 initiator address (see Section 3.7) and waits until the check is 651 completed. 653 o Updates the IPsec SAs associated with this IKE_SA with the new 654 addresses. 656 o If NAT Traversal is supported and NAT detection payloads were 657 included, enables or disables NAT Traversal. 659 When the initiator receives the reply: 661 o If an address change has occurred after the request was first 662 sent, no MOBIKE processing is done for the reply message because a 663 new UPDATE_SA_ADDRESSES is going to be sent (or has already been 664 sent, if window size greater than one is in use). 666 o If the response contains the UNEXPECTED_NAT_DETECTED notification, 667 it processes the response as described in Section 3.9. 669 o If the response contains an UNACCEPTABLE_ADDRESSES notification, 670 the initiator MAY select another addresses and retry the exchange, 671 keep on using the previously used addresses, or disconnect. 673 o It updates the IPsec SAs associated with this IKE_SA with the new 674 addresses (unless this was already done earlier before sending the 675 request; this is the case when no return routability check was 676 required). 678 o If NAT Traversal is supported and NAT detection payloads were 679 included, it enables or disables NAT Traversal. 681 There is one exception to the rule that the responder never updates 682 any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If 683 the source address that the responder is currently using becomes 684 unavailable (i.e., sending packets using that source address is no 685 longer possible), the responder is allowed to update the IPsec SAs to 686 use some other address (in addition to initiating the procedure 687 described in the next section). 689 3.6. Updating Additional Addresses 691 As described in Section 3.4, both the initiator and responder can 692 send a list of additional addresses in the IKE_AUTH exchange. This 693 information can be updated by sending an INFORMATIONAL exchange 694 request message that contains either one or more 695 ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the 696 NO_ADDITIONAL_ADDRESSES notification. 698 If the exchange initiator has only a single IP address, it is placed 699 in the IP header, and the message contains the 700 NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has 701 several addresses, one of them is placed in the IP header, and the 702 rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications. 703 The new list of addresses replaces the old information (in other 704 words, there are no separate add/delete operations; instead, the 705 complete list is sent every time these notifications are used). 707 The message exchange will look as follows: 709 Initiator Responder 710 ----------- ----------- 711 HDR, SK { [N(ADDITIONAL_*_ADDRESS)+], 712 [N(NO_ADDITIONAL_ADDRESSES)], 713 [N(NO_NATS_ALLOWED)], 714 [N(COOKIE2)] } --> 716 <-- HDR, SK { [N(COOKIE2)] } 718 When a request containing an ADDITIONAL_IP4_ADDRESS, 719 ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is 720 received, the exchange responder: 722 o Determines whether it has already received a newer request to 723 update the addresses (if a window size greater than one is used, 724 it is possible that the requests are received out of order). If 725 it has, a response message is sent, but the address set is not 726 updated. 728 o If the NO_NATS_ALLOWED notification is present, processes it as 729 described in Section 3.9. 731 o Updates the set of peer addresses based on the IP header and the 732 ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS and 733 NO_ADDITIONAL_ADDRESSES notifications. 735 o Sends a response. 737 The initiator MAY include these notifications in the same request as 738 UPDATE_SA_ADDRESSES. 740 If the request to update the addresses is retransmitted using several 741 different source addresses, a new INFORMATIONAL request MUST be sent. 743 There is one additional complication: when the responder wants to 744 update the address set, the currently used addresses may no longer 745 work. In this case, the responder uses the additional address list 746 received from the initiator, and the list of its own addresses, to 747 determine which addresses to use for sending the INFORMATIONAL 748 request. This is the only time the responder uses the additional 749 address list received from the initiator. 751 Note that both peers can have their own policies about what addresses 752 are acceptable to use, and certain types of policies may simplify 753 implementation. For instance, if the responder has a single fixed 754 address, it does not need to process the ADDITIONAL_IP4_ADDRESS and 755 ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring 756 unrecognized status notifications as already required in [IKEv2]). 758 Furthermore, if the initiator has a policy saying that only the 759 responder address specified in local configuration is acceptable, it 760 does not have to send its own additional addresses to the responder 761 (since the responder does not need them except when changing its own 762 address). 764 3.7. Return Routability Check 766 Both parties can optionally verify that the other party can actually 767 receive packets at the claimed address. By default, this "return 768 routability check" SHOULD be performed. In environments where the 769 peer is expected to be well-behaved (many corporate VPNs, for 770 instance), or the address can be verified by some other means (e.g., 771 a certificate issued by an authority trusted for this purpose), the 772 return routability check MAY be omitted. 774 The check can be done before updating the IPsec SAs, immediately 775 after updating them, or continuously during the connection. By 776 default, the return routability check SHOULD be done before updating 777 the IPsec SAs, but in some environments it MAY be postponed until 778 after the IPsec SAs have been updated. 780 Any INFORMATIONAL exchange can be used for return routability 781 purposes, with one exception (described later in this section): when 782 a valid response is received, we know the other party can receive 783 packets at the claimed address. 785 To ensure that the peer cannot generate the correct INFORMATIONAL 786 response without seeing the request, a new payload is added to 787 INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY 788 include a COOKIE2 notification, and if included, the recipient of an 789 INFORMATIONAL request MUST copy the notification as-is to the 790 response. When processing the response, the original sender MUST 791 verify that the value is the same one as sent. If the values do not 792 match, the IKE_SA MUST be closed. (See also Section 4.2.5 for the 793 format of the COOKIE2 notification.) 795 The exception mentioned earlier is as follows: If the same 796 INFORMATIONAL request has been sent to several different addresses 797 (i.e., the destination address in the IKE_SA has been updated after 798 the request was first sent), receiving the INFORMATIONAL response 799 does not tell which address is the working one. In this case, a new 800 INFORMATIONAL request needs to be sent to check return routability. 802 3.8. Changes in NAT Mappings 804 IKEv2 performs Dead Peer Detection (DPD) if there has recently been 805 only outgoing traffic on all of the SAs associated with the IKE_SA. 807 In MOBIKE, these messages can also be used to detect if NAT mappings 808 have changed (for example, if the keepalive interval is too long, or 809 the NAT box is rebooted). More specifically, if both peers support 810 both this specification and NAT Traversal, the 811 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 812 notifications MAY be included in any INFORMATIONAL request; if the 813 request includes them, the responder MUST also include them in the 814 response (but no other action is taken, unless otherwise specified). 816 When the initiator is behind a NAT (as detected earlier using the 817 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 818 notifications), it SHOULD include these notifications in DPD 819 messages, and compare the received NAT_DETECTION_DESTINATION_IP 820 notifications with the value from the previous UPDATE_SA_ADDRESSES 821 response (or the IKE_SA_INIT response). If the values do not match, 822 the IP address and/or port seen by the responder has changed, and the 823 initiator SHOULD send UPDATE_SA_ADDRESSES as described in 824 Section 3.5. If the initiator suspects that the NAT mapping has 825 changed, it MAY also skip the detection step and send 826 UPDATE_SA_ADDRESSES immediately. This saves one roundtrip if the NAT 827 mapping has indeed changed. 829 Note that this approach to detecting NAT mapping changes may cause an 830 extra address update when the IKE_SA is rekeyed. This is because the 831 NAT_DETECTION_DESTINATION_IP hash also includes the IKE SPIs, which 832 change when performing rekeying. This unnecessary update is 833 harmless, however. 835 When MOBIKE is in use, the dynamic updates specified in [IKEv2] 836 Section 2.23 (where the peer address and port are updated from the 837 last valid authenticated packet) work in a slightly different 838 fashion. The host not behind a NAT MUST NOT use these dynamic 839 updates for IKEv2 packets, but MAY use them for ESP packets. This 840 ensures that an INFORMATIONAL exchange that does not contain 841 UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be 842 used for, e.g., testing whether a particular path works. 844 3.9. NAT Prohibition 846 Basic IKEv2/IPsec without NAT Traversal support may work across some 847 types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in 848 tunnel mode. This is because the IKEv2 integrity checksum does not 849 cover the addresses in the IP header. This may be considered a 850 problem in some circumstances, because in some sense any modification 851 of the IP addresses can be considered an attack. 853 This specification addresses the issue by protecting the IP addresses 854 when NAT Traversal has not been explicitly enabled. This means that 855 MOBIKE without NAT Traversal support will not work if the paths 856 contain NATs, IPv4/IPv6 translation agents, or other nodes that 857 modify the addresses in the IP header. This feature is mainly 858 intended for IPv6 and site-to-site VPN cases, where the 859 administrators may know beforehand that NATs are not present, and 860 thus any modification to the packet can be considered an attack. 862 More specifically, when NAT Traversal is not enabled, all messages 863 that can update the addresses associated with the IKE_SA and/or IPsec 864 SAs (the first IKE_AUTH request and all INFORMATIONAL requests that 865 contain any of the following notifications: UPDATE_SA_ADDRESSES, 866 ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, 867 NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED 868 notification. The exchange responder MUST verify that the contents 869 of the NO_NATS_ALLOWED notification match the addresses in the IP 870 header. If they do not match, a response containing an 871 UNEXPECTED_NAT_DETECTED notification is sent. The response message 872 is sent to the address and port that the corresponding request came 873 from, not to the address contained in the NO_NATS_ALLOWED 874 notification. 876 If the exchange initiator receives an UNEXPECTED_NAT_DETECTED 877 notification in response to its INFORMATIONAL request, it SHOULD 878 retry the operation several times using new INFORMATIONAL requests. 879 Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the 880 IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several 881 times, starting from a new IKE_SA_INIT request. This ensures that an 882 attacker who is able to modify only a single packet does not 883 unnecessarily cause a path to remain unused. The exact number of 884 retries is not specified in this document because it does not affect 885 interoperability. However, because the IKE message will also be 886 rejected if the attacker modifies the integrity checksum field, a 887 reasonable number here would be the number of retries that is being 888 used for normal retransmissions. 890 If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange 891 responder MUST NOT use the contents of the NO_NATS_ALLOWED 892 notification for any other purpose than possibly logging the 893 information for troubleshooting purposes. 895 3.10. Path Testing 897 IKEv2 Dead Peer Detection allows the peers to detect if the currently 898 used path has stopped working. However, if either of the peers has 899 several addresses, Dead Peer Detection alone does not tell which of 900 the other paths might work. 902 If required by its address selection policy, the initiator can use 903 normal IKEv2 INFORMATIONAL request/response messages to test whether 904 a certain path works. Implementations MAY do path testing even if 905 the path currently being used is working to, for example, detect when 906 a better (but previously unavailable) path becomes available. 908 3.11. Failure Recovery and Timeouts 910 In MOBIKE, the initiator is responsible for detecting and recovering 911 from most failures. 913 To give the initiator enough time to detect the error, the responder 914 SHOULD use relatively long timeout intervals when, for instance, 915 retransmitting IKEv2 requests or deciding whether to initiate dead 916 peer detection. While no specific timeout lengths are required, it 917 is suggested that responders continue retransmitting IKEv2 requests 918 for at least five minutes before giving up. 920 3.12. Dead Peer Detection 922 MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but 923 as addresses may change, it is not sufficient to just verify that the 924 peer is alive, but also that it is synchronized with the address 925 updates and has not, for instance, ignored an address update due to 926 failure to complete return routability test. This means that when 927 there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the 928 addresses used in those packets and determine that they correspond to 929 those that should be employed. If they do not, such packets SHOULD 930 NOT be used as evidence that the peer is able to communicate with 931 this node and or that the peer has received all address updates. 933 4. Payload Formats 935 This specification defines several new IKEv2 Notify payload types. 936 See [IKEv2] Section 3.10 for a general description of the Notify 937 payload. 939 4.1. Notify Messages - Error Types 941 4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload 943 The responder can include this notification in an INFORMATIONAL 944 exchange response to indicate that the address change in the 945 corresponding request message (which contained an UPDATE_SA_ADDRESSES 946 notification) was not carried out. 948 The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA6. 949 The Protocol ID and SPI Size fields are set to zero. There is no 950 data associated with this Notify type. 952 4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload 954 See Section 3.9 for a description of this notification. 956 The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9. 957 The Protocol ID and SPI Size fields are set to zero. There is no 958 data associated with this Notify type. 960 4.2. Notify Messages - Status Types 962 4.2.1. MOBIKE_SUPPORTED Notify Payload 964 The MOBIKE_SUPPORTED notification is included in the IKE_AUTH 965 exchange to indicate that the implementation supports this 966 specification. 968 The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The 969 Protocol ID and SPI Size fields are set to zero. The notification 970 data field MUST be left empty (zero-length) when sending, and its 971 contents (if any) MUST be ignored when this notification is received. 972 This allows the field to be used by future versions of this protocol. 974 4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify 975 Payloads 977 Both parties can include ADDITIONAL_IP4_ADDRESS and/or 978 ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and 979 INFORMATIONAL exchange request messages; see Section 3.4 and 980 Section 3.6 for more detailed description. 982 The Notify Message Types for ADDITIONAL_IP4_ADDRESS and 983 ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA2 and TBD-BY-IANA3, 984 respectively. The Protocol ID and SPI Size fields are set to zero. 985 The data associated with these Notify types is either a four-octet 986 IPv4 address or a 16-octet IPv6 address. 988 4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload 990 The NO_ADDITIONAL_ADDRESSES notification can be included in an 991 INFORMATIONAL exchange request message to indicate that the exchange 992 initiator does not have addresses beyond the one used in the exchange 993 (see Section 3.6 for more detailed description). 995 The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-IANA4. 996 The Protocol ID and SPI Size fields are set to zero. There is no 997 data associated with this Notify type. 999 4.2.4. UPDATE_SA_ADDRESSES Notify Payload 1001 This notification is included in INFORMATIONAL exchange requests sent 1002 by the initiator to update addresses of the IKE_SA and IPsec SAs (see 1003 Section 3.5). 1005 The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA5. The 1006 Protocol ID and SPI Size fields are set to zero. There is no data 1007 associated with this Notify type. 1009 4.2.5. COOKIE2 Notify Payload 1011 This notification MAY be included in any INFORMATIONAL request for 1012 return routability check purposes (see Section 3.7). If the 1013 INFORMATIONAL request includes COOKIE2, the exchange responder MUST 1014 copy the notification to the response message. 1016 The data associated with this notification MUST be between 8 and 64 1017 octets in length (inclusive), and MUST be chosen by the exchange 1018 initiator in a way that is unpredictable to the exchange responder. 1019 The Notify Message Type for this message is TBD-BY-IANA7. The 1020 Protocol ID and SPI Size fields are set to zero. 1022 4.2.6. NO_NATS_ALLOWED Notify Payload 1024 See Section 3.9 for a description of this notification. 1026 The Notify Message Type for this message is TBD-BY-IANA8. The 1027 notification data contains the IP addresses and ports from/to which 1028 the packet was sent. For IPv4, the notification data is 12 octets 1029 long and is defined as 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 ! Source IPv4 address ! 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 ! Destination IPv4 address ! 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 ! Source port ! Destination port ! 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 For IPv6, the notification data is 36 octets long and is defined as 1042 follows: 1044 1 2 3 1045 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 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 ! ! 1048 ! Source IPv6 address ! 1049 ! ! 1050 ! ! 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 ! ! 1053 ! Destination IPv6 address ! 1054 ! ! 1055 ! ! 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 ! Source port ! Destination port ! 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 The Protocol ID and SPI Size fields are set to zero. 1062 5. Security Considerations 1064 The main goals of this specification are to maintain the security 1065 offered by usual IKEv2 procedures and to counter mobility-related 1066 threats in an appropriate manner. This section describes new 1067 security considerations introduced by MOBIKE. See [IKEv2] for 1068 security considerations for IKEv2 in general. 1070 5.1. Traffic Redirection and Hijacking 1072 MOBIKE payloads relating to updating addresses are encrypted, 1073 integrity protected, and replay protected using the IKE_SA. This 1074 assures that no one except the participants can, for instance, give a 1075 control message to change the addresses. 1077 However, as with normal IKEv2, the actual IP addresses in the IP 1078 header are not covered by the integrity protection. This means that 1079 a NAT between the parties (or an attacker acting as a NAT) can modify 1080 the addresses and cause incorrect tunnel header (outer) IP addresses 1081 to be used for IPsec SAs. The scope of this attack is limited mainly 1082 to denial-of-service because all traffic is protected using IPsec. 1084 This attack can only be launched by on-path attackers that are 1085 capable of modifying IKEv2 messages carrying NAT detection payloads 1086 (such as Dead Peer Detection messages). By modifying the IP header 1087 of these packets, the attackers can lead the peers to believe a new 1088 NAT or a changed NAT binding exists between them. The attack can 1089 continue as long as the attacker is on the path, modifying the IKEv2 1090 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms 1091 designed to detect NAT mapping changes will eventually recognize that 1092 the intended traffic is not getting through, and will update the 1093 addresses appropriately. 1095 MOBIKE introduces the NO_NATS_ALLOWED notification that is used to 1096 detect modification, by outsiders, of the addresses in the IP header. 1097 When this notification is used, communication through NATs and other 1098 address translators is impossible, so it is sent only when not doing 1099 NAT Traversal. This feature is mainly intended for IPv6 and site-to- 1100 site VPN cases, where the administrators may know beforehand that 1101 NATs are not present. 1103 5.2. IPsec Payload Protection 1105 The use of IPsec protection on payload traffic protects the 1106 participants against disclosure of the contents of the traffic, 1107 should the traffic end up in an incorrect destination or be subject 1108 to eavesdropping. 1110 However, security associations originally created for the protection 1111 of a specific flow between specific addresses may be updated by 1112 MOBIKE later on. This has to be taken into account if the (outer) IP 1113 address of the peer was used when deciding what kind of IPsec SAs the 1114 peer is allowed to create. 1116 For instance, the level of required protection might depend on the 1117 current location of the VPN client, or access might be allowed only 1118 from certain IP addresses. 1120 It is recommended that security policies, for peers that are allowed 1121 to use MOBIKE, are configured in a manner that takes into account 1122 that a single security association can be used at different times 1123 through paths of varying security properties. 1125 This is especially critical for traffic selector authorization. The 1126 (logical) Peer Authorization Database (PAD) contains the information 1127 used by IKEv2 when determining what kind of IPsec SAs a peer is 1128 allowed to create. This process is described in [IPsecArch] Section 1129 4.4.3. When a peer requests the creation of an IPsec SA with some 1130 traffic selectors, the PAD must contain "Child SA Authorization Data" 1131 linking the identity authenticated by IKEv2 and the addresses 1132 permitted for traffic selectors. See also [Clarifications] for a 1133 more extensive discussion. 1135 It is important to note that simply sending IKEv2 packets using some 1136 particular address does not automatically imply a permission to 1137 create IPsec SAs with that address in the traffic selectors. 1138 However, some implementations are known to use policies where simply 1139 being reachable at some address X implies a temporary permission to 1140 create IPsec SAs for address X. Here "being reachable" usually means 1141 the ability to send (or spoof) IP packets with source address X and 1142 receive (or eavesdrop) packets sent to X. 1144 Using this kind of policies or extensions with MOBIKE may need 1145 special care to enforce the temporary nature of the permission. For 1146 example, when the peer moves to some other address Y (and is no 1147 longer reachable at X), it might be necessary to close IPsec SAs with 1148 traffic selectors matching X. However, these interactions are beyond 1149 the scope of this document. 1151 5.3. Denial-of-Service Attacks Against Third Parties 1153 Traffic redirection may be performed not just to gain access to the 1154 traffic or to deny service to the peers, but also to cause a denial- 1155 of-service attack for a third party. For instance, a high-speed TCP 1156 session or a multimedia stream may be redirected towards a victim 1157 host, causing its communications capabilities to suffer. 1159 The attackers in this threat can be either outsiders or even one of 1160 the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers 1161 can be easily dealt with if the authentication performed in the 1162 initial IKEv2 negotiation can be traced to persons who can be held 1163 responsible for the attack. This may not be the case in all 1164 scenarios, particularly with opportunistic approaches to security. 1166 If the attack is launched by an outsider, the traffic flow would 1167 normally stop soon due to the lack of responses (such as transport 1168 layer acknowledgements). However, if the original recipient of the 1169 flow is malicious, it could maintain the traffic flow for an extended 1170 period of time, since it often would be able to send the required 1171 acknowledgements (see [Aura02] for more discussion). 1173 It should also be noted, as shown in [Bombing], that without ingress 1174 filtering in the attacker's network, such attacks are already 1175 possible simply by sending spoofed packets from the attacker to the 1176 victim directly. Furthermore, if the attacker's network has ingress 1177 filtering, this attack is largely prevented for MOBIKE as well. 1178 Consequently, it makes little sense to protect against attacks of 1179 similar nature in MOBIKE. However, it still makes sense to limit the 1180 amplification capabilities provided to attackers, so that they cannot 1181 use stream redirection to send a large number of packets to the 1182 victim by sending just a few packets themselves. 1184 This specification includes return routability tests to limit the 1185 duration of any "third party bombing" attacks by off-path (relative 1186 to the victim) attackers. The tests are authenticated messages that 1187 the peer has to respond to, and can be performed either before the 1188 address change takes effect, immediately afterwards, or even 1189 periodically during the session. The tests contain unpredictable 1190 data, and only someone who has the keys associated with the IKE SA 1191 and has seen the request packet can properly respond to the test. 1193 The duration of the attack can also be limited if the victim reports 1194 the unwanted traffic to the originating IPsec tunnel endpoint using 1195 ICMP error messages or INVALID_SPI notifications. As described in 1196 [IKEv2] Section 2.21, this SHOULD trigger a liveness test, which also 1197 doubles as a return routability check if the COOKIE2 notification is 1198 included. 1200 5.4. Spoofing Network Connectivity Indications 1202 Attackers may spoof various indications from lower layers and the 1203 network in an effort to confuse the peers about which addresses are 1204 or are not working. For example, attackers may spoof link-layer 1205 error messages in an effort to cause the parties to move their 1206 traffic elsewhere or even to disconnect. Attackers may also spoof 1207 information related to network attachments, router discovery, and 1208 address assignments in an effort to make the parties believe they 1209 have Internet connectivity when, in reality, they do not. 1211 This may cause use of non-preferred addresses or even denial-of- 1212 service. 1214 MOBIKE does not provide any protection of its own for indications 1215 from other parts of the protocol stack. These vulnerabilities can be 1216 mitigated through the use of techniques specific to the other parts 1217 of the stack, such as validation of ICMP errors [ICMPAttacks], link 1218 layer security, or the use of [SEND] to protect IPv6 Router and 1219 Neighbor Discovery. 1221 Ultimately, MOBIKE depends on the delivery of IKEv2 messages to 1222 determine which paths can be used. If IKEv2 messages sent using a 1223 particular source and destination addresses reach the recipient and a 1224 reply is received, MOBIKE will usually consider the path working; if 1225 no reply is received even after retransmissions, MOBIKE will suspect 1226 the path is broken. An attacker who can consistently control the 1227 delivery or non-delivery of the IKEv2 messages in the network can 1228 thus influence which addresses actually get used. 1230 5.5. Address and Topology Disclosure 1232 MOBIKE address updates and the ADDITIONAL_IP4_ADDRESS/ 1233 ADDITIONAL_IP6_ADDRESS notifications reveal information about which 1234 networks the peers are connected to. 1236 For example, consider a host A with two network interfaces: a 1237 cellular connection and a wired Ethernet connection to a company LAN. 1238 If host A now contacts host B using IKEv2 and sends 1239 ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications, host B 1240 receives additional information it might not otherwise know. If host 1241 A used the cellular connection for the IKEv2 traffic, host B can also 1242 see the company LAN address (and perhaps further guess that host A is 1243 used by an employee of that company). If host A used the company LAN 1244 to make the connection, host B can see that host A has a subscription 1245 from this particular cellular operator. 1247 These additional addresses can also disclose more accurate location 1248 information than just a single address. Suppose that host A uses its 1249 cellular connection for IKEv2 traffic, but also sends an 1250 ADDITIONAL_IP4_ADDRESS notification containing an IP address 1251 corresponding to, say, a wireless LAN at a particular coffee shop 1252 location. It is likely that host B can now make a much better guess 1253 at A's location than would be possible based on the cellular IP 1254 address alone. 1256 Furthermore, as described in Section 3.4, some of the addresses could 1257 also be private addresses behind a NAT. 1259 In many environments, disclosing address information is not a problem 1260 (and indeed it cannot be avoided if the hosts wish to use those 1261 addresses for IPsec traffic). For instance, a remote access VPN 1262 client could consider the corporate VPN gateway sufficiently 1263 trustworthy for this purpose. Furthermore, the 1264 ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are 1265 sent encrypted, so the addresses are not visible to eavesdroppers 1266 (unless, of course, they are later used for sending IKEv2/IPsec 1267 traffic). 1269 However, if MOBIKE is used in some more opportunistic approach, it 1270 can be desirable to limit the information that is sent. Naturally, 1271 the peers do not have to disclose any addresses they do not want to 1272 use for IPsec traffic. Also, as noted in Section 3.6, an initiator 1273 whose policy is to always use the locally configured responder 1274 address does not have to send any ADDITIONAL_IP4_ADDRESS/ 1275 ADDITIONAL_IP6_ADDRESS payloads. 1277 6. IANA Considerations 1279 This document does not create any new namespaces to be maintained by 1280 IANA, but it requires new values in namespaces that have been defined 1281 in the IKEv2 base specification [IKEv2]. 1283 This document defines several new IKEv2 notifications whose values 1284 are to be allocated from the "IKEv2 Notify Message Types" namespace. 1286 Notify Messages - Error Types Value 1287 ----------------------------- ----- 1288 UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) 1289 UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) 1291 Notify Messages - Status Types Value 1292 ------------------------------ ----- 1293 MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) 1294 ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) 1295 ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) 1296 NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) 1297 UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) 1298 COOKIE2 TBD-BY-IANA7 (16396..40959) 1299 NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) 1301 These notifications are described in Section 4. 1303 7. Acknowledgements 1305 This document is a collaborative effort of the entire MOBIKE WG. We 1306 would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo 1307 Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti, 1308 Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann, 1309 Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld, 1310 Maureen Stillman, Shinta Sugimoto, Sami Vaarala, and Hannes 1311 Tschofenig. This document also incorporates ideas and text from 1312 earlier MOBIKE-like protocol proposals, including [AddrMgmt], 1313 [Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design document 1314 [Design]. 1316 8. References 1318 8.1. Normative References 1320 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1321 RFC 4306, December 2005. 1323 [IPsecArch] 1324 Kent, S. and K. Seo, "Security Architecture for the 1325 Internet Protocol", RFC 4301, December 2005. 1327 [KEYWORDS] 1328 Bradner, S., "Key words for use in RFCs to Indicate 1329 Requirement Levels", RFC 2119, March 1997. 1331 8.2. Informative References 1333 [AddrMgmt] 1334 Dupont, F., "Address Management for IKE version 2", 1335 draft-dupont-ikev2-addrmgmt-08 (work in progress), 1336 November 2005. 1338 [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 1339 Location Management", Proc. 18th Annual Computer Security 1340 Applications Conference (ACSAC), December 2002. 1342 [Bombing] Dupont, F., "A note about 3rd party bombing in Mobile 1343 IPv6", draft-dupont-mipv6-3bombing-03 (work in progress), 1344 December 2005. 1346 [Clarifications] 1347 Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 1348 Implementation Guidelines", 1349 draft-eronen-ipsec-ikev2-clarifications-07 (work in 1350 progress), February 2006. 1352 [DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1353 Network Attachment (DNA) in IPv4", 1354 draft-ietf-dhc-dna-ipv4-18 (work in progress), 1355 December 2005. 1357 [DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting 1358 Network Attachment in IPv6 - Best Current Practices for 1359 hosts", draft-ietf-dna-hosts-02 (work in progress), 1360 October 2005. 1362 [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE 1363 protocol", draft-ietf-mobike-design-07 (work in progress), 1364 January 2006. 1366 [ICMPAttacks] 1367 Gont, F., "ICMP attacks against TCP", 1368 draft-gont-tcpm-icmp-attacks-05 (work in progress), 1369 October 2005. 1371 [Kivinen] Kivinen, T., "MOBIKE protocol", 1372 draft-kivinen-mobike-protocol-00 (work in progress), 1373 February 2004. 1375 [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1376 August 2002. 1378 [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1379 in IPv6", RFC 3775, June 2004. 1381 [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO- 1382 IKE)", draft-eronen-mobike-mopo-02 (work in progress), 1383 February 2005. 1385 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1386 Discovery for IP Version 6 (IPv6)", RFC 2461, 1387 December 1998. 1389 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1390 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1392 [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and 1393 Multihoming Extensions for IKEv2 (SMOBIKE)", 1394 draft-eronen-mobike-simple-00 (work in progress), 1395 March 2004. 1397 [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1398 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1399 Through Network Address Translators (NATs)", RFC 3489, 1400 March 2003. 1402 [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- 1403 Address Fixing (UNSAF) Across Network Address 1404 Translation", RFC 3424, November 2002. 1406 Appendix A. Implementation Considerations 1408 A.1. Links from SPD Cache to Outbound SAD Entries 1410 [IPsecArch] Section 4.4.2 says that "For outbound processing, each 1411 SAD entry is pointed to by entries in the SPD-S part of the SPD 1412 cache". The document does not specify how exactly this "pointing" is 1413 done, since this is an implementation detail that does not have to be 1414 standardized. 1416 However, it is clear that the links between the SPD cache and the SAD 1417 have to be done correctly to ensure that outbound packets are sent 1418 over the right SA. Some implementations are known to have problems 1419 in this area. 1421 In particular, simply storing the (remote tunnel header IP address, 1422 remote SPI) pair in the SPD cache is not sufficient, since the pair 1423 does not always uniquely identify a single SAD entry. For instance, 1424 two hosts behind the same NAT can accidentally happen to choose the 1425 same SPI value. The situation can also occur when a host is assigned 1426 an IP address previously used by some other host, and the SAs 1427 associated with the old host have not yet been deleted by dead peer 1428 detection. This may lead to packets being sent over the wrong SA or, 1429 if the key management daemon ensures the pair is unique, denying the 1430 creation of otherwise valid SAs. 1432 Storing the remote tunnel header IP address in the SPD cache may also 1433 complicate the implementation of MOBIKE, since the address can change 1434 during the lifetime of the SA. Thus, we recommend implementing the 1435 links between the SPD cache and the SAD in a way that does not 1436 require modification when the tunnel header IP address is updated by 1437 MOBIKE. 1439 A.2. Creating Outbound SAs 1441 When an outbound packet requires IPsec processing but no suitable SA 1442 exists, a new SA will be created. In this case, the host has to 1443 determine (1) who is the right peer for this SA, (2) whether the host 1444 already has an IKE_SA with this peer, and (3) if no IKE_SA exists, 1445 the IP address(es) of the peer for contacting it. 1447 Neither [IPsecArch] nor MOBIKE specifies how exactly these three 1448 steps are carried out. [IPsecArch] Section 4.4.3.4 says: 1450 For example, assume that IKE A receives an outbound packet 1451 destined for IP address X, a host served by a security gateway. 1452 RFC 2401 [RFC2401] and this document do not specify how A 1453 determines the address of the IKE peer serving X. However, any 1454 peer contacted by A as the presumed representative for X must be 1455 registered in the PAD in order to allow the IKE exchange to be 1456 authenticated. Moreover, when the authenticated peer asserts that 1457 it represents X in its traffic selector exchange, the PAD will be 1458 consulted to determine if the peer in question is authorized to 1459 represent X. 1461 In step 1, there may be more than one possible peer (e.g., several 1462 security gateways that are allowed to represent X). In step 3, the 1463 host may need to consult a directory such as DNS to determine the 1464 peer IP address(es). 1466 When performing these steps, implementations may use information 1467 contained in the SPD, the PAD, and possibly some other 1468 implementation-specific databases. Regardless of how exactly the 1469 steps are implemented, it is important to remember that IP addresses 1470 can change, and that an IP address alone does not always uniquely 1471 identify a single IKE peer (for the same reasons as why the 1472 combination of the remote IP address and SPI does not uniquely 1473 identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 1474 and 2 it may be easier to identify the "right peer" using its 1475 authenticated identity instead of its current IP address. However, 1476 these implementation details are beyond the scope of this 1477 specification. 1479 Appendix B. Changelog 1481 (This section should be removed by the RFC editor.) 1483 Changes from -07 to -08: 1485 o Clarified meaning of ADDITIONAL_*_ADDRESS and other notations. 1487 o Clarified number of retries and UNEXPECTED_NAT_DETECTED. 1489 o Added text about traffic selector authorization to security 1490 considerations. 1492 o Updated quotations to match RFC 4301. 1494 o Updated acknowledgements and references. 1496 o Small editorial fixes for IESG evaluation and IETF last call. 1498 Changes from -06 to -07: 1500 o Editorial fixes from AD evaluation. 1502 Changes from -06.a to -06: 1504 o Clarified text about certificates and omitting RR (issue 54). 1506 o Take initial addresses from IKE_AUTH even when not doing NAT-T 1507 (issue 60). 1509 o Added text about dead peer detection (issue 71). 1511 o Fixed port numbers in examples (issue 73). 1513 o Updated acknowledgements list and references. 1515 Changes from -05 to -06.a: 1517 o Clarified third-party DoS security considerations (issue 45). 1519 o Clarified the use of ADDITIONAL_*_ADDRESS/NO_ADDITIONAL_ADDRESSES 1520 notifications and deleting addresses (issues 46 and 58). 1522 o Better separation of error and status types (issue 59). 1524 o Changed order of fields in NO_NATS_ALLOWED and provided a bit 1525 diagram (issue 59). 1527 o Added implementation considerations appendix (issues 51 and 70). 1529 o Editorial fixes and clarifications (issues 54, 56, 59, 64, 72). 1531 Changes from -04 to -05: 1533 o Editorial fixes and clarifications (issue 44, 47, 48, 49, 50, 53, 1534 62, 66, 67, 68, 69). 1536 o Ignore data in MOBIKE_SUPPORTED (issue 61). 1538 Changes from -03 to -04: 1540 o Copy-editing done by the RFC editor. 1542 Changes from -02 to -03: 1544 o Editorial fixes and clarifications (issues 42 and 43). 1546 o Clarified IANA considerations (issue 42). 1548 o Added security considerations about address and topology 1549 disclosure (issue 42). 1551 o Added a suggestion about retransmission timeout (issue 42). 1553 o Change dynamic address updates: MUST NOT do them based on IKEv2 1554 packets, MAY do based on ESP (issue 34). 1556 o Mandate NAT prohibition if not doing NAT traversal (issue 41). 1558 o Clarified security considerations related to NATs (issue 41). 1560 o Don't use SHA-1 in NO_NATS_ALLOWED, just send the addresses (issue 1561 42). 1563 o Added a short section about path testing. 1565 o Added an example protocol run in Section 1. 1567 Changes from -01 to -02: 1569 o Moved MOBIKE_SUPPORTED from IKE_SA_INIT to IKE_AUTH (issues 35, 1570 37). 1572 o Changed terminology related to NAT prohibition (issues 22, 24). 1574 o Rewrote much of the ADDITIONAL_*_ADDRESS text, added 1575 NO_ADDITIONAL_ADDRESSES notification. 1577 o Use NAT detection payloads to detect changes in NAT mappings 1578 (issue 34). 1580 o Removed separate PATH_TEST message (issue 34). 1582 o Clarified processing of UNACCEPTABLE_ADDRESSES when request has 1583 been sent using several different addresses (issue 36). 1585 o Clarified changing of ports 500/4500 (issue 33). 1587 o Updated security considerations (issues 27 and 28). 1589 o No need to include COOKIE2 in non-RR messages (issue 32). 1591 o Many editorial fixes and clarifications (issue 38, 40). 1593 o Use the terms initiator and responder more consistently. 1595 o Clarified that this document does not solve all problems in MOBIKE 1596 WG charter (issue 40). 1598 Changes from -00 to -01: 1600 o Editorial fixes and small clarifications (issues 21, 25, 26, 29). 1602 o Use Protocol ID zero for notifications (issue 30). 1604 o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue 1605 23). 1607 o Use the word "path" only in senses that include the route taken 1608 (issue 29). 1610 Author's Address 1612 Pasi Eronen (editor) 1613 Nokia Research Center 1614 P.O. Box 407 1615 FIN-00045 Nokia Group 1616 Finland 1618 Email: pasi.eronen@nokia.com 1620 Intellectual Property Statement 1622 The IETF takes no position regarding the validity or scope of any 1623 Intellectual Property Rights or other rights that might be claimed to 1624 pertain to the implementation or use of the technology described in 1625 this document or the extent to which any license under such rights 1626 might or might not be available; nor does it represent that it has 1627 made any independent effort to identify any such rights. Information 1628 on the procedures with respect to rights in RFC documents can be 1629 found in BCP 78 and BCP 79. 1631 Copies of IPR disclosures made to the IETF Secretariat and any 1632 assurances of licenses to be made available, or the result of an 1633 attempt made to obtain a general license or permission for the use of 1634 such proprietary rights by implementers or users of this 1635 specification can be obtained from the IETF on-line IPR repository at 1636 http://www.ietf.org/ipr. 1638 The IETF invites any interested party to bring to its attention any 1639 copyrights, patents or patent applications, or other proprietary 1640 rights that may cover technology that may be required to implement 1641 this standard. Please address the information to the IETF at 1642 ietf-ipr@ietf.org. 1644 Disclaimer of Validity 1646 This document and the information contained herein are provided on an 1647 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1648 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1649 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1650 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1651 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1652 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1654 Copyright Statement 1656 Copyright (C) The Internet Society (2006). This document is subject 1657 to the rights, licenses and restrictions contained in BCP 78, and 1658 except as set forth therein, the authors retain all their rights. 1660 Acknowledgment 1662 Funding for the RFC Editor function is currently provided by the 1663 Internet Society.