idnits 2.17.1 draft-mglt-ipsec-mm-mobikex-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.mglt-ipsec-mm-requirements], [RFC4555]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1846 has weird spacing: '...itiator sends...' -- The document date (September 2009) is 5335 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) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME Working Group D. Migault 3 Internet-Draft Orange Labs R&D 4 Intended status: Standards Track September 2009 5 Expires: March 5, 2010 7 MOBIKE eXtension (MOBIKE-X) for Transport Mobility and Multihomed IKE_SA 8 draft-mglt-ipsec-mm-mobikex-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 5, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This draft provides a description of MOBIKE mobility and multihoming 47 extension (MOBIKE-X). The extension is elaborated from the MOBIKE 48 [RFC4555] protocol as well as mobility and multihoming requirements 49 described in [I-D.mglt-ipsec-mm-requirements]. Extension concerns 50 the Security Association facilities in a multihoming and mobile 51 environment. More specifically this draft considers the use of 52 multiple interfaces and the transport mode of IPsec. One of the goal 53 of this draft was to make this extension compatible with MOBIKE 54 [RFC4555]. We especially point out the differences from MOBIKE 55 [RFC4555], as well as how its interacts with MOBIKE. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. MOBIKE-X Protocol overview . . . . . . . . . . . . . . . . . . 8 64 5.1. UPDATE action . . . . . . . . . . . . . . . . . . . . . . 8 65 5.2. ADD and REMOVE actions . . . . . . . . . . . . . . . . . . 9 66 5.3. Response to a CHECK Request . . . . . . . . . . . . . . . 10 67 5.4. SELECTing the SA . . . . . . . . . . . . . . . . . . . . . 10 68 5.5. Alternate IP Address . . . . . . . . . . . . . . . . . . . 10 69 5.6. MOBIKE Version . . . . . . . . . . . . . . . . . . . . . . 11 70 5.7. Other Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. Notify Payload Description . . . . . . . . . . . . . . . . . . 12 72 6.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 12 73 6.2. MOBIKE_UNSUPPORTED_VERSION Notify Payload . . . . . . . . 12 74 6.3. SELECTOR Notify Payload . . . . . . . . . . . . . . . . . 13 75 6.4. END_OF_SELECTOR Notify Payload . . . . . . . . . . . . . . 13 76 6.5. ADDITIONAL_IP_ADDRESS Notify Payload . . . . . . . . . . . 13 77 6.6. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 14 78 6.7. ADD_SA_ADDRESS Notify Payload . . . . . . . . . . . . . . 15 79 6.8. REMOVE_SA_ADDRESS Notify Payload . . . . . . . . . . . . . 16 80 7. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 17 81 7.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . . 17 82 7.1.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . 17 83 7.1.2. MOBIKE_UNSUPPORTED_VERSION Notify Payload . . . . . . 21 84 7.1.3. Initial exchange state diagrams . . . . . . . . . . . 21 85 7.2. Alternate IP Address Exchange . . . . . . . . . . . . . . 26 86 7.3. Alternate IP Address Exchange State Diagram . . . . . . . 27 87 7.4. UPDATE Exchange . . . . . . . . . . . . . . . . . . . . . 29 88 7.5. UPDATE Exchange State Diagram . . . . . . . . . . . . . . 32 89 7.6. Multihoming Exchanges . . . . . . . . . . . . . . . . . . 36 90 7.7. Multihoming Exchanges State Diagrams . . . . . . . . . . . 37 91 8. SELECTOR Notify Payload . . . . . . . . . . . . . . . . . . . 39 92 9. SELECTOR State diagrams . . . . . . . . . . . . . . . . . . . 42 93 10. ID Notify Payload Parameter . . . . . . . . . . . . . . . . . 45 94 11. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 45 95 11.1. Notify Payload . . . . . . . . . . . . . . . . . . . . . . 45 96 11.2. Notify Message -- status type . . . . . . . . . . . . . . 46 97 11.2.1. MOBIKE_SUPPORTED . . . . . . . . . . . . . . . . . . . 46 98 11.2.2. ADDITIONAL_IP_ADDRESS . . . . . . . . . . . . . . . . 46 99 11.2.3. NO_ADDITIONAL_ADDRESS . . . . . . . . . . . . . . . . 47 100 11.2.4. SELECTOR . . . . . . . . . . . . . . . . . . . . . . . 47 101 11.2.5. END_OF_SELECTOR . . . . . . . . . . . . . . . . . . . 47 102 11.2.6. UPDATE_SA_ADDRESSES . . . . . . . . . . . . . . . . . 47 103 11.2.7. ADD_SA_ADDRESS Notify Payload . . . . . . . . . . . . 47 104 11.2.8. REMOVE_SA_ADDRESS Notify Payload . . . . . . . . . . . 47 105 11.2.9. Notify Message -- status type table . . . . . . . . . 47 106 11.3. Notify Message -- error type . . . . . . . . . . . . . . . 48 107 11.3.1. MOBIKE_UNSUPPORTED_VERSION . . . . . . . . . . . . . . 48 108 11.3.2. UNACCEPTABLE_ADDRESS . . . . . . . . . . . . . . . . . 48 109 11.3.3. DOES_NOT_FIT_SPD . . . . . . . . . . . . . . . . . . . 48 110 11.3.4. UNACCEPTABLE_PARAMETERS . . . . . . . . . . . . . . . 48 111 11.3.5. UNEXPECTED_PAYLOAD_AFTER_SELECTOR . . . . . . . . . . 49 112 11.3.6. UNMATCHED_SELECTOR_SET . . . . . . . . . . . . . . . . 49 113 11.3.7. Notify Message -- error type table . . . . . . . . . . 49 114 11.4. Notify Parameters . . . . . . . . . . . . . . . . . . . . 49 115 11.4.1. VERSION . . . . . . . . . . . . . . . . . . . . . . . 49 116 11.4.2. SPI . . . . . . . . . . . . . . . . . . . . . . . . . 50 117 11.4.3. IP . . . . . . . . . . . . . . . . . . . . . . . . . . 51 118 11.4.4. Multihoming Information Payload (MIP) . . . . . . . . 52 119 11.4.5. IPSEC_MODE . . . . . . . . . . . . . . . . . . . . . . 54 120 11.4.6. IPSEC_PROTO . . . . . . . . . . . . . . . . . . . . . 54 121 11.4.7. SELECTOR_SPECIFIC_VALUE_PARAMETER . . . . . . . . . . 55 122 11.4.8. ID . . . . . . . . . . . . . . . . . . . . . . . . . . 56 123 11.4.9. Parameter Code Type . . . . . . . . . . . . . . . . . 56 124 12. Security Considerations . . . . . . . . . . . . . . . . . . . 57 125 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 126 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 127 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 128 15.1. Normative References . . . . . . . . . . . . . . . . . . . 59 129 15.2. Informative References . . . . . . . . . . . . . . . . . . 59 130 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 59 132 1. Requirements notation 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. Terminology 140 - Mobile Node (MN) : In this draft the Mobile Node is the peer that 141 performs the mobility action. The Mobile Node does not have to 142 be understood as in MIPv6. 143 - Initiator : The Initiator is the peer that initiates the 144 exchange. It sends a message to the Responder. It is 145 important to note that if two peers are connected, the 146 Initiator of one exchange can be the Responder of another 147 exchange. When a mobility action is performed then the 148 Initiator is also the Mobile Node. 149 - Responder : The Responder is the peer receiving a message. The 150 message is sent from the Initiator. 151 - Alternate IP Address : The alternate IP address of a peer is the 152 IP address a peer is not currently using but that might be used 153 latter. An alternate IP address should used only if the 154 current IP address does not work anymore. 156 3. Introduction 158 This document provides a description of MOBIKE-X. We assume the 159 reader is familiar with IPsec [RFC4301], IKEv2 [RFC4306] and with 160 MOBIKE [RFC4555]. 162 MOBIKE-X extends MOBIKE facilities to change the IP address of an 163 IPsec Security Associations. More specifically, MOBIKE-X includes an 164 IPsec Security Association using a transport mode. MOBIKE-X also 165 extends the multihoming scope of MOBIKE, and considers that 166 simultaneous IP addresses can be used between two peers. Combination 167 of mobility and multihoming facilities provide IP address management 168 facilities. This draft is mainly focused on the multihoming aspects 169 of the IKEv2 channel. This draft does not provide any use cases. 170 Use cases are described in [I-D.mglt-ipsec-mm-requirements]. This 171 draft considers scenarios and requirements of [I-D.mglt-ipsec-mm- 172 requirements]. From theses requirements, this document defines 173 extensions to MOBIKE which includes new Notify Payloads, and 174 parameters carried by Notify Payloads. 176 MOBIKE [RFC4555] proposes a mobility solution for the tunnel mode. 177 MOBIKE use case is a mobile node connected to an Intranet through a 178 security gateway. For simplicity we consider that the security 179 gateway is connected on the Internet and on a private network. The 180 mobile node negotiates a connection with the security gateway using 181 IKEv2. After the IKEv2 negotiation, the mobile node has a private IP 182 address, and communicates with nodes on the Intranet by tunneling 183 them to the security gateway. The outer IP addresses of the tunnel 184 are the public IP addresses of the security gateway and of the mobile 185 node. MOBIKE has been designed so that the mobile node can change 186 its public IP address without breaking the Security Association 187 between the inner IP addresses, negotiated with IKEv2. In other 188 words, when the mobile node changes its public IP address MOBIKE 189 avoids that the mobile node restarts a IKEv2 negotiation with the 190 security gateway, proceeding to the IKE_SA_INIT, IKE_AUTH and 191 CREATE_CHILD_SA exchanges. 193 With the tunnel mode the selectors of the SPD and the SAD are the 194 inner IP addresses. When outer addresses are changed, only some 195 parameters of the SA are changed. More specifically, selectors of a 196 given SA are kept unchanged during mobility. No new SA needs to be 197 created and so SPD and PAD and their bindings with the SAD are kept 198 unchanged. On the other hand, with the transport mode, the selectors 199 of the SA are changed. When one host changes its IP address, and the 200 SA is identified through its selectors, it MUST be changed. As a 201 consequence, the SPD MUST also be changed, and the PAD MUST be 202 checked to see if new SA can be created. 204 MOBIKE considers that peer only has one interface. This brings 205 simplification over what modification has to be done, and where the 206 updates need to be performed. In fact if a node decides to perform a 207 mobility action and has only one interface, then the other peer knows 208 the new address is one being used by the Mobile Node, and the old IP 209 address is the one that the MN used to use. If a peer is multihomed, 210 the MN should be able to indicate what is the new IP address, and 211 what is the old IP address -- that is to say the IP address to be 212 replaced. 214 MOBIKE also considers multihoming. The type of multihoming MOBIKE 215 considers is the Alternate IP Addresses Multihoming (AM). This means 216 that one peer can provide multiple IP addresses to the other peer, 217 but those IP addresses MUST NOT be used unless the current IP address 218 is not working anymore. In other words, MOBIKE do not consider the 219 Simultaneous IP Addresses Multihoming (SM) that would enable IKEv2 to 220 use simultaneously multiple IP addresses. 222 Furthermore, one should also notice that multihoming facilities 223 provided by MOBIKE are ONLY intended for the IKEv2 application. This 224 means that the Alternate IP Addresses provided by on peer are only 225 intended to be used by IKEv2. In other words, other applications 226 than IKEv2 are not using the Alternate IP Addresses. 228 We do not see in this draft much reasons to enable Simultaneous IP 229 Addresses Multihoming (SM) for IKEv2 as an application. On the other 230 hand we consider that Simultaneous IP Addresses Multihoming (SM) 231 facilities can be provided by IKEv2 so that other application can 232 benefit from it. More precisely, the IPsec layer of one peer MUST be 233 able to inform the other peer IPsec layer that Simultaneous IP 234 Addresses can be used on a given Security Association. Simultaneous 235 IP Addresses Multihoming consists of ADDing or REMOVing one or more 236 IP addresses to a specific Security Association. Such IPsec 237 modifications are necessary to protect and allow the traffic of an 238 application. At least they can avoid IKEv2 negotiation, and multiple 239 IPsec contexts. 241 Until now we assume that IKEv2 provides messages that only concerns 242 the IPsec parameters. This of course respects the layered model. On 243 the other hand we can also think of interaction between Upper Layer 244 Protocols (ULP). One way is to consider that ULP exchanges provide 245 the IPsec Security Association configuration. The other way 246 considers that such exchanges SHOULD be protected and IPsec is a good 247 way to protect data. Thus rather then using a specific channel 248 negotiated by IKEv2, we can use directly the IKEv2 channel. 249 Furthermore this way would provide a generic multihomed and mobility 250 related information that could be re-used by different ULP. So this 251 way considers that multihoming and mobility information sent via the 252 IKEv2 channel, are used by the IPsec layer to update / modify the 253 Security Association, but are also forwarded to the ULP so that they 254 could consider there own mobility and multihoming action on their own 255 layer. The advantage of such strategy is to avoid multiple 256 exchanges. 258 With ULP-IKEv2 interaction considerations, one can consider the use 259 of the Alternate IP Addresses not for the IKEv2 application, but also 260 for other applications. This means that when an Alternate IP Address 261 is associated to a given Security Association, IKEv2 forwards this 262 information to the ULP. That is the purpose of the ULP to decide how 263 and when to use this Alternate IP Address. When the ULP considers 264 that the current IP address is not working anymore and that an 265 Alternate IP address could be used, then it asks IKEv2 to eventually 266 perform Return Routability check and to either perform a mobility or 267 multihoming action. If a multihoming action is decided, then the IP 268 address is ADDed to a given Security Association. If a mobility 269 action is decided, then the Security Association is UPDATEd. 271 In this draft, we do not consider how the ULP SHOULD proceed. We do 272 not either consider how the mobility or multihoming information are 273 transmitted to the ULP if they are. This draft only consider the 274 IKEv2 exchange between the two peers. We mention here possible 275 interactions between ULP and IKEv2 to justify that Multihoming 276 Information can be associated to the IP addresses. 278 4. Requirements 280 From the previous section as well as from the [ID.mglt-ipsec-mm- 281 requirements], the requirements for MOBIKE-X can be split into three 282 categories : the requirements on the Security Association other than 283 the IKE_SA, the requirements on the IKE_SA and the requirements on 284 the protocol. 286 Requirements on the Security Associations other than the IKE_SA are 287 listed below : 289 1 : Mobility and Multihoming MUST be done with IPsec in transport 290 and in tunnel mode. 291 2 : The Initiator MUST be able to perform an UPDATE, ADD or REMOVE 292 action on a Security Association, that is to say, change the IP 293 address associated to the SA. 294 3 : For Mobility and Multihoming actions -- i.e. UPDATE, REMOVE or 295 ADD action -- the Initiator MUST be able to check if the action 296 is possible on the Responder side. 297 4 : Mobility and Multihoming actions, -- i.e. UPDATE, REMOVE or 298 ADD -- action can explicitly specify which IP address is to be 299 ADDed, REMOVEd, UPADTEd, and which IP address MUST replaced. 300 5 : When the Responder is requested to check a Mobility or 301 Multihoming action, it MUST respond relevant information if the 302 action can be performed and if not why the action cannot be 303 performed. 304 6 : The Initiator MUST be able to SELECT the SA on which the action 305 applies. 306 7 : The Initiator MUST be able to provide Alternate IP Addresses 307 associated to specific SA. 309 Requirements on the IKE_SA are listed below : 311 8 : The Initiator can send an Alternate IP Address to the IKEv2 312 application 313 9 : The Initiator MUST be able to explicitly specify on which 314 IKE_SA the action applies to. 316 Requirements regarding MOBIKE-X are listed bellow : 318 10 : The extension MUST be as close as possible to MOBIKE. This 319 means that MOBIKE-X MUST take MOBIKE as a base, and make the 320 coding extension as light as possible. This include re-use of 321 Notify Payloads defined in MOBIKE, as well as the same 322 "philosophy". 323 11 : The exchange messages MUST be as low and short as possible. 324 This means that omitted parameters have default values so that 325 they do not need to be specified. 326 12 : Peers MUST be able to agree if the MOBIKE version used is 327 MOBIKE-X or MOBIKE. 329 5. MOBIKE-X Protocol overview 331 5.1. UPDATE action 333 MOBIKE considers that only one IP address can be used at a time. 334 This has the advantage of removing the ambiguity about which IP 335 address is to be used. In fact the mobile node has established a 336 communication with the security gateway using OLD_IP. The MN is 337 identified by its ID, has established an IKE_SA to secure IKE 338 transactions. When the mobile node has a new IP address NEW_IP, it 339 sends to the security gateway an UPDATE_SA_ADDRESSES Notify Payload. 340 There is no need to specify which IP address is to be changed. When 341 receiving an UPDATE_SA_ADDRESSES Notify Payload, the security gateway 342 identifies the concerned IKE_SA, and the concerned CHILD_SA(s). The 343 IP address that is to be replaced (OLD_IP) is the outer tunnel IP 344 address of the CHILD_SA(s), and the IP address of the IKE_SA 345 associated to the host. The new value (NEW_IP) to be placed is the 346 IP address used to carry the UPDATE_SA_ADDRESSES Notify Payload and 347 located in the IP header. Update of the SAD might requires some 348 checks, such as checking return routability. 350 With MOBIKE-X we do not consider the Mobile Node uses only one IP 351 address at a time. We do not make any assumption on how the Mobile 352 Node is managing its IP addresses. This means that we do not use the 353 IP layer to find out values needed for the update. MOBIKE-X provides 354 the ability to fully specify into its UPDATE_SA_ADDRESSES Notify 355 Payload the IP address to be replaced (OLD_IP) and the new value of 356 the IP address (NEW_IP). MOBIKE-X uses the IP parameters that are 357 put into the data field of the UPDATE_SA_ADDRESSES Notify Payload. 358 The difference with MOBIKE is that the data field MAY be not empty. 359 The IP parameter may carries certain information associated to the IP 360 address. More specifically, the Initiator MUST specify if the IP 361 address is an OLD_IP, a NEW_IP, and information on whether the 362 Initiator wants the UPDATE to occurs now or if it want only to check 363 the UPDATE would match local policies and IPsec Security Policies 364 (CHECK). As far as UPDATE action is concerned, it fulfills 365 requirements 1, 2, 3 and 4. 367 Note that the OLD_IP and NEW_IP parameters does not have to be always 368 specified. If none of those parameters are specified, the 369 UPDATE_SA_ADDRESSES is performed in a similar manner as in MOBIKE 370 way. In this case, the Responder updates the IP addresses used to 371 route packet to/from the Initiator. More specifically, this includes 372 the outer IP addresses in IPsec tunnel mode, the IP address of 373 transport mode, and the IP address of the IKE_SA. The replacing IP 374 address is the IP address the Initiator use in the IP header of the 375 IKEv2 message. The replacement occurs on the SA and IKE_SA specified 376 by the SELECTORs Notify Payload. This is coherent with MOBIKE 377 specification. The default values for the SELECTOR Notify Payload is 378 CHILD_SA_AND_IKE_SA. If the Initiator has a single interface and 379 uses the tunnel mode the outer IP address of the tunnel being 380 replaced. The difference with MOBIKE is that transport mode IPsec SA 381 are also going to be UPDATEd. As far as UPDATE action is concerned, 382 it fulfills requirements 10 and 11. 384 5.2. ADD and REMOVE actions 386 MOBIKE does not specify any equivalent actions for ADD or REMOVE 387 actions. MOBIKE specifies an ADDITIONAL_IP_ADDRESS Notify Payload, 388 but its purpose is to specify Alternate IP Addresses. One option 389 would have been to re-use those Notify Payload at least for the ADD 390 operation, and specify in the IP address parameters whether the IP 391 address is an Alternate IP address or not. We decided to have 392 specific Notify Payloads for Alternate IP Addresses since such IP 393 addresses are not "directly" affecting the IPsec Security 394 Associations. More specifically, Alternate IP addresses are either 395 addressed to the IKEv2 application, or can eventually in the future 396 be forwarded to the Upper Layer Protocols. 398 ADD and REMOVE actions need new Notify Payloads ADD_SA_ADDRESS and 399 REMOVE_SA_ADDRESS Notify Payloads. Such Payloads work in a similar 400 manner as the UPDATE_SA_ADDRESSES Notify Payload. The IP address 401 that has to be ADDed or REMOVEd of the SA is specified in an IP 402 parameter. Only one IP parameter needs to be specified. The IP 403 parameter carries some information such as the CHECK bit. The CHECK 404 bit set to 1 specifies the Initiator only wants to check the action 405 matches local and security policies. The IP parameter can also carry 406 multihoming specific information thanks to the Multihoming 407 Information Payload (MIP). Multihoming specific Information are used 408 so that ULP can make their decision on which IP address to choose. 409 In fact there are not expected to be handled by IKEv2. Such 410 information can be the PREFERENCE which indicates how the Initiator 411 prefer this IP address, the CLASS which indicates the nature of the 412 IP address (HoA, CoA, ...), or reachability information. As far as 413 ADD and REMOVE actions are concerned, requirements 1, 2, 3 and 4 are 414 fulfilled. 416 In a similar way as with the UPDATE_SA_ADDRESSES Notify Payload, if 417 no IP parameter is provided in the data field, than the ADD or REMOVE 418 action applies to all CHILD_SA associated to the IKE_SA. The IP 419 address to be ADDed or REMOVEd is the one placed in the IP header. 420 As far as ADD and REMOVE actions are concerned requirements 10 and 11 421 are fulfilled. 423 Note that ADD and REMOVE actions do not applies to the IKE_SA. In 424 this draft we do not consider that the IKEv2 application implements 425 Simultaneous IP Address Multihoming. This is for future development. 427 5.3. Response to a CHECK Request 429 When the Responder receives an UPDATE, ADD or REMOVE action request 430 with the CHECK bit set to 1, then the Responder is expected to 431 provide information on whether the action can be performed, and if 432 not why the action cannot be performed. If the action can be 433 performed the Responder returns a response without any error Notify 434 Payload. If the action cannot be performed because the IP address 435 does not fit local policies, then a UNACCEPTABLE_ADDRESS Notify 436 Payload is sent. If the action cannot be performed because the IP 437 address does not match the SPD, then a DOES_NOT_FIT_SPD Notify 438 Payload. 440 Such Notify Payloads fulfill requirement 5. 442 5.4. SELECTing the SA 444 MOBIKE-X provides a mechanism to explicitly specify which SA or which 445 IKE_SA the action applies to. One or more SELECTOR Notify Payload 446 can be used. If the Initiator does not specifies any SELECTOR, then 447 the default value for the SELECTOR is IKE_SA_AND_CHILD_SA, which 448 means that the action MUST apply to the IKE_SA and all associated 449 CHILD_SA(s). 451 Such mechanism fulfills requirement 9, 10, 11 and 5. 453 5.5. Alternate IP Address 455 MOBIKE defines an ADDITIONAL_IP4_ADDRESS and ADDITIONA_IP6_ADDRESS 456 Notify Payloads so that a peer can advertise the other peer an IP 457 address. This message specifies an Alternate IP Address intended to 458 be used by the IKEv2 application. This means that the implicit 459 selector value is IKE_SA. MOBIKE-X uses this Notify Payload, by 460 considering that the specified IP address can also be associated to a 461 SA. The SAs are specified with the SELECTORs Notify Payloads. In 462 that case, the IKEv2 application is not expected to do anything else 463 than forwarding the information to the Upper Layer Protocols. MOBIKE 464 defines ADDITIONAL_IP*_ADDRESS with the IP address value inside the 465 data field of the Notify Payload. MOBIKE-X re-uses those messages, 466 but fills the data field of the Notify Payload with the IP 467 parameters. 469 Note that the use of two distinct ADDITIONAL_IP*_ADRESS Notify 470 Payload is not anymore necessary, since the type of the IP address is 471 specified with the parameter type. Thus we define in this document 472 the ADDITIONAL_IP_ADDRESS Notify Payload which is an alias for the 473 ADDITIONAL_IP6_ADDRESS. Reasons are that we do not want to have two 474 different Notify Payload for the same action. 476 Such mechanism fulfills requirements 7, 8 and 10. 478 Note that this draft does not specify nor provide mechanisms that 479 either enable one peer to know if the alternate IP address is 480 forwarded to the ULP, or that enables communications between the ULP 481 and the IKEv2 application. In other words, it defines that 482 ADDITIONAL_IP_ADDRESS Notify Payload can be associated to SA, and so 483 SHOULD NOT be rejected by IKEV2 or generate any error message. 485 5.6. MOBIKE Version 487 The protocol described in this draft is not fully compatible with 488 MOBIKE. Furthermore, it provides more functionalities. Peers need 489 to agree on which version of the protocol they understand. In this 490 draft, the two possible protocols are MOBIKE or MOBIKE-X, and the 491 choice is exclusive. Negotiation on the MOBIKE version is agreed by 492 using the MOBIKE_SUPPORT Notify Payload. MOBIKE-X is designated by 493 using a version parameter in the data field. The version value 494 considered for MOBIKE-X is 2. 496 The exchange defined in this draft is expected to support further 497 MOBIKE versions. Thus we defined the MOBIKE_UNSUPPORTED_VERSION 498 Notify Payload. 500 This mechanism fulfill requirements 12. 502 5.7. Other Considerations 504 As defined in MOBIKE, MOBIKE-X considers that Mobility or Multihoming 505 action can only be triggered by the Initiator. 507 MOBIKE deals with NAT, and we would like to take advantage of this 508 work, even though we do not consider NAT in this paper. 510 6. Notify Payload Description 512 6.1. MOBIKE_SUPPORTED Notify Payload 514 This message is described in MOBIKE [RFC4555]. MOBIKE-X uses 515 versions parameters to specify which version is supported by the 516 peer. We consider is this paper the version corresponding to MOBIKE 517 as defined in [RFC4555] as version 1 and the MOBIKE-X version as 518 described in this paper as version 2. A node that implements a 519 MOBIKE-X of version equal or greater than 2 MUST specify the version 520 numbers in its MOBIKE_SUPPORTED Notify Payload. If no version is 521 specified, then the node is assumed to support only MOBIKE of version 522 1. 524 In the IKE_AUTH exchange, the MOBIKE_SUPPORTED Notify Payload is sent 525 by the Initiator. The Initiator sends an MOBIKE_SUPPORTED Notify 526 Payload with the version parameters of the MOBIKE versions it 527 supports. There can be multiple version parameters and the Initiator 528 expects that the Responder will choose one of them. When the 529 Responder receives an MOBIKE_SUPPORTED Notify Payload, and the 530 Responder supports one of the proposed versions, it chooses one of 531 those and indicates the chosen version with the version parameter in 532 the MOBIKE_SUPPORTED Notify Payload sent as a response. If none of 533 the version is supported by the Responder, the Responder MUST send an 534 MOBIKE_UNSUPPORTED_VERSION Notify Payload. 536 - Version : The supported version of MOBIKE-X. MOBIKE-X as defined 537 in this draft is considered as version 2, MOBIKE as specified 538 in [RFC4555] is considered as version 1. 540 At this level of the negotiation both peers have agreed on which 541 MOBIKE version of the protocol they understand. 543 6.2. MOBIKE_UNSUPPORTED_VERSION Notify Payload 545 This Notify Payload is used to indicate that proposed versions by the 546 Initiator are not supported. This message carries the version the 547 Responder supports. If the Initiator also supports this version and 548 has not already proposed it to the Responder, then it can restart the 549 negotiation. 551 This Notify Payload is also used to cancel the use of MOBIKE-X, to go 552 back to the initial state where MOBIKE is not supported by any of the 553 peers. This is mainly to avoid ambiguous situation where one peer 554 understands one thing but not the other. For that purpose, we use a 555 specific version value NONE. The Notify Payload can carry the 556 following options : 558 - Version : The considered version of MOBIKE-X. MOBIKE-X in this 559 draft is considered as version 1. The NONE value is 255. 561 6.3. SELECTOR Notify Payload 563 A SELECTOR Notify Payload contains a list of parameters. A SA 564 matches this SELECTOR payload if it matches all parameters within the 565 SELECTOR Notify Payload. A SELECTOR Notify Payload is always 566 followed either by a SELECTOR, an UPDATE_SA_ADDRESSES, an 567 ADD_SA_ADDRESS, a REMOVE_SA_ADDRESS, or an ADDITIONAL_IP_ADDRESS 568 Notify Payload. Those Notify Payloads are also called the action. 569 When different SELECTOR Notify Payloads are grouped together before 570 an action, we call this group a SELECTOR_SET. An SA matches the 571 SELECTOR_SET when a match occurs with at least one of the SELECTOR 572 payload. The SELECTOR Notify Payload can have the following 573 parameters : 575 - SPI : By specifying the SPI the action applies to. 576 - IP : By specifying the IP address the action applies to. The IP 577 parameter can provide information about the location (inner or 578 outer IP address). 579 - IPSEC_PROTO : By specifying the IPSEC_PROTO the action applies 580 to. 581 - IPSEC_MODE : By specifying the IPSEC_MODE, the applies to. 582 - ID : The Identification Number of the Notify Payload. It is 583 optional. It is recommended to add this option to identify the 584 SELECTOR_SET. When an error occurs, the SELECTOR Notify 585 Payload causing the error can be identified. 587 6.4. END_OF_SELECTOR Notify Payload 589 The END_OF_SELECTOR Notify Payload indicates the SELECTOR_SET do not 590 apply any more to the action that follows this Notify Payload. We do 591 not expect any parameters being carried by this payload. 593 6.5. ADDITIONAL_IP_ADDRESS Notify Payload 595 ADDITIONAL_IP_ADDRESS Notify Payloads carry Alternate IP Addresses. 596 ADDITIONAL_IP_ADDRESS Notify Payload applies to the IKE_SA as 597 specified in MOBIKE [RFC4555]. That is to say the carried IP address 598 is used by the IKEv2 application, only. Alternate IP addresses are 599 used only when the current IP Address is not working anymore. 601 When ADDITIONAL_IP_ADDRESS Notify Payload applies to a regular SA, 602 then IKEv2 SHOULD forward the information to ULP. This draft does 603 not provide any details on how communication is done between ULP and 604 IKEv2. This is not considered in this paper. 606 The IP address is carried in the Notify Payload in the data field 607 thanks to IP parameter. This is a main difference with MOBIKE 608 [RFC4555] where the data field directly contains the value of IP 609 address. 611 Thus the ADDITIONAL_IP_ADDRESS Notify Payload can carry the following 612 parameters : 614 - IP : The IP address to be used as an Alternate IP Address. 615 - ID : The Identification Number of the Notify Payload. It is 616 optional. It is recommended to add this option so that when an 617 error occurs, the Notify Payload Notify Payload causing the 618 error can be identified. 620 IP parameters can carry information about the IP address thanks to 621 the Multihoming Information Payload (MIP). Such information is 622 intended to help the Responder to choose the best Alternate IP 623 Address, in case of failure. Such information includes the 624 REACHABILITY that indicates the REACHABILITY information of the IP 625 address, the CLASS which indicates the nature of the IP address (HoA, 626 CoA...), the PREFERENCE which is a non objective parameter provided 627 by the Initiator. 629 The CHECK bit indicates if the Initiator expects the action to be 630 performed or if the Initiator is only willing to check the action can 631 be performed. If the Alternate IP Address does not match the local 632 policies then an UNACCEPTABLE_IP_ADDRESS Notify Payload is sent back. 633 If the Alternate IP Address does not fit the SPD, then a 634 DOES_NOT_FIT_SPD Notify Payload is sent back. Note that checks do 635 not include Return Routability Check. If the user wants to check the 636 reachability of the Alternate IP address, and if that is possible -- 637 the Initiator is multihomed -- , then the Initiator MUST perform it 638 and initiate the exchange. If NEW_IP address matches both local 639 policies and the SPD, then a INFORMATIONAL response is sent without 640 error Notify Payloads. 642 SELECTORs Notify Payload MAY be used to specify which on which 643 Security Association the IP address change MUST occur. 645 6.6. UPDATE_SA_ADDRESSES Notify Payload 647 UPDATE_SA_ADDRESSES Notify Payload indicates the Responder that the 648 Initiator wants to replace OLD_IP by NEW_IP, in the selected SAs. 650 In MOBIKE, the Initiator uses only one IP address. Thus, OLD_IP is 651 the one associated to the peer in the IKE_SA and the CHILD_SA(s). 652 The NEW_IP is in the IP header of the IP packet carrying IKEv2 653 message. In MOBIKE-X, the Initiator can use simultaneous IP 654 addresses, thus we need to be able to explicitly specify in the 655 Notify Payload, OLD_IP and NEW_IP. 657 So the difference with MOBIKE is that the UPDATE_SA_ADDRESSES Payload 658 can carry the following parameters : 660 - OLD_IP : The replaced IP address. The parameter is a regular IP 661 parameter, where we set the OLD bit to one. In case of tunnel 662 mode Security Association, the I (inner) and the H (header) bit 663 specifies if the OLD_IP is the inner or outer IP address. 664 - NEW_IP : The replacing IP address. The parameter is a regular IP 665 parameter where we set the NEW bit to one. 666 - ID : The Identification Number of the Notify Payload. It is 667 optional. It is recommended to add this option so that when an 668 error occurs, the Notify Payload Notify Payload causing the 669 error can be identified. 671 If NEW_IP does not match the local policies then an 672 UNACCEPTABLE_IP_ADDRESS Notify Payload is sent back. If NEW_IP does 673 not fit the SPD, then a DOES_NOT_FIT_SPD Notify Payload is sent back. 674 Note that checks do not include Return Routability Check. If the 675 user wants to check the reachability of NEW_IP, and if that is 676 possible -- the Initiator is multihomed -- , then the Initiator MUST 677 perform it and initiate the exchange. 679 The CHECK bit indicates if the Initiator expects the action to be 680 performed or if the Initiator is only willing to check the action can 681 be performed. 683 O, N, bits specify which IP is the OLD_IP, and which IP is the 684 NEW_IP. H and I bits specify where in the SA the IP address is 685 located. In SA using tunnel mode, the bit I indicates the IP address 686 is located inside the tunnel (Inner), and H specifies the IP address 687 is in the outer tunnel header (Header). In SA using transport mode, 688 the H bit indicates the IP address is in the outer IP header. H 689 stands for routed IP Header. 691 The OLD_IP and NEW_IP are not required. If there are omitted by the 692 Initiator, then default values are considered. 694 SELECTORs Notify Payload MAY be used to specify which on which 695 Security Association the IP address change MUST occur. 697 6.7. ADD_SA_ADDRESS Notify Payload 699 The ADD_SA_ADDRESS Notify Payload is very similar as the 700 UPDATE_SA_ADDRESSES Notify Payload. The Initiator sends an 701 ADD_SA_UPDATE Notify Payload so the Responder ADDs an IP address to 702 the SA designated by the SELECTORs. The IP address is designated by 703 the IP parameter. 705 If IP parameter does not match the local policies then an 706 UNACCEPTABLE_IP_ADDRESS Notify Payload is sent back. If the IP 707 address does not fit the SPD, then a DOES_NOT_FIT_SPD Notify Payload 708 is sent back. Note that checks do not include Return Routability 709 Check. If the user wants to check the reachability of the IP 710 address, and that is possible -- the Initiator is multihomed -- , 711 then the Initiator MUST perform it and initiates the exchange. 713 CHECK, H, I have the same signification as with the 714 UPDATE_SA_ADDRESSES Notify Payload. The O bit and N bit are not 715 considered, since only one IP address is being ADDed. 717 The ADD_SA_ADDRESS Notify Payload can carry the following parameters 718 : 720 - IP : The IP address to be used as an alternate IP address. 721 - ID : The Identification Number of the Notify Payload. It is 722 optional. It is recommended to add this option so that when an 723 error occurs, the Notify Payload Notify Payload causing the 724 error can be identified. 726 6.8. REMOVE_SA_ADDRESS Notify Payload 728 The REMOVE_SA_ADDRESS Notify Payload is very similar as the 729 UPDATE_SA_ADDRESSES Notify Payload. The Initiator sends an 730 REMOVE_SA_UPDATE Notify Payload so the Responder REMOVEs an IP 731 address to the SA designated by the SELECTORs. 733 If IP parameter does not match the local policies then an 734 UNACCEPTABLE_IP_ADDRESS Notify Payload is sent back. If the IP 735 address does not fit the SPD, then a DOES_NOT_FIT_SPD Notify Payload 736 is sent back. Note that checks do not include Return Routability 737 Check. If the user wants to check the reachability of IP address, 738 and if that is possible -- the Initiator is multihomed --, then the 739 Initiator MUST perform it and initiate the exchange. When the 740 Initiator requests a REMOVEs on the last IP address of an SA, then 741 the Responder REMOVEs the IP address -- or not depending on the CHECK 742 bit value --- and sends a warning Notify Payload CLOSING_SA. 744 CHECK, H, I have the same signification as with the 745 UPDATE_SA_ADDRESSES Notify Payload. The O bit and N bit are not 746 considered, since only one IP address is being REMOVEd. 748 The REMOVE_SA_ADDRESS Notify Payload can carry the following 749 parameters : 751 - IP : The IP address to be used as an alternate IP address. 752 - ID : The Identification Number of the Notify Payload. It is 753 optional. It is recommended to add this option so that when an 754 error occurs, the Notify Payload Notify Payload causing the 755 error can be identified. 757 7. Protocol Exchanges 759 This section provides a description on how Initiators and Responders 760 are expected to behave when receiving or sending the different Notify 761 Payloads involved in this paper. For clarification purpose we 762 illustrate the behavior with state diagrams. State diagrams mostly 763 rely on node's implementation. States and state diagrams are not 764 normative. We also tried to point out different possible 765 implementations. 767 7.1. Initial Exchange 769 7.1.1. MOBIKE_SUPPORTED Notify Payload 771 The initial exchange enables the Initiator to check if the Responder 772 supports MOBIKE-X and negotiates a given version of MOBIKE-X with the 773 Responder. The Initial exchange is derived from [RFC4555] and shows 774 how NAT is considered. As mentioned in the Introduction section NAT 775 is treated in a similar manner as it is in MOBIKE [RFC4555]. 777 Initiator Responder 778 ----------- ----------- 779 1) (IP_I1:500 -> IP_R1:500) 780 HDR, SAi1, KEi, Ni --> 781 N(NAT_DETECTION_SOURCE_IP), 782 N(NAT_DETECTION_DESTINATION_IP) --> 784 <-- (IP_R1:500 -> IP_I1:500) 785 HDR, SAr1, KEr, Nr, 786 N(NAT_DETECTION_SOURCE_IP), 787 N(NAT_DETECTION_DESTINATION_IP) 789 2) (IP_I1:4500 -> IP_R1:4500) 790 HDR, SK { IDi, CERT, AUTH, 791 CP(CFG_REQUEST), 792 SAi2, TSi, TSr, 793 N(MOBIKE_SUPPORTED)} --> 795 <-- (IP_R1:4500 -> IP_I1:4500) 796 HDR, SK { IDr, CERT, AUTH, 797 CP(CFG_REPLY), 798 SAr2, TSi, TSr, 799 N(MOBIKE_SUPPORTED) } 801 Initial exchange 803 As specified in [RFC4555], in order to be able to go through NAT, 804 when using MOBIKE, the port used is 4500. The Initiator sends a 805 MOBIKE_SUPPORTED Notify Payload in which it indicates the proposed 806 versions. The Notify Payload SHOULD have its critical flag on. The 807 version of MOBIKE considered in [RFC4555] is version 1, and the 808 version of MOBIKE considered in this draft is version 2. 810 If the Responder does not support MOBIKE, it does not understand the 811 Notify Payload, the exchange is described in section 2.5 of 812 [RFC4306]. If the Notify Payload has been set to critical by the 813 Initiator, then the Responder MUST send as specified in [RFC4306] a 814 UNSUPPORTED_CRITICAL_PAYLOAD Notify Payload. The Initiator knows 815 that the Responder does not support any version of MOBIKE or 816 MOBIKE-X. If the Notify Payload does not have its critical flag, 817 then the Responder does not send any response and the Initiator 818 SHOULD wait for a given time before assuming the Responder does not 819 support MOBIKE or MOBIKE-X. 821 If the Responder supports MOBIKE, but does not support MOBIKE-X : 822 When it receives a MOBIKE_SUPPORTED Notify Payload, it does not 823 understand parameters specified in data field. If the Responder 824 wants to activate MOBIKE, then it sends a MOBIKE_SUPPORTED Notify 825 Payload with no version specified in the data field of the Notify 826 Payload. When the Initiator receives this Notify Payload, it 827 understands that with no version specified, the Responder does only 828 understand MOBIKE as specified in [RFC4555]. If the Responder does 829 not want to activate MOBIKE, it MUST check the critical flag of the 830 received Notify Payload and either MUST send a 831 UNSUPPORTED_CRITICAL_PAYLOAD Notify Payload, or no response at all. 832 When the Initiator receives the UNSUPPORTED_CRITICAL_PAYLOAD Notify 833 Payload or no response, it understands that the Responder does not 834 support MOBIKE. 836 Note that the Initiator cannot make the distinction between a 837 Responder that does not want to activate MOBIKE, or a responder do 838 not support MOBIKE. 840 If the Responder supports MOBIKE-X and does not want to activate 841 MOBIKE or MOBIKE-X : When it receives the MOBIKE_SUPPORTED Notify 842 Payload, the Responder MUST check the data field and check if there 843 are any versions proposed. If no version is proposed, then the 844 Initiator only supports MOBIKE. The Responder should check the 845 critical flag of the Notify Payload and either sends a 846 UNSUPPORTED_CRITICAL_PAYLOAD Notify Payload, or no response. If the 847 MOBIKE_SUPPORTED Notify Payload carries version parameters in its 848 data payload, then the Responder knows that the Initiator does 849 support MOBIKE-X. It SHOULD send a MOBIKE_UNSUPPORTED_VERSION Notify 850 Payload with a version set to NONE. The Responder knows the 851 Initiator supports MOBIKE-X since the MOBIKE_SUPPORTED Notify Payload 852 has version parameters. The Initiator will then understand the 853 response. This case is an alternative to simulate the case the 854 Responder does not event understand MOBIKE and sends only a 855 UNSUPPORTED_CRITICAL_PAYLOAD. It clearly states the Responder does 856 support MOBIKE-X, but does not want to activate it. 858 If the Responder supports MOBIKE-X and does only want to activate 859 MOBIKE as defined in [RFC4555] : When it receives the 860 MOBIKE_SUPPORTED Notify Payload, it MUST check the MOBIKE_SUPPORTED 861 Notify Payload carries version parameters in its data field. If no 862 version number is found, the Responder assumes the Initiator does 863 only supports MOBIKE as defined in [RFC4555]. It SHOULD send a 864 MOBIKE_SUPPORTED Notify Payload. If the data field carries version 865 numbers, then the Responder knows the Initiator supports MOBIKE-X. 866 The Responder should check version 1 is proposed. If version 1 is 867 proposed, then the Responder MUST send a MOBIKE_SUPPORTED Notify 868 Payload with the chosen version, i.e. version 1. If the version 1 is 869 not proposed, then the Responder MUST send a 870 MOBIKE_UNSUPPORTED_VERSION Notify Payload indicating the accepted 871 version by the Responder. In that specific case the Notify Payload 872 data field MUST carry version 1. When the Initiator receives the 873 response it is up to him to decide to restart a MOBIKE_SUPPORTED 874 exchange with the version 1 proposed or to consider that neither 875 MOBIKE nor MOBIKE-X are activated. 877 If the Responder supports MOBIKE-X and wants to activate MOBIKE-X : 878 When it receives the MOBIKE_SUPPORTED Notify Payload, it MUST check 879 the data field of the Notify Payload carries version numbers in the 880 data field. If no version numbers are specified, then the Initiator 881 supports MOBIKE, but does not support MOBIKE-X. The Responder can 882 choose to enable MOBIKE or not. This case is similar as the one when 883 the Responder supports MOBIKE-X but only wants to activate MOBIKE. 884 If the Initiator supports MOBIKE-X, the Responder should check 885 version number 2 is proposed by the Initiator. If version number 2 886 is not proposed, the Responder MUST send a MOBIKE_UNSUPPORTED_VERSION 887 Notify Payload with version set to 2. If version number 2 is 888 proposed then the Responder MUST send a MOBIKE_SUPPORTED Notify 889 Payload with the chosen version number, that is to say with version 890 number 2. In this case MOBIKE-X is considered activated both on the 891 Initiator side and on the Responder side. 893 NOTE 1 : The case where the Initiator supports MOBIKE-X and starts a 894 MOBIKE_SUPPORTED exchange with the Responder which does not supports 895 is specified in [RFC4306] section 2.5. 897 IKEv2 adds a "critical" flag to each payload header for further 898 flexibility for forward compatibility. If the critical flag is 899 set and the payload type is unrecognized, the message MUST be 900 rejected and the response to the IKE request containing that 901 payload MUST include a Notify payload 902 UNSUPPORTED_CRITICAL_PAYLOAD, indicating an unsupported 903 critical payload was included. If the critical flag is not set 904 and the payload type is unsupported, that payload MUST be 905 ignored. 907 NOTE 2 : There is one corner case. Consider the Initiator supports 908 MOBIKE-X, and wants to activate MOBIKE-X but does NOT want MOBIKE, 909 and the Responder does only supports MOBIKE. In that case, the 910 Initiator sends a MOBIKE_SUPPORTED Notify Payload to the Responder. 911 The Responder supports only MOBIKE, and sends back a MOBIKE_SUPPORTED 912 Notify Payload. Responder and Initiators have agreed on version 1 of 913 MOBIKE. MOBIKE as described in [RFC4555] does not provides any 914 Notify Payload to remove the MOBIKE option. In other words, there is 915 no equivalent of MOBIKE_UNSUPPORTED_VERSION in MOBIKE. So the 916 situation is MOBIKE as been "agreed" between the Initiator and the 917 Responder, the Initiator wants MOBIKE-X and cannot remove MOBIKE. 918 Consequences are that the Initiator cannot use MOBIKE-X 919 functionalities, but can be requested by the Responder some MOBIKE 920 functions. If that bothers the Initiator, then it has to restart an 921 IKE_SA_INT exchange without sending MOBIKE_SUPPORTED Notify Payload. 923 7.1.2. MOBIKE_UNSUPPORTED_VERSION Notify Payload 925 The MOBIKE_UNSUPPORTED_VERSION is a MOBIKE-X specific Notify Payload. 926 It MUST be sent by the Responder when it has checked the Initiator 927 supports MOBIKE-X. 929 The MOBIKE_UNSUPPORTED_VERSION Notify Payload can be received during 930 the MOBIKE_SUPPORTED negotiation. The Responder as well as the 931 Initiator supports MOBIKE-X but the Responder does not support the 932 version of MOBIKE-X proposed by the Initiator. The other case this 933 Notify Payload can be used is when the Initiator and the Responder 934 have already agreed on which version of MOBIKE-X to activate, and one 935 of them wants to deactivate the used of MOBIKE or MOBIKE-X. 937 Suppose the Initiator has started its MOBIKE version negotiation, and 938 both Initiator and Responder support MOBIKE-X. When the 939 MOBIKE_UNSUPPORTED_VERSION Notify Payload is received, the Initiator 940 knows the previously proposed versions are not supported by the 941 Responder. The Initiator can read the version carried by the 942 MOBIKE_UNSUPPORTED_VERSION. If the version is NONE, it means the 943 Responder supports MOBIKE-X but does not want to activate the MOBIKE 944 or MOBIKE-X extension. 946 If the Responder supports another version than the one proposed by 947 the Initiator, then it sends its version number into the 948 MOBIKE_UNSUPPORTED_VERSION, the Initiator can then check if this 949 version has not been previously been sent and if it supports this 950 version. It can then restart a negotiation and send a 951 MOBIKE_SUPPORTED Notify Payload with the version supported by the 952 Responder. This gives the opportunity to the Initiator to have a 953 preferred list sent in the first MOBIKE_SUPPORTED Notify Payload, and 954 a backup of other versions in case the Responder does not support the 955 versions of the "preferred list". The Responder is expected to send 956 a MOBIKE_SUPPORTED Notify Payload with the proper version. If not 957 the Initiator the Responder is probably badly configured and MOBIKE-X 958 extension is not activated. 960 The MOBIKE_UNSUPPORTED_VERSION Notify Payload can also be received by 961 any of the peer while MOBIKE-X has been negotiated between the 962 Initiator and the Responder. In this situation, the version MUST be 963 set to NONE, and it means that MOBIKE-X is not active anymore. 965 7.1.3. Initial exchange state diagrams 967 The diagrams and states descriptions provided in this section are not 968 normative. There purpose is to clarify the text description. It 969 might help for some implementations but implementations are not 970 expected to implement them. 972 The different states considered in this paper are : 974 - INIT : This state corresponds to the starting point when no 975 MOBIKE-X negotiation has been initiated. 976 - MOBIKE_SUPPORTED_SENT : This Initiator is in this state when it 977 has sent a MOBIKE_SUPPORTED Notify Payload. The Initiator is 978 then waiting for a response. 979 - MOBIKE_SUPPORTED : This state ends a MOBIKE_SUPPORTED 980 negotiation. Initiator and the Responder agreed on activating 981 version 1, that is to say MOBIKE as specified in [RFC4555]. 982 MOBIKE-X as specified in this paper has not been agreed. 983 - MOBIKE-X_SUPPORTED : This state ends a MOBIKE_SUPPORTED 984 negotiation. Initiator and the Responder agree on activating 985 version greater then 1, that is to say MOBIKE-X as specified in 986 this paper is activated by the Initiator and the Responder. 987 When MOBIKE-X is supported, then MOBIKE is also supported. 988 - MOBIKE-X_UNSUPPORTED : This state ends the MOBIKE_SUPPORTED 989 negotiation. Initiator and Responder did not agreed on the 990 activation of MOBIKE-X as described in this paper. This state 991 means the Initiator and the Responder agreed on MOBIKE but not 992 MOBIKE-X. 993 - MOBIKE_UNSUPPORTED : This state ends the MOBIKE_SUPPORTED 994 negotiation. Initiator and Responder did not agree on the 995 activation of MOBIKE-X as described in this paper nor MOBIKE as 996 described in [RFC4555]. This state can also been considered as 997 similar to the INIT state, except that one negotiation has been 998 attempted. 1000 In the state diagram, we used a context called CTX. This is also not 1001 normative. The Context contains the following information : 1003 - INITIATOR The necessary information to identify the Initiator 1004 part of the MOBIKE-X negotiation. 1005 - RESPONDER The necessary information to identify the Responder 1006 part of the MOBIKE-X negotiation. 1007 - INITIATOR_VERSION MOBIKE-X versions proposed by the Initiator to 1008 the Responder. 1009 - RESPONDER_VERSION MOBIKE-X versions proposed by the Responder to 1010 the Initiator. 1011 - NEGOTIATED_VERSION MOBIKE-X versions agreed by the Responder and 1012 the Initiator. 1014 - STATUS The status of the negotiation the different values can be 1015 START, MOBIKE, MOBIKE-X or NULL. 1017 For simplification, we assume in the Initiator diagram that the 1018 Initiator supports MOBIKE-X and proposed to the Responder version 1 1019 (MOBIKE) and version 2 (MOBIKE-X). We also assume in the Responder 1020 diagram that if the Responder supports MOBIKE-X, then it choose 1021 MOBIKE-X rather then MOBIKE. The Responder state diagram does not 1022 have MOBIKE_UNSUPPORTED or MOBIKE-X_UNSUPPORTED state, and when a 1023 negotiation fails, the Responder does not keep any context. This is 1024 an implementation consideration, and we thought that keeping a 1025 context to every negotiation could expose the Responder to DoS. 1027 +------------------------+ 1028 | INIT | 1029 +------------------------+ 1030 | 1031 +<--- Initiator want to enable MOBIKE-X 1032 | 1033 Create Context 1034 CTX = (INITIATOR, RESPONDER, 1035 INITIATOR_VERSION=1,2 1036 RESPONDER_VERSION=NULL, 1037 NEGOTIATED_VERSION=NULL, 1038 STATUS=START ) 1039 Send a MOBIKE_SUPPORTED Notify Message 1040 with corresponding VERSION to RESPONDER 1041 Set the critical flag to 1 1042 | 1043 +------------------------+ 1044 | MOBIKE_SUPPORTED_SENT | 1045 +------------------------+ 1047 Initiator : INIT to MOBIKE_SUPPORTED_SENT 1049 +------------------------+ 1050 | MOBIKE_SUPPORTED_SENT | INITIATOR, CTX 1051 +------------------------+ 1052 | NO 1053 MESSAGE from CTX.RESPONDER ? --TIMEOUT-+--------------+ 1054 | YES YES | | 1055 MESSAGE.type == ----------+ CTX.STATUS=NULL 1056 UNSUPPORTED_CRITICAL_PAYLOAD ? | 1057 | NO +------------------------+ 1058 MESSAGE.type = MOBIKE_SUPPORTED && ---+ | MOBIKE_UNSUPPORTED | 1059 MESSAGE has no VERSION ? YES | +------------------------+ 1060 NO | NO +--------------+ 1061 +-- MESSAGE.type == MOBIKE_SUPPORTED && v 1062 | MESSAGE.VERSION in CTX.RESPONDER_VERSION=1 1063 | CTX.INITIATOR_VERSION ? CTX.STATUS=MOBIKE 1064 | | YES CTX.NEGOTIATED_VERSION=1 1065 | CTX.STATUS = MOBIKE-X | 1066 | CTX.NEGOTIATED_VERSION = +------------------------+ 1067 MESSAGE.VERSION | MOBIKE-X_UNSUPPORTED | 1068 | CTX.RESPONDER_VERSION=MESSAGE.VERSION +------------------------+ 1069 | | 1070 | +------------------------+ 1071 | | MOBIKE-X_SUPPORTED | 1072 | +------------------------+ 1073 | 1074 +-> MESSAGE.type == MOBIKE_UNSUPPORTED_VERSION 1075 | NO 1076 MESSAGE.VERSION == NONE ? ---------------------------+ 1077 | YES NO v 1078 CTX.RESPONDER_VERSION=1,2 +-------- MESSAGE.VERSION == 1 ? 1079 CTX.STATUS=NULL | | YES 1080 | | CTX.RESPONDER_VERSION=1,2 1081 +------------------------+ | CTX.STATUS=MOBIKE 1082 | MOBIKE_UNSUPPORTED | | | 1083 +------------------------+ | +------------------------+ 1084 +-----------------+ | MOBIKE-X_UNSUPPORTED | 1085 v +------------------------+ 1086 CTX.RESPONDER_VERSION=1,2 1087 CTX.STATUS=NULL 1088 | 1089 +------------------------+ 1090 | MOBIKE_UNSUPPORTED | 1091 +------------------------+ 1093 Initiator : MOBIKE_SUPPORTED_SENT to MOBIKE*_*SUPPORTED 1095 +------------------------+ 1096 | INIT | RESPONDER, CTX 1097 +------------------------+ 1098 | 1099 | 1100 MESSAGE received && NO +------------------------+ 1101 MESSAGE.type == MOBIKE_SUPPORTED ? --->| INIT | 1102 | YES NO +------------------------+ 1103 RESPONDER supports MOBIKE ? -----------------------+ 1104 | YES NO v 1105 RESPONDER supports MOBIKE-X (')?-----+ Send UNSUPPORTED_CRITICAL_PAYLOAD 1106 | YES NO| | 1107 Does MESSAGE carries VERSION (*)?----+ +------------------------+ 1108 | YES | | INIT | 1109 MESSAGE.VERSION supported ? | +------------------------+ 1110 | YES | NO+--------------+ 1111 Chose a VERSION +------------+ v 1112 Send MOBIKE_SUPPORTED | Send MOBIKE_SUPPORTED -no version 1113 MESSAGE.VERSION | Create CTX( 1114 Create Context | INITIATOR, RESPONDER 1115 CTX = ( | INITIATOR_VERSION=1 1116 INITIATOR, RESPONDER | RESPONDER_VERSION=[1'] [1, 2*] 1117 INITIATOR_VERSION=MESSAGE.VERSION, | NEGOTIATED_VERSION=1 1118 RESPONDER_VERSION=VERSION, | STATUS=MOBIKE) 1119 NEGOTIATED_VERSION=VERSION, | | 1120 STATUS=MOBIKE-X ) | +------------------------+ 1121 | | | MOBIKE_SUPPORTED | 1122 +--------------------------+ | +------------------------+ 1123 | MOBIKE-X_SUPPORTED | +--------------+ 1124 +--------------------------+ v 1125 Send UNSUPPORTED_MOBIKE_VERSION 1126 with supported VERSIONs 1127 | 1128 +------------------------+ 1129 | INIT | 1130 +------------------------+ 1132 Responder : INIT to MOBIKE*_SUPPORTED 1134 +------------------------+ 1135 | MOBIKE-X_SUPPORTED | 1136 +------------------------+ 1137 | 1138 +<----MESSAGE received 1139 | NO 1140 MESSAGE.type == ----------------------+ 1141 MOBIKE_UNSUPPORTED_VERSION ? | 1142 | YES NO v 1143 MESSAGE.VERSION == NONE ? ----------+ Treat MESSAGE 1144 | YES | | 1145 v | +------------------------+ 1146 +-------- ---------------+ | | MOBIKE-X_SUPPORTED | 1147 | MOBIKE_UNSUPPORTED | | +------------------------+ 1148 +------------------------+ +----------+ 1149 v 1150 Discard MESSAGE 1151 | 1152 +------------------------+ 1153 | MOBIKE-X_SUPPORTED | 1154 +------------------------+ 1156 MOBIKE-X_SUPPORTED to MOBIKE_UNSUPPORTED 1158 7.2. Alternate IP Address Exchange 1160 When the Initiator wants to inform the Responder that it has an 1161 Alternate IP address, the Initiator sends an ADDITIONAL_IP_ADDRESS 1162 Notify Payload. In MOBIKE [RFC4555], this case is described in 1163 section 3.6. More specifically the data field contains the value of 1164 the IP address. 1166 In MOBIKE-X, the main difference is that we use parameter payload 1167 that specifies the type of the IP address. Furthermore, the IP 1168 parameter provides also some information on the IP addresses. The 1169 reason is that with multihoming, the Initiator might have more then 1170 one alternate IP address. If the current IP address is not in use, 1171 then the Responder has to choose the more adequate IP address. 1172 Multihoming Information Payload (MIP) associated to the IP address 1173 are intended to provide input for the Responder. 1175 As in the MOBIKE [RFC4555] document, ADDITIONAL_IP_ADDRESS Notify 1176 Payload contains only one IP address. More IP addresses could have 1177 been placed, but it is better for logs to have elementary actions. 1178 One difference with MOBIKE [RFC4555] is that the type of the expected 1179 IP address is specified in the action Notify Payload. In fact, if 1180 IPv6 (resp IPv4) Alternate IP Addresses have to be sent, then an 1181 ADDITIONAL_IP6_ADDRESS (resp. ADDITIONAL_IP4_ADDRESS) Notify Payload 1182 is used. MOBIKE-X does not need different Notify Payload since the 1183 type of the IP address is defined in the IP address parameter. 1184 MOBIKE-X only uses the ADDITIONAL_IP6_ADDRESS notify Payload, and it 1185 is called ADDITIONAL_IP_ADDRESS in this document. 1187 When the Responder receives an ADDITIONAL_IP_ADDRESS with a CHECK bit 1188 set to 0, the Responder MUST clear the list of Alternate IP address, 1189 and fill the list with the IP addresses provided in the multiple 1190 ADDITIONAL_IP_ADDRESSES Notify Payloads. In other words, Initiator 1191 can only send to full list and there is not incremental way to 1192 provide / remove Alternate IP Addresses. This mechanism is the one 1193 already existing in MOBIKE [RFC4555]. 1195 This draft only cares about Alternate IP Address associated to the 1196 IKE_SA. When an Alternate IP address is associated to an SA, IKEv2 1197 application MUST forward the information to the ULP. How this is 1198 performed is beyond the scope of this document. In this document we 1199 mainly consider the Initiator sends an Alternate IP address to the 1200 IKEv2 application of the Responder. 1202 If the Initiator sends an ADDITIONAL_IP_ADDRESS Notify Payload with 1203 the CHECK bit set to 0, then the Initiator does not request for 1204 verifications. The Responder adds the IP address into the list of 1205 alternate IP addresses. 1207 If the Initiator wants to CHECK an alternate IP address is valid, 1208 then it MUST set the CHECK bit to 1. When the Responder receives an 1209 ADDITIONAL_IP_ADDRESS Notify Payload with the CHECK bit set to one, 1210 the Responder checks the Alternate IP address matches local policies. 1211 If the Alternate IP address does not match the local policies, then 1212 the Responder MUST send an UNACCEPTABLE_IP_ADDRESS Notify Payload. 1213 The Responder also checks the Alternate IP address matches with the 1214 SPD. If the Alternate IP address does not fit the SPD, then a 1215 DOES_NOT_FIT_SDP Notify Payload MUST be sent. Note that with IKE_SA, 1216 any IP address matches the SP policy. 1218 The Initiator indicates the Alternate IP Address thanks to IP 1219 parameter. The Initiator MAY set the PREFERENCE, CLASS fields. 1221 In this document Alternate IP addresses have their IP parameters 1222 payload with the O, N, I bits values set to 0 and the H bit set to 1. 1224 7.3. Alternate IP Address Exchange State Diagram 1225 +------------------------+ 1226 | MOBIKE-X_SUPPORTED | INITIATOR 1227 +------------------------+ 1228 | 1229 +<---- Want to ADD an 1230 | Alternate IP Address 1231 | matching SELECTORs 1232 Set the proper SELECTORs 1233 | 1234 Do I want CHECK ? ---------------+ 1235 | YES NO v 1236 v Set NEW_IP/OLD_IP 1237 Set NEW_IP/OLD_IP CHECK bit to 0 1238 CHECK bit to 1 | 1239 | | 1240 +<-------------------+ 1241 | 1242 Set ID parameter 1243 Set the I, O, N to 0 1244 Set the H bit to 1 1245 Send it to Responder 1246 | 1247 +--------------------------+ 1248 |ADDITIONAL_IP_ADDRESS_SENT| 1249 +--------------------------+ 1251 Initiator : Sending SA_UPDATE_ADDRESSES 1253 +--------------------------+ 1254 |ADDITIONAL_IP_ADDRESS_SENT| INITIATOR 1255 +--------------------------+ 1256 | 1257 +<---- RESPONSE is received 1258 | from Responder 1259 Does RESPONSE carries ERROR -----+ 1260 | YES NO v 1261 The Alternate IP The Alternate IP 1262 Address cannot be used Address can be used. 1263 Eventually forward Eventually ACKnowledge 1264 ERROR to ULP it to ULP 1265 | | 1266 +<-------------------+ 1267 | 1268 +------------------------+ 1269 | MOBIKE-X_SUPPORTED | 1270 +------------------------+ 1271 Initiator : Going back to MOBIKE-X_SUPPORTED State 1273 +------------------------+ 1274 | MOBIKE-X_SUPPORTED | RESPONDER 1275 +------------------------+ 1276 | 1277 +<---- SA_ADDITIONAL_IP_ADDRESS 1278 | received 1279 | NO 1280 ADDITIONAL_IP_ADDRESS has one ------------+ 1281 and only one ID parameters ? v NO 1282 | YES There is no ID parameter ? ----+ 1283 Insert it in RESPONSE | YES | 1284 +<---------------------------+ | 1285 | RESPONSE = UNACCEPTABLE 1286 IP Address fits local policies ? ---------+ PARAMETER v 1287 | YES NO v | 1288 | RESPONSE=UNACCEPTABLE_ADDRESSES | 1289 IP Address fits SPD ? -------------------+ | 1290 | YES NO v | 1291 Replace OLD_IP by NEW_IP RESPONSE=DOES_NOT_FIT_SPD | 1292 where SELECTOR indicates it | | 1293 | YES | | 1294 RESPONSE=VOID | | 1295 | | | 1296 CHECK=0 ? ----------------------+ | | 1297 | YES NO | | | 1298 Clear Alternate IP Addresses | | | 1299 List associated to SELECTORs | | | 1300 | | | 1301 | | | | 1302 +<------------------+<------+<--------------------+ 1303 | 1304 Send RESPONSE 1305 | 1306 +------------------------+ 1307 | MOBIKE-X_SUPPORTED | 1308 +------------------------+ 1310 Responder : Receiving ADDITIONAL_IP_ADDRESS 1312 7.4. UPDATE Exchange 1314 The figure below illustrates the different possible IPsec 1315 configuration between the responder and the Initiator. The figure 1316 represents the different IKE_SA negotiated by one of the peer. The 1317 Initiator can have various IKE_SA to which are associated different 1318 SAs. 1320 : 1321 +-IKE_SA_0 1322 | iID: INITIATOR (iIP) 1323 | rID: RESPONDER (rIP_1, ...,IP_n) 1324 | | 1325 | +-SA_1 : mode=Transport 1326 | : iID: iIP rID: rIP_1 1327 | +-SA_j : mode=Transport 1328 | : iID: iIP rID: rIP_k 1329 | +-SA_m : mode=Tunnel 1330 : iID: iIP_vitual rID: rIP_1 1331 : Tunnel header : 1332 : iID:iIP rID:rIP_1 1333 : 1334 +-IKE_SA_l 1335 | iID: INITIATOR (iIP) 1336 | rID: RESPONDER (rIP_1, ...,IP_n) 1337 | | 1338 | +-SA_1 : mode=Transport 1339 | : iID: iIP rID: rIP_1 1340 | +-SA_p : mode=Transport 1341 | : iID: iIP rID: rIP_k 1342 | +-SA_q : mode=Tunnel 1343 : iID: iIP_vitual rID: rIP_1 1344 : Tunnel header : 1345 : iID:iIP rID:rIP_1 1347 IKE configuration 1349 The UPDATE_SA_ADDRESSES Notify Payload already exists in MOBIKE 1350 [RFC4555]. In MOBIKE OLD_IP and NEW_IP are implicit. In MOBIKE-X 1351 also they can be implicitly or explicitly specified. OLD_IP and 1352 NEW_IP are specified with the IP parameter. Distinction between OLD 1353 and NEW is done thanks to the O and N bit. According to the IP 1354 parameter in the data field we consider the following cases : 1356 - NO IP parameter : is specified. Then the NEW_IP is the IP 1357 address in the IP header carrying the Notify Payload. The 1358 OLD_IP are all IP addresses associated to the Initiator. In 1359 SAs using the tunnel mode, only the outer IP address is 1360 considered. 1362 - A single OLD_IP parameter : is specified. Then the NEW_IP 1363 address is the one in the IP header of the message carrying the 1364 Notify Payload. OLD_IP is specified, and replaced by NEW_IP. 1365 The H and I bits of the OLD_IP specifies where in the SA the 1366 change occurs. 1367 - A single NEW_IP parameter : is specified. Then OLD_IP are all 1368 IP address associated to the Initiator. OLD_IP are replaced by 1369 the specified NEW_IP address. The H and I bits in the OLD_IP 1370 specifies where the update MUST be done. 1371 - One OLD_IP and one NEW_IP parameters : are specified. OLD_IP 1372 MUST be replaced by NEW_IP. The H and I bits MUST be the same 1373 on both OLD_IP and NEW_IP. Those values specify where the 1374 change occurs. If the H and I bits are not the same, then a 1375 UNACCEPTABLE_PARAMETERS Notify Payload MUST be sent as a 1376 response. 1378 In any other cases, an UNACCEPTABLE_PARAMETERS Notify Payload MUST be 1379 sent. 1381 Section 3.5 of [RFC4555] provides a description on how to change an 1382 IPsec SA in the tunnel mode case. The Initiator decides if a return 1383 routability check needs to be performed before updating the IKE_SA 1384 and SAs or not. Then updates the IKE_SA with the new IP address and 1385 set the "pending flag" of the IKE_SA. If The Initiator does not 1386 require the return routability check to be performed before the 1387 update, then, the Initiator updates the SAs and the IKE_SA. When 1388 updating the SAs, the Initiator should also consider NAT traversal 1389 mechanisms and in some cases enables UDP encapsulation of outgoing 1390 ESP packets as well as NAT-Keepalive packets. The Initiator MUST 1391 retransmit requests for which it has not received any responses with 1392 the updated IKE_SA, that is to say with the new address, send a 1393 UPDATE_SA_ADDRESSES Notify Payload and clear the "pending update" 1394 flag. 1396 MOBIKE [RFC4555] specifies that when the Responder receives the 1397 UPDATE_SA_ADDRESSES Notify Payload, it checks if that is the latest 1398 one received. The main reasons to that check was that peers were 1399 only using one IP address always targeted by the UPDATE action. Such 1400 a check SHOULD NOT be performed with MOBIKE-X, since for a given 1401 Security Association different IP addresses can be updated 1402 independently. Some checks can be performed, but in this paper we 1403 believe the easiest way is to performed actions as they are being 1404 requested. 1406 The Responder considers the specified NAT options, checks the new IP 1407 address matches the local policy. If local policies do not match 1408 then the Responder MUST send a UNACCEPTABLE_ADDRESSES. If policies 1409 match, then the Responder updates the IKE_SA with the IP address 1410 taken from the IP header, send a response. Optionally it can perform 1411 a return routability check before updating the SAs. When updating 1412 the SAs, NAT options MUST be carefully considered. 1414 When the Initiator receives the response; it checks the considered 1415 UPDATE_SA_ADDRESSES is still to be considered. If no 1416 UNEXPECTED_NAT_DETECTED or UNACCEPTABLE_ADDRESSES Notify Payload are 1417 sent, the Initiator updates the SAs if not previously done, and take 1418 into account the NAT considerations. 1420 As mentioned in section 3.5 of [RFC4555], the Responder does not 1421 change the IPsec SA without receiving a UPDATE_SA_ADDRESSES Notify 1422 Payload unless the Initiator is unreachable. In that case, the 1423 Responder can use an Alternate IP Address. 1425 Updating a Security Association in a transport mode is done in a 1426 similar manner as it is done for a tunnel mode as described in in 1427 [RFC4555]. The difference is that updating a tunnel header requires 1428 to change one parameter of the SA. This requires to check if that 1429 new IP address matches local policies. Changing the IP address of a 1430 transport mode SA requires also to check and eventually update the 1431 Security Policy Database as well as modifying the binding between the 1432 SPD and the SA. If the update cannot be performed because the SPD 1433 does not allow it, then the Responder MUST send a DOES_NOT_FIT_SPD 1434 Notify Payload. The Initiator MUST try with other IP addresses, so 1435 to enable the mobility. 1437 The Initiator can also send an UPDATE_SA_ADDRESSES Notify Payload to 1438 check wherever the update is possible or not. This is done thanks to 1439 the CHECK bit set to one. The CHECK bit is on the IP parameters. 1440 When no IP parameters are specified, than the Responder considers 1441 that CHECK is set to 0 and that the update MUST occur. When only one 1442 IP parameter is specified, then the CHECK bit value is explicitly set 1443 by the Initiator. When two IP parameters are specified, then the 1444 CHECK value of both parameters MUST be the same. If not, a 1445 UNACCEPTABLE_PARAMETERS Notify Payload MUST be sent. If both CHECK 1446 values are set to 1, then the update MUST NOT occurs. When both of 1447 them are set to 0, and the NEW_IP addresses matches both local and 1448 Security Policies, then the update MUST be performed. 1450 7.5. UPDATE Exchange State Diagram 1452 The state diagram is not normative, and is provided only for 1453 clarification purposes. In that state diagram we assumed the 1454 Initiator specifies the NEW_IP and OLD_IP addresses when it is 1455 multihomed. Deciding when the OLD_IP and NEW_IP or the ID parameters 1456 SHOULD be added depends on the local hosts policies. 1458 +------------------------+ 1459 | MOBIKE-X_SUPPORTED | INITIATOR 1460 +------------------------+ 1461 | 1462 +<---- Want to UPDATE SA 1463 | matching SELECTORs 1464 Can I use default values ---------------+ 1465 for NEW_IP and OLD_IP ? NO v 1466 | YES Explicitly specify 1467 v NEW_IP or/and OLD_IP 1468 Do I want CHECK ? ------+ | 1469 | YES NO | Do I want CHECK ? ---------------+ 1470 v | | YES NO v 1471 I need to specify at | v Set NEW_IP/OLD_IP 1472 least OLD_IP or NEW_IP | Set NEW_IP/OLD_IP CHECK bit to 0 1473 with CHECK bit = 1 | CHECK bit to 1 UPDATE the SA 1474 | UPDATE the SA | | 1475 | | | | 1476 +<---------+<--------------+<-------------------+ 1477 | 1478 v 1479 Set ID parameter 1480 Send it to Responder 1481 | 1482 +------------------------+ 1483 |SA_UPDATE_ADDRESSES_SENT| 1484 +------------------------+ 1486 Initiator : Sending SA_UPDATE_ADDRESSES 1488 +------------------------+ 1489 |UPDATE_SA_ADDRESSES_SENT| INITIATOR 1490 +------------------------+ 1491 | 1492 +<---- RESPONSE is received 1493 | from Responder 1494 Does RESPONSE carries ERROR -----+ 1495 | YES NO | 1496 Responder could not Has CHECK bit set to 1 ? ----+ 1497 proceed to UPDATE v NO | 1498 Eventually forward UPDATE SAs if not already | 1499 ERROR to ULP performed | 1500 | | | 1501 Has CHECK bit set to 0 ? ----+ +<---------------+ 1502 v NO | | 1503 CANCEL UPDATE if already | | 1504 performed | | 1505 | | | 1506 +<---------------+ | 1507 | | 1508 +--------------------+ 1509 | 1510 +------------------------+ 1511 | MOBIKE-X_SUPPORTED | 1512 +------------------------+ 1514 Initiator : Going back to MOBIKE-X_SUPPORTED State 1516 +------------------------+ 1517 | MOBIKE-X_SUPPORTED | RESPONDER 1518 +------------------------+ 1519 | 1520 +<---- UPDATE_SA_ADDRESSES 1521 | received 1522 | NO 1523 UPDATE_SA_ADDRESSES has one -------------+ 1524 and only one ID parameters ? v NO 1525 ID_PARAM=ID There is no ID parameter ? ----+ 1526 | YES ID_PARAM=VOID v 1527 | YES | RESPONSE = UNACCEPTABLE 1528 +<--------------------------+ _PARAMETER 1529 | Insert ID_PARAM -----+ 1530 Has the SA_UPDATE_ADDRESSES -------------+ | 1531 no NEW_IP and no OLD_IP NO v | 1532 parameters Has the SA_UPDATE_ADDRESS --+ | 1533 | YES one and only one NEW_IP and NO| | 1534 Set NEW_IP = IPHEADER.IP_src /or one and only one OLD_IP | | 1535 Set OLD_IP = All iIPs parameters ? | | 1536 | | YES | | 1537 Set CHECK=0, I=0, H=1 Check H, I and CHECK bit | | 1538 | Set OLD_IP and NEW_IP | | 1539 | | v | 1540 +<--------------------------+ RESPONSE=UNACCEPTABLE| 1541 | _PARAMETER | 1542 NEW_IP fits local policies ? -------------+ Insert ID_PARAM --+ | 1543 | YES NO v | | 1544 | RESPONSE=UNACCEPTABLE_ADDRESSES | | 1545 | Insert ID_PARAM ------------+ | | 1546 NEW_IP fits SPD ? -----------------------+ | | | 1547 | YES NO v | | | 1548 Replace OLD_IP by NEW_IP RESPONSE=DOES_NOT_FIT_SPD | | | 1549 where SELECTOR indicates it Insert ID_PARAM | | | 1550 | YES | | | | 1551 RESPONSE=VOID | | | | 1552 | | | | | 1553 +<--------------------------+<---------------+<-+<-+ 1554 Send RESPONSE 1555 | 1556 +------------------------+ 1557 | MOBIKE-X_SUPPORTED | 1558 +------------------------+ 1560 Responder : Receiving UPDATE_SA_ADDRESSES 1562 7.6. Multihoming Exchanges 1564 ADD and REMOVE are the Multihoming actions, and the Notify Payloads 1565 associated to those actions are the ADD_SA_ADDRESS and 1566 REMOVE_SA_ADDRESS Notify Payloads. 1568 The Initiator sends an ADD_SA_ADDRESS or REMOVE_SA_ADDRESS Notify 1569 Payload, when it wants to ADD or REMOVE one IP address to the SA 1570 specified by the SELECTORs. The draft does not consider the case of 1571 the IKE_SA, since we consider that the IKEv2 application does not 1572 support Simultaneous use of multiple IP addresses. In the draft, we 1573 consider that if an IKE_SA is specified by the SELECTORs, then the 1574 Multihoming actions are simply skipped. 1576 The Notify Payloads only need to specify one single IP address, i.e 1577 the IP address to be ADDed or REMOVEd to or from the SA. This IP 1578 address can be explicitly specified using the IP parameter, or 1579 implicitly specified. When the IP address is implicitly specified, 1580 no IP parameters are specified in the data field. The Responder 1581 assume the IP address to be considered is the one in the IP header. 1583 When the IP is specified, then the ADD or REMOVE action can be 1584 CHECKed, which means that the Initiator does not expect the change to 1585 be performed. Of course, when the IP address is implicitly 1586 specified, the Responder considers that the ADD or REMOVE operation 1587 MUST occur. 1589 When the IP address is specified, the I and H bits indicates, where 1590 the IP address MUST be ADDEd or UPDATEd -- in IP Header in transport 1591 or tunnel mode, or inside the tunnel when the tunnel mode is used. 1592 Of course, such bits cannot be specified when the IP address is 1593 implicitly specified. In that case, the Responder ADDs or REMOVE any 1594 IP address in the IP Header of tunnel and transport mode -- that is 1595 to say not the inner IP addresses. 1597 As with the UPDATE_SA_ADDRESSES Notify Payload, when the Responder 1598 receives it, it does not have to check if that is the last received 1599 Notify Payload. 1601 When the Responder receives an ADD_SA_ADDRESS or a REMOVE_SA_ADDRESS 1602 Notify Payload, it checks if the data field is formatted correctly or 1603 not. If other parameters then ID or IP parameter is specified or 1604 more then one IP parameter is specified, an UNACCEPTABLE_PARAMETER 1605 Notify Payload is sent as a response. If the data field does not 1606 carry one IP parameter, the Responder considers the IP address in the 1607 IP header of the received message, the operation has to be performed, 1608 and I bit is set to zero, H bit is set to 1. If the IP address is 1609 specified in the data field, the Responder reads the CHECK bit, the I 1610 bit and H bit values. Then the Responder performs a check-policy 1611 operation. 1613 When an ADD action is requested, then the Responder MUST check if the 1614 new IP address matches local and Security Policies. If the IP 1615 address does not match local policies, then an 1616 UNACCEPTABLE_IP_ADDRESS Notify Payload is sent as a response. If the 1617 IP address does not match the Security Policy, then a 1618 DOES_NOT_FIT_SPD Notify Payload is sent as a response. When a REMOVE 1619 action is requested, the Responder checks at least one IP address is 1620 still associated to the SA, if there is only one IP address 1621 associated to the SA, then REMOVing it will close the SA. 1623 7.7. Multihoming Exchanges State Diagrams 1625 Multihoming Actions are very similar as UPDATE actions. 1627 +------------------------+ 1628 | MOBIKE-X_SUPPORTED | RESPONDER 1629 +------------------------+ 1630 | 1631 +<---- ADD_SA_ADDRESS 1632 | received 1633 | NO 1634 ADD_SA_ADDRESS has one --------------+ 1635 and only one ID parameters ? v NO 1636 | YES There is no ID parameter ? ----+ 1637 ID_PARAM=ID ID_PARAM=VOID YES | 1638 | | v 1639 +<---------------------------+RESPONSE = UNACCEPTABLE 1640 | ID_PARAMETER 1641 Has the ADD_SA_ADDRESS -------------+ Insert ID_PARAM ----+ 1642 no IP parameters ? NO v | 1643 | YES Has the ADD_SA_ADDRESS one ----+ | 1644 Set IP= IPHEADER.IP_src and only one IP parameter ? NO| | 1645 | | YES | | 1646 | Check CHECK, I and H | | 1647 Set CHECK=0, I=0, H=1 bits value ? v | 1648 | | RESPONSE=UNACCEPTABLE| 1649 +<--------------------------+ ADD_SA_ADDRESS | 1650 | PARAMETER | 1651 IP fits local policies ? -----------------+ Insert ID_PARAM --+ | 1652 | YES NO v | | 1653 | RESPONSE=UNACCEPTABLE_ADDRESS | | 1654 | Insert ID_PARAM ----------+ | | 1655 IP fits SPD ? --------------------------+ | | | 1656 | YES NO v | | | 1657 ADD IP to the SA RESPONSE=DOES_NOT_FIT_SPD | | | 1658 where SELECTOR indicates it Insert ID_PARAM | | | 1659 | YES | | | | 1660 RESPONSE=VOID | | | | 1661 | | | | | 1662 +<--------------------------+<-------------+<---+<-+ 1663 Send RESPONSE 1664 | 1665 +------------------------+ 1666 | MOBIKE-X_SUPPORTED | 1667 +------------------------+ 1669 Responder : Receiving ADD_SA_ADDRESS 1671 +------------------------+ 1672 | MOBIKE-X_SUPPORTED | RESPONDER 1673 +------------------------+ 1674 | 1675 +<---- REMOVE_SA_ADDRESS 1676 | received 1677 | NO 1678 REMOVE_SA_ADDRESS has one --------------+ 1679 and only one ID parameters ? v NO 1680 | YES There is no ID parameter ? ----+ 1681 ID_PARAM=ID ID_PARAM=VOID YES | 1682 | | v 1683 +<---------------------------+RESPONSE = UNACCEPTABLE 1684 | ID_PARAMETER 1685 Has the REMOVE_SA_ADDRESS -------------+ Insert ID_PARAM -----+ 1686 no IP parameters ? NO v | 1687 | YES Has REMOVE_SA_ADDRESS one ----+ | 1688 Set IP= IPHEADER.IP_src and only one IP parameter ? NO| | 1689 | | YES | | 1690 | Check CHECK, I and H | | 1691 Set CHECK=0, I=0, H=1 bits value ? | | 1692 | | v | 1693 +<--------------------------+ RESPONSE=UNACCEPTABLE| 1694 | YES ADD_SA_ADDRESS | 1695 ADD IP to the SA PARAMETER | 1696 where SELECTOR indicates it Insert ID_PARAM | 1697 | YES | | 1698 RESPONSE=VOID | | 1699 | | | 1700 +<------------------------------------+<-----------+ 1701 Send RESPONSE 1702 | 1703 +------------------------+ 1704 | MOBIKE-X_SUPPORTED | 1705 +------------------------+ 1707 Responder : Receiving REMOVE_SA_ADDRESS 1709 8. SELECTOR Notify Payload 1711 The SELECTOR payloads are used to select one, a set of SA or IKE_SA 1712 where an ACTION MUST occur. ACTIONs are represented by the 1713 UPDATE_SA_ADDRESSES, ADD_SA_ADDRESS, REMOVE_SA_ADDRESS or 1714 ADDITIONAL_IP_ADDRESS Notify Payloads. The Initiator might use more 1715 than one SELECTOR that constitutes a SELECTOR_SET. The Initiator has 1716 to build the SELECTOR_SET carefully according to the considered 1717 Notify Payload that follows SELECTOR_SET. 1719 A SELECTOR_SET is a collection of SELECTOR Notify Payloads. An SA or 1720 an IKE_SA matches the SELECTOR_SET if a match occurs with at least 1721 one SELECTOR of the SELECTOR_SET. A SELECTOR Notify Payload carries 1722 different parameters. An SA or an IKE_SA matches a SELECTOR if all 1723 parameters of the SELECTOR Notify Payload match the SA or the IKE_SA. 1724 By default the SELECTOR value is IKE_SA_AND_CHILD_SA. In this 1725 document, this means that UPDATE_SA_ADDRESSES, ADD/REMOVE_SA_ADDRESS 1726 Notify Payload apply to the IKE_SA and the CHILD SAs, and the 1727 ADDTIONAL_IP_ADDRESS applies to the IKE_SA. 1729 The SELECTOR_SET precedes the action -- that is to say the 1730 UPDATE_SA_ADDRESSES, the ADD/REMOVE_SA_ADDRESS or the 1731 ADDITIONAL_IP_ADDRESS Notify Payloads. There can be multiple action 1732 Notify Payloads, and all of them apply to the SAs or IKE_SA that 1733 matches the SELECTOR_SET. 1735 To specify that the SELECTOR_SET MUST NOT be considered anymore, the 1736 Initiator MUST add an END_OF_SELECTOR Notify Payload. If an action 1737 Notify Payload is placed right after the END_OF_SELECTOR Notify 1738 Payload, then there is no SELECTOR_SET specified for this action and 1739 the default value is consider -- IKE_SA_AND_CHILD_SA or IKE_SA. On 1740 the other hand, another SELECTOR_SET can also be defined after the 1741 END_OF_SELECTOR Notify Payload. 1743 When a SELECTOR_SET is defined, any other Notify Payload different 1744 from UPDATE_SA_ADDRESSES or ADDITIONAL_IP_ADDRESS Notify Payload 1745 remove the SELECTOR_SET and set it to its default value. 1747 The SELECTOR_SET is a regular expression like, and can be modelized 1748 as SELECTOR_SET = SELECTOR_1 OR ... OR SELECTOR_n. . A match with 1749 the SELECTOR_SET occurs with an IKE_SA or an SA, if there is a match 1750 with SELECTOR_1 OR ... OR a match occurs with SELECTOR_n. If 1751 SELECTOR_i has k PARAMETERs, then a match occurs with SELECTOR_i and 1752 IKE_SA or a SA if a match occurs with PARAMETER_1 AND ... AND a 1753 match occurs with PARAMETERS_k. 1755 The initiator sending a SELECTOR Notify Payload it is recommended the 1756 Initiator proceeds as mentioned below : 1758 - 1 : When the Initiator wants to send actions, it SHOULD check to 1759 which SA or IKE_SA the action has to be proceeded. The 1760 different SAs or IKE_SA can be described with different 1761 SELECTOR. If no selectors applied, the default value is 1762 IKE_SA_AND_CHILD_SA. The Initiator either has set its 1763 SELECTOR_SET or consider the default values. 1765 - 2 : The Initiator might group the different actions that matches 1766 the same SELECTOR_SET. There are many way the different 1767 actions can be bound to SELECTOR_SET and SELECTOR_SET adapted 1768 to the actions so that to reduce the number of payload or the 1769 size of the message sent. This is not specified in this paper. 1770 - 3 : The Initiator appends all the action to the SELECTOR_SET. 1771 - 4 : If a SELECTOR_SET is explicitly built, append an 1772 END_OF_SELECTOR Notify Payload. 1774 The procedure described here is what we thought was the simplest way 1775 to implement it and is not normative. There are possible 1776 optimizations since without SELECTOR specification the assumed 1777 default value is IKE_SA_AND_CHILD_SA. 1779 When receiving a SELECTOR Notify Payload, the Responder MUST proceed 1780 as described below. We define states for the SELECTOR_SET variable. 1781 The SELECTOR_SET state is NULL when it has not been initiated. In 1782 that case the Responder will have to consider the default values of 1783 the SELECTOR_SET. When the SELECTOR_SET is being built, it is in a 1784 START state. This means the SELECTOR_SET value is not yet fixed, but 1785 is on its way to be set. When the SELECTOR_SET value is set then its 1786 state is ESTABLIHED. When an error is encounter, like an unexpected 1787 Notify Payload found, an unknown parameter, or badly formed 1788 parameter, then the SELECTOR_SET sets a variable ERROR to 1. When 1789 the Responder receives a message, the SELECTOR_SET value is set to 1790 NULL and the ERROR variable is set to 0. 1792 - 1 : If the Notify Payload type are UPDATE_SA_ADDRESSES, 1793 ADD_SA_ADDRESS, REMOVE_SA_ADDRESS or ADDITIONAL_IP_ADDRESSES, 1794 then check the SELECTOR_SET state value. If the SELECTOR_SET 1795 state value is NULL then perform the action with the default 1796 value of the SELECTOR_SET -- IKE_SA or IKE_SA_AND_CHILD_SA. If 1797 the SELECTOR_SET state value is START, then the Responder sets 1798 the SELECTOR_SET state to ESTABLISHED, and applies the Notify 1799 Payload to the SA or IKE_SA specified by the SELECTOR_SET 1800 value. If the SELECTOR_SET state value is ESTABLISHED, apply 1801 the Notify Payload to the IKE_SA and SA specified by the 1802 SELECTOR_SET value. 1803 - 2 : If the Notify Payload is of type SELECTOR, then check the 1804 SELECTOR_SET state value. If the SELECTOR_SET state value is 1805 NULL, then set the SELECTOR_SET state value to START and 1806 consider the SELECTOR parameters, and add them to the 1807 SELECTOR_SET value. If the SELECTOR_SET state value is START 1808 then add the SELECTOR parameters to the SELECTOR_SET value. If 1809 the SELECTOR_SET state value is ESTABLISHED then clear the 1810 SELECTOR_SET value, create a new SELECTOR_SET value, set the 1811 SELECTOR_SET state value to START and add the parameters of the 1812 SELECTOR to the SELECTOR_SET value. 1814 - 3 : If the Notify Payload is of type END_OF_SELECTOR clear the 1815 SELECTOR_SET value and set the SELECTOR_SET state value to 1816 NULL. 1817 - 4 : If the Notify Payload is of any other type, or if the Payload 1818 is different from the Notify type, then clear the SELECTOR_SET 1819 value and set the SELECTOR_SET value to NULL. The Responder 1820 MUST send a UNEXPECTED_PAYLOAD_AFTER_SELECTOR Notify Payload, 1821 set the variable ERROR to 1 and skip the Payloads 1822 - 5 : When the Responder performs the action Notify Payloads and do 1823 not find any SA or IKE_SA it SHOULD send an 1824 UNMATCHED_SELECTOR_SET. 1825 - 6 : When the Responder finds an Notify Payload, it does not 1826 understand, it sends an error message as specified in [RFC4306] 1827 if the critical flag is set to one. No error message 1828 otherwise. The Responder MUST set the variable ERROR to 1 and 1829 go on analyzing Notify Payload. 1830 - 7 : When the Responder do not understand the parameters of a 1831 SELECTOR Notify Payload, it MUST send an error 1832 UNACCEPTABLE_SELECTOR_PARAMETER Notify Payload. It MUST set 1833 the ERROR variable to 1. 1834 - 8 : When the Responder performs an action and the ERROR variable 1835 is set to 0, it performs it in a regular way. When the ERROR 1836 variable is set to 1. 1837 - 9 : When the Responder performs an action and the ERROR variable 1838 is set to 0, it performs it in a regular way. When the ERROR 1839 variable is set to 1. 1841 9. SELECTOR State diagrams 1842 +------------------------+ INITIATOR 1843 | MOBIKE-X_SUPPORTED | 1844 +------------------------+ 1845 | 1846 +<--- Initiator sends an ACTION 1847 | and prepares the SELECTOR_SET 1848 Does the IKE_SA_AND_CHILD value for 1849 SELECTOR_SETapplies ? -------+ 1850 NO | YES | 1851 Select the concerned SA | 1852 (can be a list of SPI) | 1853 | | 1854 Append all SELECTOR | 1855 | | 1856 Append ACTION | 1857 | | 1858 Append END_OF_SELECTOR | 1859 | | 1860 +<------------------------------+ 1861 | 1862 Send All Notify Payloads 1863 | 1864 +--------------------------+ 1865 |ACTION_NOTIFY_PAYLOAD_SENT| 1866 +--------------------------+ 1868 Initiator : Handling with SELECTORs 1870 +--------------------+ SELECTOR_SET_VALUE= 1871 | MOBIKE-X_SUPPORTED | RESPONDER IKE_SA_AND_CHILD_SA 1872 +--------------------+ SELECTOR_STATE=NULL 1873 | NO ERROR=0 1874 Notify Payload ------------------+ 1875 is SELECTOR ? v NO 1876 YES | Notify Payload is --------------+ 1877 SELECTOR_STATE= -----+ ACTION ? v NO 1878 NULL ? | YES | NO Notify Payload is ---+ 1879 YES | | SELECTOR_STATE ------+ END_OF_SELECTOR ? | 1880 Create a new | =ESTABLISHED | YES | | 1881 SELECTOR_SET | Apply ACTION to | SELECTOR_STATE=NULL | 1882 Add SELECTOR Value | SELECTOR_SET ? | SELECTOR_SET_VALUE= | 1883 SELECTOR_STATE=START | | | IKE_SA_AND_CHILD_SA | 1884 | | +--------------------+| | | 1885 +--------------------+| | MOBIKE-X_SUPPORTED || +--------------------+| 1886 | MOBIKE-X_SUPPORTED || +--------------------+| | MOBIKE-X_SUPPORTED || 1887 +--------------------+| | +--------------------+| 1888 +---------+ +-----------+ +-------------+ 1889 v NO v NO v NO 1890 SELECTOR_STATE= -----+ SELECTOR_STATE= ---+ SELECTOR_STATE ------+ 1891 START ? | NULL ? | =START ? | 1892 YES | | YES | | | | 1893 Add SELECTOR Value | Apply ACTION to | SEND UNEXPECTED_ | 1894 | | SELECTOR_SET | PAYLOAD_AFTER_SELECTOR| 1895 +--------------------+| =IKE_SA_AND_CHILD_SA | ERROR=1 | 1896 | MOBIKE-X_SUPPORTED || | | | | 1897 +--------------------+| +--------------------+| +--------------------+| 1898 +---------+ | MOBIKE-X_SUPPORTED || | MOBIKE-X_SUPPORTED || 1899 v +--------------------+| +--------------------+| 1900 SELECTOR_STATE= (SELECTOR +-----------+ +-------------+ 1901 ESTABLISHED ? _STATE=START)| |(SELECTOR_STATE 1902 YES | v |=ESTABLISHED or 1903 Clear SELECTOR_SET SELECTOR_STATE= v= NULL) 1904 Set ERROR=0 ESTABLISHED SELECTOR_STATE=NULL 1905 Create new SELECTOR_SET Set SELECTOR_SET_VALUE ERROR=0 1906 Add SELECTOR Value Apply ACTION to | 1907 SELECTOR_STATE=START SELECTOR_SET +--------------------+ 1908 | | | MOBIKE-X_SUPPORTED | 1909 +--------------------+ +--------------------+ +--------------------+ 1910 | MOBIKE-X_SUPPORTED | | MOBIKE-X_SUPPORTED | 1911 +--------------------+ +--------------------+ 1913 Responder : Receiving SELECTOR Notify Payloads 1915 Add SELECTOR Value to SELECTOR_SET consists of check the SELECTOR 1916 syntax before adding it. If an error occurs, then the Responder set 1917 the ERROR value to 1. 1919 Apply ACTION to SELECTOR_SET consists of checking the ERROR value of 1920 SELECTOR_SET. If ERROR is set to 1, then the ACTION is not performed 1921 and a UNEXPECTED_PARAMETER Notify Payload is returned. When the 1922 ACTION cannot be performed because no SA matches the SELECTORs, then 1923 an UNMATCHED_SELECTOR_SET Notify Payload is sent. This latest Notify 1924 Payload is more a warning message than an error message. 1926 10. ID Notify Payload Parameter 1928 The ID parameter purpose is to bind a query Notify Payload to the 1929 response Notify Payload. An Initiator can send multiple Notify 1930 Payload, some of them might require a response for example if the 1931 Notify Payload generating an error. When the Responder receives a 1932 Notify Payload with an ID parameter in its data field, which requires 1933 a response, it MUST insert the ID parameter in its response Payload. 1935 It is the responsibility of the Initiator to make sure the ID 1936 parameters are different, so that it can easily bind the response 1937 with the query Notify Payload. 1939 11. Packet Format 1941 11.1. Notify Payload 1943 The Notify Payload is define in[RFC4306] section 3.10. This Notify 1944 Payload is represented as below : 1946 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 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 ! Next Payload !C! RESERVED ! Payload Length ! 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 ! Protocol ID ! SPI Size ! Notify Message Type ! 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 ! ! 1953 ~ Security Parameter Index (SPI) ~ 1954 ! ! 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 ! ! 1957 ~ Notification Data ~ 1958 ! ! 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 Notify Payload 1963 In our case, we would fill the different fields as defined below : 1965 - Protocol ID (1 octet) : As mentioned in [RFC4306] "If this 1966 notification concerns an existing SA, this field indicates the 1967 type of that SA. For IKE_SA notifications, this field MUST be 1968 one (1). For notifications concerning IPsec SAs this field 1969 MUST contain either (2) to indicate AH or (3) to indicate ESP. 1970 For notifications that do not relate to an existing SA, this 1971 field MUST be sent as zero and MUST be ignored on receipt. All 1972 other values for this field are reserved to IANA for future 1973 assignment." In our case the Protocol is 1, since it is 1974 related to the IKE_SA 1975 - SPI Size (1 octet) : [RFC4306] mentions "h in octets of the SPI 1976 as defined by the IPsec protocol ID or zero if no SPI is 1977 applicable. For a notification concerning the IKE_SA, the SPI 1978 Size MUST be zero.". In our case the SPI is set to zero. 1979 - Notify Message Type (2 octets) : [RFC4306] mentions "Specifies 1980 the type of notification message." 1981 - SPI (variable length) [RFC4306] mentions "Security Parameter 1982 Index." In our case this field should not appear. 1983 - Notification Data (variable length) [RFC4306] mentions 1984 "Informational or error data transmitted in addition to the 1985 Notify Message Type. Values for this field are type specific 1986 (see below)." 1988 11.2. Notify Message -- status type 1990 In this section we provide assignment numbers for the different Type 1991 of Notify Payloads. Such numbers are added to the list provided by 1992 the IANA at http://www.iana.org/assignments/ikev2-parameters. 1994 11.2.1. MOBIKE_SUPPORTED 1996 The MOBIKE_SUPPORTED Notify Payload MUST carry the VERSION parameter. 1997 They can be one or more VERSION parameter payload. The VERSION value 1998 for MOBIKE [RFC4555] is 1. The VERSION value for MOBIKE-X as defined 1999 in this draft is 2. The Protocol ID and SPI Size fields are set to 2000 zero. 2002 The Notify Message Type for MOBIKE_SUPPORTED is defined in [RFC4555] 2003 and the Type code is 16396. 2005 11.2.2. ADDITIONAL_IP_ADDRESS 2007 The ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS are defined in 2008 MOBIKE [RFC4555], and type codes are 16397 and 16398. In this 2009 document, we consider only ADDITIONAL_IP6_ADDRESS as 2010 ADDITIONAL_IP_ADDRESS, so its type is 16398. 2012 11.2.3. NO_ADDITIONAL_ADDRESS 2014 The NO_ADDITIONAL_ADDRESS is defined in [RFC4555] and the type code 2015 is 16399. 2017 11.2.4. SELECTOR 2019 The SELECTOR Notify Payload is used to define who the 2020 ADDITIONAL_IP_ADDRESS, the UPDATE_SA_ADDRESSES. The Notify Message 2021 Type for SELECTOR is 40961 -- We define it as private use number but 2022 it should be assigned by the IANA. 2024 The SELECTOR Payload MUST carry selectors parameters in its data 2025 payload. The currently supported parameters are IP, SPI, 2026 IKE_AND_CHILD_SA and ALL_IKE_SA. 2028 11.2.5. END_OF_SELECTOR 2030 The END_OF_SELECTOR defines where the SELECTOR_SET stop being used. 2031 The Notify Message Type for SELECTOR is 40962. 2033 11.2.6. UPDATE_SA_ADDRESSES 2035 The UPDATE_SA_ADDRESSES is described in [RFC4555] and in this paper. 2036 The type code is 16400. The main difference between description in 2037 [RFC4555] and this paper is the UPDATE_SA_ADDRESSES Notify Payload 2038 can carry the NEW_IP and the OLD_IP address as parameters in its data 2039 field. 2041 11.2.7. ADD_SA_ADDRESS Notify Payload 2043 The ADD_SA_ADDRESS requests the Responder to ADD an IP address to an 2044 associated SA. The type code is 40962. This Notify Payload can 2045 specify the IP address to ADD. 2047 11.2.8. REMOVE_SA_ADDRESS Notify Payload 2049 The REMOPE_SA_ADDRESS requests the Responder to REMOVE an IP address 2050 to an associated SA. The type code is 40963. This Notify Payload 2051 can specify the IP address to ADD. 2053 11.2.9. Notify Message -- status type table 2054 Name Value Reference 2055 ---- ----- --------- 2056 MOBIKE_SUPPORTED 16396 [RFC4555] 2057 SELECTOR 40961 2058 END_OF_SELECTOR 40962 2059 ADDITIONAL_IP_ADDRESS 16398 [RFC4555] 2060 NO_ADDITIONAL_ADDRESS 16399 [RFC4555] 2061 UPDATE_SA_ADDRESSES 16400 [RFC4555] 2062 ADD_SA_ADDRESS 40963 2063 REMOVE_SA_ADDRESS 40964 2065 Notify Message -- status type -- Private values 2067 11.3. Notify Message -- error type 2069 11.3.1. MOBIKE_UNSUPPORTED_VERSION 2071 This Notify Payload is used by the Responder to indicate, it does not 2072 understand the MOBIKE version proposed by the Initiator. When 2073 sending this Notify Payload, the Responder MUST add the supported 2074 version of MOBIKE it supports. This Notify Payload can also be used 2075 to cancel the use of MOBIKE-X. In that specific case, the version 2076 number is NONE. 2078 The Type value associated to this message is the first value of 2079 Notify Message error type value assigned for private use, that is to 2080 say : 8192. 2082 11.3.2. UNACCEPTABLE_ADDRESS 2084 This Notify Payload is defined in [RFC4555]. This Notify Payload is 2085 sent by the Responder when it cannot accept the IP address specified 2086 in an UPDATE_SA_ADDRESSES. This Notify Payload MUST be sent when the 2087 IP address does not match the local policies. More specifically it 2088 cannot be used instead of a DOES_NOT_FIT_SPD Notify Payload. The 2089 UNACCEPTABLE_ADDRESS type value is 40 as specified in [RFC4555]. 2091 11.3.3. DOES_NOT_FIT_SPD 2093 This message MUST be send by the Responder when the proposed IP 2094 address is reject by the SPD. The type value associated to the 2095 message is 8193. 2097 11.3.4. UNACCEPTABLE_PARAMETERS 2099 This message MUST be sent as response when parameters are not well 2100 understood by the Responder. 2102 11.3.5. UNEXPECTED_PAYLOAD_AFTER_SELECTOR 2104 The message is sent when the responder does not find a expected 2105 payload after the SELECTOR payload. It is more a warning message 2106 then an error message. The type value associated to it is 8195. 2108 11.3.6. UNMATCHED_SELECTOR_SET 2110 This message MUST be sent when no SA matches the mentioned 2111 SELECTOR_SET. The type value associated to the message is 8196. 2113 11.3.7. Notify Message -- error type table 2115 Name Value Reference 2116 ---- ----- --------- 2117 MOBIKE_UNSUPPORTED_VERSION 8192 2118 UNACCEPTABLE_ADDRESS 40 [RFC4555] 2119 DOES_NOT_FIT_SPD 8193 2120 UNACCEPTABLE_PARAMETER 8194 2121 UNEXPECTED_PAYLOAD_AFTER_SELECTOR 8195 2122 UNMATCHED_SELECTOR_SET 8196 2124 Notify Message -- error type -- Private values 2126 11.4. Notify Parameters 2128 11.4.1. VERSION 2130 1 2 3 2131 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 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 | TYPE | NBR | VERS | VERS | 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | | 2136 ~ ~ 2137 | | 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 | VERS | VERS | PADDING | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 VERSION parameter 2144 Where : 2146 TYPE : 16 bits to define the VERSION parameter (1) 2147 NBR : 8 bits to define the number of proposed version. This field 2148 defines the where the PADDING bits starts as well as the length 2149 of the PADDING field. 2150 VERS : 8 bits to define the version number. MOBIKE is being 2151 assigned the version number 1, the current description in this 2152 paper is being assigned the version number 2. The NONE value 2153 MUST be only carried by the MOBIKE-X_UNSUPPORTED Notify 2154 Payload, and means that MOBIKE-X messages MUST NOT be anymore 2155 considered. 2156 PADDING : 8, 16 or 24 bits set to zero. The PADDING length is such 2157 that the VERSION parameter length is a multiple of 32 bits. 2158 Its length is derived from NBR. Consider L = (NBR+1) %4. This 2159 value represents the PADDING number of bytes. 2161 Name Value Reference 2162 ---- ----- --------- 2163 Reserved 0 2164 MOBIKE 1 2165 MOBIKE-X 2 2166 Reserved to IANA 3-254 2167 NONE 255 2169 VERSION 2171 11.4.2. SPI 2173 1 2 3 2174 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 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | TYPE | SPI_SIZE | RESERVED | 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | | 2179 ~ SPI ~ 2180 | | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 SPI size 2185 Where : 2187 TYPE : 8 bits to define the SPI parameter. 2189 SPI_SIZE : 8 bits to define the size of the SPI. The size is 2190 expressed in number of bytes. 2191 RESERVED : 16 bits set to zero and reserved for future use. 2192 SPI : the SPI value. 2194 11.4.3. IP 2196 1 2 3 2197 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 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 | TYPE |M| V |C|O|N|H|I| RESERVED | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | Multihoming Information (optional) | 2202 | | 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | | 2205 ~ IP address value : IPv4 or IPv6 ~ 2206 | | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 IP 2211 Where : 2213 TYPE : 8 bits to define the IP parameter. 2214 M (Multihoming) bit : 1 bit that specifies whether Multihoming 2215 Information Payload (MIP) is present in the IP parameter. M 2216 set to 1 means that the MIP is present; otherwise M is set to 2217 0. This bit is not optional and its value MUST be set 2218 properly. 2219 V (Version) bits : 2 bits that specifies the version of the IP 2220 address. . V set to 0 means the IP is an IPv4, V set to 1 2221 means the IP is an IPv6. Those bits MUST be set properly and 2222 their value is not optional. 2223 C (CHECK) bit : 1 bit that specifies the Initiator does not want 2224 the action to be performed but does only want to check the IP 2225 address matches local and security policies. When this bit is 2226 set to 1, then the ACTION is only CHECKed, otherwise, the 2227 ACTION is performed. 2228 O (Old) bit : 1 bit that specifies that the IP address is 2229 considered as the OLD_IP, that is to say the address to 2230 replace. To specify the IP parameter is an OLD_IP, the bit 2231 MUST be set to 1. O bit or N bit MUST be used when the IP 2232 address is a parameter of the UPDATE_SA_ADDRESSES Notify 2233 Payload. Other ACTION ignores those bits. If both OLD_IP and 2234 NEW_IP are explicitly specified and the CHECK bit has not the 2235 same value in both IP parameter, then a UNACCEPTABLE_PARAMETER 2236 will be sent by the Responder. 2237 N (New) bit : 1 bit that specifies that the IP address is 2238 considered as the NEW_IP, that is to say the value replacing 2239 the OLD_IP. To specify the IP parameter is a NEW_IP, the N bit 2240 MUST be set to 1. (see O bit for more information). 2241 H (IP Header) bit : 1 bit that specifies the IP address is use for 2242 routing purpose. If the SA is using the transport mode, then 2243 setting H to 1 means the IP address has to be considered. If 2244 the SA is using the tunnel mode, the outer IP address is 2245 considered. The H and I bits are not optional and MUST be set 2246 for ADD, REMOVE and UPDATE actions. ADDITIONAL_IP_ADDRESS 2247 assumes H=1, I=0. 2248 I (Inner IP) bit : 1 bit that specifies the IP address is a inner 2249 IP address. When set to 1, it means the IP address is the 2250 inner IP address of a tunnel mode. (see the H bit for more 2251 explanation). 2252 RESERVED : 16 bits set to zero and reserved for future. 2253 IP4 : 32 bits to define the IPv4 address. 2254 IP6 : 128 bits to define the IPv6 address. 2256 Name Value Reference 2257 ---- ----- --------- 2258 IPv6 0 2259 IPv4 1 2260 Reserved to IANA 2-3 2262 Version 2264 11.4.4. Multihoming Information Payload (MIP) 2266 This section defines the Multihoming Information Payload. 2267 Multihoming Information can be useful for Multihoming purposes. That 2268 is to say such information is only useful for multihoming management 2269 entity. In this document the only Multihoming Management Entity is 2270 the IKEv2 application. In fact we do not consider here communication 2271 between IKEv2 and ULP. As a result, the MIP SHOULD be only used 2272 associated with ADDITIONAL_IP_ADDRESS Notify Payload. 2274 1 2 3 2275 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 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | PREFERENCE | CLASS | R | RESERVED | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | IP address Start Time | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | IP address Life Time | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 Multihoming Information Payload 2286 Where : 2288 PREFERENCE : 8 bits preference associated to every IP addresses in 2289 the range. The PREFERENCE bits are especially useful to select 2290 the more adequate IP address. 2291 CLASS : 8 bits the class of the IP, that is to say specify whether 2292 the IP address is a HoA, a CoA when using MIP6, or NONE when 2293 the IP address has no specific class value. If there is no 2294 class associated to the IP address, then the class field MUST 2295 be set to NONE. 2296 R (Reachability) : 2 bits that specifies is the peer is reachable 2297 with this IP address, or not. NO_INFO means the Initiator does 2298 not have specific information on the reachability of the IP 2299 address. This is the default value. 2300 RESERVED : 15 bits set to zero and reserved for future. 2301 IP address Start Time : 32 bits that indicates the time the 2302 Responder SHOULD wait after it has received the IP parameter 2303 before considering it. This time expresses the number of 2304 seconds the Responder has to wait. By default, the Initiator 2305 should set it to zero. 2306 IP address Life Time : 32 bits that specifies how long the data is 2307 valid. A zero value means an infinite number of seconds. 2309 Name Value Reference 2310 ---- ----- --------- 2311 NONE 0 2312 HoA 1 2313 CoA 2 2314 Reserved to IANA 3-255 2316 CLASS 2318 Name Value Reference 2319 ---- ----- --------- 2320 NO_INFO 0 2321 REACHABLE 1 2322 UNREACHABLE 2 2323 Reserved to IANA 4 2325 R 2327 11.4.5. IPSEC_MODE 2329 1 2 3 2330 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 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 | TYPE | IPSEC_MODE | RESERVED | 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 IPSEC_MODE 2337 Where : 2339 TYPE : 8 bits to define the IPSEC_MODE parameter. 2340 IPSEC_MODE : 8 bits the IPsec mode to consider. Encapsulation Mode 2341 is defined in [RFC2407] and in 2342 http://www.iana.org/assignments/isakmp-registry. 2343 RESERVED : 16 bits set to zero and reserved for future. 2345 From http://www.iana.org/assignments/isakmp-registry, we get the 2346 following values : 2348 Name Value Reference 2349 ---- ----- --------- 2350 Reserved 0 [RFC2407] 2351 Tunnel 1 [RFC2407] 2352 Transport 2 [RFC2407] 2353 UDP-Encapsulated-Tunnel 3 [RFC3947] 2354 UDP-Encapsulated-Transport 4 [RFC3947] 2356 Values 3-61439 are reserved to IANA. Values 61440-65535 are 2357 for private use. 2359 IPSEC_MODE 2361 11.4.6. IPSEC_PROTO 2363 1 2 3 2364 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 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2366 | TYPE | IPSEC_PROTO | RESERVED | 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2369 IPSEC_PROTO 2371 Where : 2373 TYPE : 8 bits to define the IPSEC_PROTO parameter. 2374 IPSEC_MODE : 8 bits the IPsec protocol to consider. Protocols are 2375 defined [RFC4306] and in 2376 http://www.iana.org/assignments/ikev2-parameters 2377 RESERVED : 16 bits set to zero and reserved for future. 2379 From http://www.iana.org/assignments/ikev2-parameters, we get the 2380 following values : 2382 Protocol ID Protocol Reference 2383 ----------- ---------------------- --------- 2384 0 Reserved [RFC4306] 2385 1 IKE [RFC4306] 2386 2 AH [RFC4306] 2387 3 ESP [RFC4306] 2388 4 FC_ESP_HEADER [RFC4595] 2389 5 FC_CT_AUTHENTICATION [RFC4595] 2390 6-200 Unassigned [RFC4306] 2391 201-255 Private use [RFC4306] 2393 Registry Name: IKEv2 Traffic Selector Types 2394 Reference: [RFC4306] 2395 Registration Procedures: Expert Review 2397 IPSEC_PROTO 2399 11.4.7. SELECTOR_SPECIFIC_VALUE_PARAMETER 2401 1 2 3 2402 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 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 | TYPE | VALUE | RESERVED | 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 SELECTOR_SPECIFIC_VALUE_PARAMETER 2409 Where : 2411 TYPE : 8 bits to define the SELECTOR_PARAMETER parameter. 2412 VALUE : 8 bits that specifies special SELECTORS values. 2413 RESERVED : 16 bits set to zero and reserved for future. 2415 The different values for VALUES are the following : 2417 SELECTOR 2418 VALUES Protocol Reference 2419 ----------- ---------------------- --------- 2420 0 Reserved 2421 2 IKESA_AND_CHILD_SA 2422 3 ALL_IKE_SA 2423 4-255 Reserved to IANA 2425 SELECTOR_SPECIFIC_VALUE_PARAMETER 2427 11.4.8. ID 2429 1 2 3 2430 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 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | TYPE | RESERVED | IDENTIFIER | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2435 ID parameter 2437 Where : 2439 TYPE : 16 bits to define the VERSION parameter. 2440 RESERVED : 8 bits set to zero and reserved for future. 2441 IDENTIFIER : 16 bits The identifier for the Notify Payload. The 2442 identifier does not need to be chosen randomly, and do not 2443 intend to provide any protection, it only reason is to 2444 distinguish different Notify Payloads. 2446 11.4.9. Parameter Code Type 2448 Registry: 2449 Value NOTIFY PARAMETER - MOBIKE-X Reference 2450 ------------ ---------------------------- --------- 2451 0 Reserved 2452 1 VERSION 2453 2 SPI 2454 3 IP 2455 4 IPSEC_MODE 2456 5 IPSEC_PROTO 2457 6 SELECTOR_SPECIFIC_VALUE_PARAMETER 2458 7 ID 2459 8-255 Reserved to IANA 2461 Parameter code types 2463 12. Security Considerations 2465 Security considerations are the same as those expressed in MOBIKE 2466 [RFC4555]. This document extends the Security Associations 2467 manipulation. More specifically, with the use of SELECTORs payloads, 2468 one user can select a random SPI, or other IKE_SAs. For this reason, 2469 we recommend that unless specified otherwise for special uses, the 2470 SELECTORs SHOULD apply to only a subset of Security Associations. 2471 The subset of Security Association is Security Association that has 2472 been negotiated between the same peer's ID and with the same 2473 authentication method. By doing so, we protect peer from weak 2474 authentication method. An attacker will not be able to hijack a 2475 peer's identity using a weak authentication method. We also prevent, 2476 a peer to interfere with others peer Security Associations. 2478 13. IANA Considerations 2480 The new Notify Message status Type to be added are : 2482 Name Value Reference 2483 ---- ----- --------- 2484 SELECTOR 40961 2485 END_OF_SELECTOR 40962 2487 Notify Message -- status type -- Private values 2489 The new Notify Message error Type to be added are : 2491 Name Value Reference 2492 ---- ----- --------- 2493 MOBIKE_UNSUPPORTED_VERSION 8192 2494 DOES_NOT_FIT_SPD 8193 2495 UNACCEPTABLE_PARAMETER 8194 2496 UNEXPECTED_PAYLOAD_AFTER_SELECTOR 8195 2497 UNMATCHED_SELECTOR_SET 8196 2499 Notify Message -- error type -- Private values 2501 A New field is created : MOBIKE-X parameters. The following values 2502 are : 2504 Registry: 2505 Value NOTIFY PARAMETER - MOBIKE-X Reference 2506 ------------ ---------------------------- --------- 2507 0 Reserved 2508 1 VERSION 2509 2 SPI 2510 3 IP 2511 4 IPSEC_MODE 2512 5 IPSEC_PROTO 2513 6 SELECTOR_SPECIFIC_VALUE_PARAMETER 2514 7 ID 2516 MOBIKE-X PARAMETERS 2518 A New field is created : SELECTOR_VALUE parameters. The following 2519 values are : 2521 SELECTOR 2522 VALUES Protocol Reference 2523 ----------- ---------------------- --------- 2524 0 Reserved 2525 2 IKESA_AND_CHILD_SA 2526 3 ALL_IKE_SA 2527 4-255 Reserved to IANA 2529 SELECTOR_PARAMETER 2531 Name Value Reference 2532 ---- ----- --------- 2533 NONE 0 2534 HoA 1 2535 CoA 2 2536 Reserved to IANA 3-255 2538 CLASS 2540 Name Value Reference 2541 ---- ----- --------- 2542 NO_INFO 0 2543 REACHABLE 1 2544 Unreachable 2 2545 Reserved to IANA 4 2547 R 2549 14. Acknowledgments 2551 Daniel Migault is partly funded by 3MING, a research project 2552 supported by the French 'National Research Agency'(ANR). 2554 15. References 2556 15.1. Normative References 2558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2559 Requirement Levels", BCP 14, RFC 2119, March 1997. 2561 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2562 Internet Protocol", RFC 4301, December 2005. 2564 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2565 RFC 4306, December 2005. 2567 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 2568 (MOBIKE)", RFC 4555, June 2006. 2570 15.2. Informative References 2572 [I-D.mglt-ipsec-mm-requirements] 2573 Migault, D., "IPsec mobility and multihoming requirements 2574 : Problem statement", draft-mglt-ipsec-mm-requirements-00 2575 (work in progress), September 2009. 2577 [RFC2407] Piper, D., "The Internet IP Security Domain of 2578 Interpretation for ISAKMP", RFC 2407, November 1998. 2580 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 2581 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 2582 January 2005. 2584 [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel 2585 Security Association Management Protocol", RFC 4595, 2586 July 2006. 2588 Author's Address 2590 Daniel Migault 2591 Orange Labs R&D 2592 38 rue du General Leclerc 2593 92794 Issy-les-Moulineaux Cedex 9 2594 France 2596 Phone: +33 1 45 29 60 52 2597 Email: mglt.ietf@gmail.com