IPSECME Working Group D. Migault Internet-Draft Orange Labs R&D Intended status: Standards Track September 2009 Expires: March 5, 2010 MOBIKE eXtension (MOBIKE-X) for Transport Mobility and Multihomed IKE_SA draft-mglt-ipsec-mm-mobikex-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 5, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This draft provides a description of MOBIKE mobility and multihoming extension (MOBIKE-X). The extension is elaborated from the MOBIKE [RFC4555] protocol as well as mobility and multihoming requirements Migault Expires March 5, 2010 [Page 1] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 described in [I-D.mglt-ipsec-mm-requirements]. Extension concerns the Security Association facilities in a multihoming and mobile environment. More specifically this draft considers the use of multiple interfaces and the transport mode of IPsec. One of the goal of this draft was to make this extension compatible with MOBIKE [RFC4555]. We especially point out the differences from MOBIKE [RFC4555], as well as how its interacts with MOBIKE. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. MOBIKE-X Protocol overview . . . . . . . . . . . . . . . . . . 8 5.1. UPDATE action . . . . . . . . . . . . . . . . . . . . . . 8 5.2. ADD and REMOVE actions . . . . . . . . . . . . . . . . . . 9 5.3. Response to a CHECK Request . . . . . . . . . . . . . . . 10 5.4. SELECTing the SA . . . . . . . . . . . . . . . . . . . . . 10 5.5. Alternate IP Address . . . . . . . . . . . . . . . . . . . 10 5.6. MOBIKE Version . . . . . . . . . . . . . . . . . . . . . . 11 5.7. Other Considerations . . . . . . . . . . . . . . . . . . . 11 6. Notify Payload Description . . . . . . . . . . . . . . . . . . 12 6.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 12 6.2. MOBIKE_UNSUPPORTED_VERSION Notify Payload . . . . . . . . 12 6.3. SELECTOR Notify Payload . . . . . . . . . . . . . . . . . 13 6.4. END_OF_SELECTOR Notify Payload . . . . . . . . . . . . . . 13 6.5. ADDITIONAL_IP_ADDRESS Notify Payload . . . . . . . . . . . 13 6.6. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 14 6.7. ADD_SA_ADDRESS Notify Payload . . . . . . . . . . . . . . 15 6.8. REMOVE_SA_ADDRESS Notify Payload . . . . . . . . . . . . . 16 7. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . . 17 7.1.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . 17 7.1.2. MOBIKE_UNSUPPORTED_VERSION Notify Payload . . . . . . 21 7.1.3. Initial exchange state diagrams . . . . . . . . . . . 21 7.2. Alternate IP Address Exchange . . . . . . . . . . . . . . 26 7.3. Alternate IP Address Exchange State Diagram . . . . . . . 27 7.4. UPDATE Exchange . . . . . . . . . . . . . . . . . . . . . 29 7.5. UPDATE Exchange State Diagram . . . . . . . . . . . . . . 32 7.6. Multihoming Exchanges . . . . . . . . . . . . . . . . . . 36 7.7. Multihoming Exchanges State Diagrams . . . . . . . . . . . 37 8. SELECTOR Notify Payload . . . . . . . . . . . . . . . . . . . 39 9. SELECTOR State diagrams . . . . . . . . . . . . . . . . . . . 42 10. ID Notify Payload Parameter . . . . . . . . . . . . . . . . . 45 11. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 45 11.1. Notify Payload . . . . . . . . . . . . . . . . . . . . . . 45 Migault Expires March 5, 2010 [Page 2] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 11.2. Notify Message -- status type . . . . . . . . . . . . . . 46 11.2.1. MOBIKE_SUPPORTED . . . . . . . . . . . . . . . . . . . 46 11.2.2. ADDITIONAL_IP_ADDRESS . . . . . . . . . . . . . . . . 46 11.2.3. NO_ADDITIONAL_ADDRESS . . . . . . . . . . . . . . . . 47 11.2.4. SELECTOR . . . . . . . . . . . . . . . . . . . . . . . 47 11.2.5. END_OF_SELECTOR . . . . . . . . . . . . . . . . . . . 47 11.2.6. UPDATE_SA_ADDRESSES . . . . . . . . . . . . . . . . . 47 11.2.7. ADD_SA_ADDRESS Notify Payload . . . . . . . . . . . . 47 11.2.8. REMOVE_SA_ADDRESS Notify Payload . . . . . . . . . . . 47 11.2.9. Notify Message -- status type table . . . . . . . . . 47 11.3. Notify Message -- error type . . . . . . . . . . . . . . . 48 11.3.1. MOBIKE_UNSUPPORTED_VERSION . . . . . . . . . . . . . . 48 11.3.2. UNACCEPTABLE_ADDRESS . . . . . . . . . . . . . . . . . 48 11.3.3. DOES_NOT_FIT_SPD . . . . . . . . . . . . . . . . . . . 48 11.3.4. UNACCEPTABLE_PARAMETERS . . . . . . . . . . . . . . . 48 11.3.5. UNEXPECTED_PAYLOAD_AFTER_SELECTOR . . . . . . . . . . 49 11.3.6. UNMATCHED_SELECTOR_SET . . . . . . . . . . . . . . . . 49 11.3.7. Notify Message -- error type table . . . . . . . . . . 49 11.4. Notify Parameters . . . . . . . . . . . . . . . . . . . . 49 11.4.1. VERSION . . . . . . . . . . . . . . . . . . . . . . . 49 11.4.2. SPI . . . . . . . . . . . . . . . . . . . . . . . . . 50 11.4.3. IP . . . . . . . . . . . . . . . . . . . . . . . . . . 51 11.4.4. Multihoming Information Payload (MIP) . . . . . . . . 52 11.4.5. IPSEC_MODE . . . . . . . . . . . . . . . . . . . . . . 54 11.4.6. IPSEC_PROTO . . . . . . . . . . . . . . . . . . . . . 54 11.4.7. SELECTOR_SPECIFIC_VALUE_PARAMETER . . . . . . . . . . 55 11.4.8. ID . . . . . . . . . . . . . . . . . . . . . . . . . . 56 11.4.9. Parameter Code Type . . . . . . . . . . . . . . . . . 56 12. Security Considerations . . . . . . . . . . . . . . . . . . . 57 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 15.1. Normative References . . . . . . . . . . . . . . . . . . . 59 15.2. Informative References . . . . . . . . . . . . . . . . . . 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 59 Migault Expires March 5, 2010 [Page 3] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology - Mobile Node (MN) : In this draft the Mobile Node is the peer that performs the mobility action. The Mobile Node does not have to be understood as in MIPv6. - Initiator : The Initiator is the peer that initiates the exchange. It sends a message to the Responder. It is important to note that if two peers are connected, the Initiator of one exchange can be the Responder of another exchange. When a mobility action is performed then the Initiator is also the Mobile Node. - Responder : The Responder is the peer receiving a message. The message is sent from the Initiator. - Alternate IP Address : The alternate IP address of a peer is the IP address a peer is not currently using but that might be used latter. An alternate IP address should used only if the current IP address does not work anymore. 3. Introduction This document provides a description of MOBIKE-X. We assume the reader is familiar with IPsec [RFC4301], IKEv2 [RFC4306] and with MOBIKE [RFC4555]. MOBIKE-X extends MOBIKE facilities to change the IP address of an IPsec Security Associations. More specifically, MOBIKE-X includes an IPsec Security Association using a transport mode. MOBIKE-X also extends the multihoming scope of MOBIKE, and considers that simultaneous IP addresses can be used between two peers. Combination of mobility and multihoming facilities provide IP address management facilities. This draft is mainly focused on the multihoming aspects of the IKEv2 channel. This draft does not provide any use cases. Use cases are described in [I-D.mglt-ipsec-mm-requirements]. This draft considers scenarios and requirements of [I-D.mglt-ipsec-mm- requirements]. From theses requirements, this document defines extensions to MOBIKE which includes new Notify Payloads, and parameters carried by Notify Payloads. MOBIKE [RFC4555] proposes a mobility solution for the tunnel mode. MOBIKE use case is a mobile node connected to an Intranet through a Migault Expires March 5, 2010 [Page 4] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 security gateway. For simplicity we consider that the security gateway is connected on the Internet and on a private network. The mobile node negotiates a connection with the security gateway using IKEv2. After the IKEv2 negotiation, the mobile node has a private IP address, and communicates with nodes on the Intranet by tunneling them to the security gateway. The outer IP addresses of the tunnel are the public IP addresses of the security gateway and of the mobile node. MOBIKE has been designed so that the mobile node can change its public IP address without breaking the Security Association between the inner IP addresses, negotiated with IKEv2. In other words, when the mobile node changes its public IP address MOBIKE avoids that the mobile node restarts a IKEv2 negotiation with the security gateway, proceeding to the IKE_SA_INIT, IKE_AUTH and CREATE_CHILD_SA exchanges. With the tunnel mode the selectors of the SPD and the SAD are the inner IP addresses. When outer addresses are changed, only some parameters of the SA are changed. More specifically, selectors of a given SA are kept unchanged during mobility. No new SA needs to be created and so SPD and PAD and their bindings with the SAD are kept unchanged. On the other hand, with the transport mode, the selectors of the SA are changed. When one host changes its IP address, and the SA is identified through its selectors, it MUST be changed. As a consequence, the SPD MUST also be changed, and the PAD MUST be checked to see if new SA can be created. MOBIKE considers that peer only has one interface. This brings simplification over what modification has to be done, and where the updates need to be performed. In fact if a node decides to perform a mobility action and has only one interface, then the other peer knows the new address is one being used by the Mobile Node, and the old IP address is the one that the MN used to use. If a peer is multihomed, the MN should be able to indicate what is the new IP address, and what is the old IP address -- that is to say the IP address to be replaced. MOBIKE also considers multihoming. The type of multihoming MOBIKE considers is the Alternate IP Addresses Multihoming (AM). This means that one peer can provide multiple IP addresses to the other peer, but those IP addresses MUST NOT be used unless the current IP address is not working anymore. In other words, MOBIKE do not consider the Simultaneous IP Addresses Multihoming (SM) that would enable IKEv2 to use simultaneously multiple IP addresses. Furthermore, one should also notice that multihoming facilities provided by MOBIKE are ONLY intended for the IKEv2 application. This means that the Alternate IP Addresses provided by on peer are only intended to be used by IKEv2. In other words, other applications Migault Expires March 5, 2010 [Page 5] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 than IKEv2 are not using the Alternate IP Addresses. We do not see in this draft much reasons to enable Simultaneous IP Addresses Multihoming (SM) for IKEv2 as an application. On the other hand we consider that Simultaneous IP Addresses Multihoming (SM) facilities can be provided by IKEv2 so that other application can benefit from it. More precisely, the IPsec layer of one peer MUST be able to inform the other peer IPsec layer that Simultaneous IP Addresses can be used on a given Security Association. Simultaneous IP Addresses Multihoming consists of ADDing or REMOVing one or more IP addresses to a specific Security Association. Such IPsec modifications are necessary to protect and allow the traffic of an application. At least they can avoid IKEv2 negotiation, and multiple IPsec contexts. Until now we assume that IKEv2 provides messages that only concerns the IPsec parameters. This of course respects the layered model. On the other hand we can also think of interaction between Upper Layer Protocols (ULP). One way is to consider that ULP exchanges provide the IPsec Security Association configuration. The other way considers that such exchanges SHOULD be protected and IPsec is a good way to protect data. Thus rather then using a specific channel negotiated by IKEv2, we can use directly the IKEv2 channel. Furthermore this way would provide a generic multihomed and mobility related information that could be re-used by different ULP. So this way considers that multihoming and mobility information sent via the IKEv2 channel, are used by the IPsec layer to update / modify the Security Association, but are also forwarded to the ULP so that they could consider there own mobility and multihoming action on their own layer. The advantage of such strategy is to avoid multiple exchanges. With ULP-IKEv2 interaction considerations, one can consider the use of the Alternate IP Addresses not for the IKEv2 application, but also for other applications. This means that when an Alternate IP Address is associated to a given Security Association, IKEv2 forwards this information to the ULP. That is the purpose of the ULP to decide how and when to use this Alternate IP Address. When the ULP considers that the current IP address is not working anymore and that an Alternate IP address could be used, then it asks IKEv2 to eventually perform Return Routability check and to either perform a mobility or multihoming action. If a multihoming action is decided, then the IP address is ADDed to a given Security Association. If a mobility action is decided, then the Security Association is UPDATEd. In this draft, we do not consider how the ULP SHOULD proceed. We do not either consider how the mobility or multihoming information are transmitted to the ULP if they are. This draft only consider the Migault Expires March 5, 2010 [Page 6] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 IKEv2 exchange between the two peers. We mention here possible interactions between ULP and IKEv2 to justify that Multihoming Information can be associated to the IP addresses. 4. Requirements From the previous section as well as from the [ID.mglt-ipsec-mm- requirements], the requirements for MOBIKE-X can be split into three categories : the requirements on the Security Association other than the IKE_SA, the requirements on the IKE_SA and the requirements on the protocol. Requirements on the Security Associations other than the IKE_SA are listed below : 1 : Mobility and Multihoming MUST be done with IPsec in transport and in tunnel mode. 2 : The Initiator MUST be able to perform an UPDATE, ADD or REMOVE action on a Security Association, that is to say, change the IP address associated to the SA. 3 : For Mobility and Multihoming actions -- i.e. UPDATE, REMOVE or ADD action -- the Initiator MUST be able to check if the action is possible on the Responder side. 4 : Mobility and Multihoming actions, -- i.e. UPDATE, REMOVE or ADD -- action can explicitly specify which IP address is to be ADDed, REMOVEd, UPADTEd, and which IP address MUST replaced. 5 : When the Responder is requested to check a Mobility or Multihoming action, it MUST respond relevant information if the action can be performed and if not why the action cannot be performed. 6 : The Initiator MUST be able to SELECT the SA on which the action applies. 7 : The Initiator MUST be able to provide Alternate IP Addresses associated to specific SA. Requirements on the IKE_SA are listed below : 8 : The Initiator can send an Alternate IP Address to the IKEv2 application 9 : The Initiator MUST be able to explicitly specify on which IKE_SA the action applies to. Requirements regarding MOBIKE-X are listed bellow : Migault Expires March 5, 2010 [Page 7] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 10 : The extension MUST be as close as possible to MOBIKE. This means that MOBIKE-X MUST take MOBIKE as a base, and make the coding extension as light as possible. This include re-use of Notify Payloads defined in MOBIKE, as well as the same "philosophy". 11 : The exchange messages MUST be as low and short as possible. This means that omitted parameters have default values so that they do not need to be specified. 12 : Peers MUST be able to agree if the MOBIKE version used is MOBIKE-X or MOBIKE. 5. MOBIKE-X Protocol overview 5.1. UPDATE action MOBIKE considers that only one IP address can be used at a time. This has the advantage of removing the ambiguity about which IP address is to be used. In fact the mobile node has established a communication with the security gateway using OLD_IP. The MN is identified by its ID, has established an IKE_SA to secure IKE transactions. When the mobile node has a new IP address NEW_IP, it sends to the security gateway an UPDATE_SA_ADDRESSES Notify Payload. There is no need to specify which IP address is to be changed. When receiving an UPDATE_SA_ADDRESSES Notify Payload, the security gateway identifies the concerned IKE_SA, and the concerned CHILD_SA(s). The IP address that is to be replaced (OLD_IP) is the outer tunnel IP address of the CHILD_SA(s), and the IP address of the IKE_SA associated to the host. The new value (NEW_IP) to be placed is the IP address used to carry the UPDATE_SA_ADDRESSES Notify Payload and located in the IP header. Update of the SAD might requires some checks, such as checking return routability. With MOBIKE-X we do not consider the Mobile Node uses only one IP address at a time. We do not make any assumption on how the Mobile Node is managing its IP addresses. This means that we do not use the IP layer to find out values needed for the update. MOBIKE-X provides the ability to fully specify into its UPDATE_SA_ADDRESSES Notify Payload the IP address to be replaced (OLD_IP) and the new value of the IP address (NEW_IP). MOBIKE-X uses the IP parameters that are put into the data field of the UPDATE_SA_ADDRESSES Notify Payload. The difference with MOBIKE is that the data field MAY be not empty. The IP parameter may carries certain information associated to the IP address. More specifically, the Initiator MUST specify if the IP address is an OLD_IP, a NEW_IP, and information on whether the Initiator wants the UPDATE to occurs now or if it want only to check the UPDATE would match local policies and IPsec Security Policies (CHECK). As far as UPDATE action is concerned, it fulfills Migault Expires March 5, 2010 [Page 8] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 requirements 1, 2, 3 and 4. Note that the OLD_IP and NEW_IP parameters does not have to be always specified. If none of those parameters are specified, the UPDATE_SA_ADDRESSES is performed in a similar manner as in MOBIKE way. In this case, the Responder updates the IP addresses used to route packet to/from the Initiator. More specifically, this includes the outer IP addresses in IPsec tunnel mode, the IP address of transport mode, and the IP address of the IKE_SA. The replacing IP address is the IP address the Initiator use in the IP header of the IKEv2 message. The replacement occurs on the SA and IKE_SA specified by the SELECTORs Notify Payload. This is coherent with MOBIKE specification. The default values for the SELECTOR Notify Payload is CHILD_SA_AND_IKE_SA. If the Initiator has a single interface and uses the tunnel mode the outer IP address of the tunnel being replaced. The difference with MOBIKE is that transport mode IPsec SA are also going to be UPDATEd. As far as UPDATE action is concerned, it fulfills requirements 10 and 11. 5.2. ADD and REMOVE actions MOBIKE does not specify any equivalent actions for ADD or REMOVE actions. MOBIKE specifies an ADDITIONAL_IP_ADDRESS Notify Payload, but its purpose is to specify Alternate IP Addresses. One option would have been to re-use those Notify Payload at least for the ADD operation, and specify in the IP address parameters whether the IP address is an Alternate IP address or not. We decided to have specific Notify Payloads for Alternate IP Addresses since such IP addresses are not "directly" affecting the IPsec Security Associations. More specifically, Alternate IP addresses are either addressed to the IKEv2 application, or can eventually in the future be forwarded to the Upper Layer Protocols. ADD and REMOVE actions need new Notify Payloads ADD_SA_ADDRESS and REMOVE_SA_ADDRESS Notify Payloads. Such Payloads work in a similar manner as the UPDATE_SA_ADDRESSES Notify Payload. The IP address that has to be ADDed or REMOVEd of the SA is specified in an IP parameter. Only one IP parameter needs to be specified. The IP parameter carries some information such as the CHECK bit. The CHECK bit set to 1 specifies the Initiator only wants to check the action matches local and security policies. The IP parameter can also carry multihoming specific information thanks to the Multihoming Information Payload (MIP). Multihoming specific Information are used so that ULP can make their decision on which IP address to choose. In fact there are not expected to be handled by IKEv2. Such information can be the PREFERENCE which indicates how the Initiator prefer this IP address, the CLASS which indicates the nature of the IP address (HoA, CoA, ...), or reachability information. As far as Migault Expires March 5, 2010 [Page 9] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 ADD and REMOVE actions are concerned, requirements 1, 2, 3 and 4 are fulfilled. In a similar way as with the UPDATE_SA_ADDRESSES Notify Payload, if no IP parameter is provided in the data field, than the ADD or REMOVE action applies to all CHILD_SA associated to the IKE_SA. The IP address to be ADDed or REMOVEd is the one placed in the IP header. As far as ADD and REMOVE actions are concerned requirements 10 and 11 are fulfilled. Note that ADD and REMOVE actions do not applies to the IKE_SA. In this draft we do not consider that the IKEv2 application implements Simultaneous IP Address Multihoming. This is for future development. 5.3. Response to a CHECK Request When the Responder receives an UPDATE, ADD or REMOVE action request with the CHECK bit set to 1, then the Responder is expected to provide information on whether the action can be performed, and if not why the action cannot be performed. If the action can be performed the Responder returns a response without any error Notify Payload. If the action cannot be performed because the IP address does not fit local policies, then a UNACCEPTABLE_ADDRESS Notify Payload is sent. If the action cannot be performed because the IP address does not match the SPD, then a DOES_NOT_FIT_SPD Notify Payload. Such Notify Payloads fulfill requirement 5. 5.4. SELECTing the SA MOBIKE-X provides a mechanism to explicitly specify which SA or which IKE_SA the action applies to. One or more SELECTOR Notify Payload can be used. If the Initiator does not specifies any SELECTOR, then the default value for the SELECTOR is IKE_SA_AND_CHILD_SA, which means that the action MUST apply to the IKE_SA and all associated CHILD_SA(s). Such mechanism fulfills requirement 9, 10, 11 and 5. 5.5. Alternate IP Address MOBIKE defines an ADDITIONAL_IP4_ADDRESS and ADDITIONA_IP6_ADDRESS Notify Payloads so that a peer can advertise the other peer an IP address. This message specifies an Alternate IP Address intended to be used by the IKEv2 application. This means that the implicit selector value is IKE_SA. MOBIKE-X uses this Notify Payload, by considering that the specified IP address can also be associated to a Migault Expires March 5, 2010 [Page 10] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 SA. The SAs are specified with the SELECTORs Notify Payloads. In that case, the IKEv2 application is not expected to do anything else than forwarding the information to the Upper Layer Protocols. MOBIKE defines ADDITIONAL_IP*_ADDRESS with the IP address value inside the data field of the Notify Payload. MOBIKE-X re-uses those messages, but fills the data field of the Notify Payload with the IP parameters. Note that the use of two distinct ADDITIONAL_IP*_ADRESS Notify Payload is not anymore necessary, since the type of the IP address is specified with the parameter type. Thus we define in this document the ADDITIONAL_IP_ADDRESS Notify Payload which is an alias for the ADDITIONAL_IP6_ADDRESS. Reasons are that we do not want to have two different Notify Payload for the same action. Such mechanism fulfills requirements 7, 8 and 10. Note that this draft does not specify nor provide mechanisms that either enable one peer to know if the alternate IP address is forwarded to the ULP, or that enables communications between the ULP and the IKEv2 application. In other words, it defines that ADDITIONAL_IP_ADDRESS Notify Payload can be associated to SA, and so SHOULD NOT be rejected by IKEV2 or generate any error message. 5.6. MOBIKE Version The protocol described in this draft is not fully compatible with MOBIKE. Furthermore, it provides more functionalities. Peers need to agree on which version of the protocol they understand. In this draft, the two possible protocols are MOBIKE or MOBIKE-X, and the choice is exclusive. Negotiation on the MOBIKE version is agreed by using the MOBIKE_SUPPORT Notify Payload. MOBIKE-X is designated by using a version parameter in the data field. The version value considered for MOBIKE-X is 2. The exchange defined in this draft is expected to support further MOBIKE versions. Thus we defined the MOBIKE_UNSUPPORTED_VERSION Notify Payload. This mechanism fulfill requirements 12. 5.7. Other Considerations As defined in MOBIKE, MOBIKE-X considers that Mobility or Multihoming action can only be triggered by the Initiator. MOBIKE deals with NAT, and we would like to take advantage of this work, even though we do not consider NAT in this paper. Migault Expires March 5, 2010 [Page 11] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 6. Notify Payload Description 6.1. MOBIKE_SUPPORTED Notify Payload This message is described in MOBIKE [RFC4555]. MOBIKE-X uses versions parameters to specify which version is supported by the peer. We consider is this paper the version corresponding to MOBIKE as defined in [RFC4555] as version 1 and the MOBIKE-X version as described in this paper as version 2. A node that implements a MOBIKE-X of version equal or greater than 2 MUST specify the version numbers in its MOBIKE_SUPPORTED Notify Payload. If no version is specified, then the node is assumed to support only MOBIKE of version 1. In the IKE_AUTH exchange, the MOBIKE_SUPPORTED Notify Payload is sent by the Initiator. The Initiator sends an MOBIKE_SUPPORTED Notify Payload with the version parameters of the MOBIKE versions it supports. There can be multiple version parameters and the Initiator expects that the Responder will choose one of them. When the Responder receives an MOBIKE_SUPPORTED Notify Payload, and the Responder supports one of the proposed versions, it chooses one of those and indicates the chosen version with the version parameter in the MOBIKE_SUPPORTED Notify Payload sent as a response. If none of the version is supported by the Responder, the Responder MUST send an MOBIKE_UNSUPPORTED_VERSION Notify Payload. - Version : The supported version of MOBIKE-X. MOBIKE-X as defined in this draft is considered as version 2, MOBIKE as specified in [RFC4555] is considered as version 1. At this level of the negotiation both peers have agreed on which MOBIKE version of the protocol they understand. 6.2. MOBIKE_UNSUPPORTED_VERSION Notify Payload This Notify Payload is used to indicate that proposed versions by the Initiator are not supported. This message carries the version the Responder supports. If the Initiator also supports this version and has not already proposed it to the Responder, then it can restart the negotiation. This Notify Payload is also used to cancel the use of MOBIKE-X, to go back to the initial state where MOBIKE is not supported by any of the peers. This is mainly to avoid ambiguous situation where one peer understands one thing but not the other. For that purpose, we use a specific version value NONE. The Notify Payload can carry the following options : Migault Expires March 5, 2010 [Page 12] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 - Version : The considered version of MOBIKE-X. MOBIKE-X in this draft is considered as version 1. The NONE value is 255. 6.3. SELECTOR Notify Payload A SELECTOR Notify Payload contains a list of parameters. A SA matches this SELECTOR payload if it matches all parameters within the SELECTOR Notify Payload. A SELECTOR Notify Payload is always followed either by a SELECTOR, an UPDATE_SA_ADDRESSES, an ADD_SA_ADDRESS, a REMOVE_SA_ADDRESS, or an ADDITIONAL_IP_ADDRESS Notify Payload. Those Notify Payloads are also called the action. When different SELECTOR Notify Payloads are grouped together before an action, we call this group a SELECTOR_SET. An SA matches the SELECTOR_SET when a match occurs with at least one of the SELECTOR payload. The SELECTOR Notify Payload can have the following parameters : - SPI : By specifying the SPI the action applies to. - IP : By specifying the IP address the action applies to. The IP parameter can provide information about the location (inner or outer IP address). - IPSEC_PROTO : By specifying the IPSEC_PROTO the action applies to. - IPSEC_MODE : By specifying the IPSEC_MODE, the applies to. - ID : The Identification Number of the Notify Payload. It is optional. It is recommended to add this option to identify the SELECTOR_SET. When an error occurs, the SELECTOR Notify Payload causing the error can be identified. 6.4. END_OF_SELECTOR Notify Payload The END_OF_SELECTOR Notify Payload indicates the SELECTOR_SET do not apply any more to the action that follows this Notify Payload. We do not expect any parameters being carried by this payload. 6.5. ADDITIONAL_IP_ADDRESS Notify Payload ADDITIONAL_IP_ADDRESS Notify Payloads carry Alternate IP Addresses. ADDITIONAL_IP_ADDRESS Notify Payload applies to the IKE_SA as specified in MOBIKE [RFC4555]. That is to say the carried IP address is used by the IKEv2 application, only. Alternate IP addresses are used only when the current IP Address is not working anymore. When ADDITIONAL_IP_ADDRESS Notify Payload applies to a regular SA, then IKEv2 SHOULD forward the information to ULP. This draft does not provide any details on how communication is done between ULP and IKEv2. This is not considered in this paper. Migault Expires March 5, 2010 [Page 13] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 The IP address is carried in the Notify Payload in the data field thanks to IP parameter. This is a main difference with MOBIKE [RFC4555] where the data field directly contains the value of IP address. Thus the ADDITIONAL_IP_ADDRESS Notify Payload can carry the following parameters : - IP : The IP address to be used as an Alternate IP Address. - ID : The Identification Number of the Notify Payload. It is optional. It is recommended to add this option so that when an error occurs, the Notify Payload Notify Payload causing the error can be identified. IP parameters can carry information about the IP address thanks to the Multihoming Information Payload (MIP). Such information is intended to help the Responder to choose the best Alternate IP Address, in case of failure. Such information includes the REACHABILITY that indicates the REACHABILITY information of the IP address, the CLASS which indicates the nature of the IP address (HoA, CoA...), the PREFERENCE which is a non objective parameter provided by the Initiator. The CHECK bit indicates if the Initiator expects the action to be performed or if the Initiator is only willing to check the action can be performed. If the Alternate IP Address does not match the local policies then an UNACCEPTABLE_IP_ADDRESS Notify Payload is sent back. If the Alternate IP Address does not fit the SPD, then a DOES_NOT_FIT_SPD Notify Payload is sent back. Note that checks do not include Return Routability Check. If the user wants to check the reachability of the Alternate IP address, and if that is possible -- the Initiator is multihomed -- , then the Initiator MUST perform it and initiate the exchange. If NEW_IP address matches both local policies and the SPD, then a INFORMATIONAL response is sent without error Notify Payloads. SELECTORs Notify Payload MAY be used to specify which on which Security Association the IP address change MUST occur. 6.6. UPDATE_SA_ADDRESSES Notify Payload UPDATE_SA_ADDRESSES Notify Payload indicates the Responder that the Initiator wants to replace OLD_IP by NEW_IP, in the selected SAs. In MOBIKE, the Initiator uses only one IP address. Thus, OLD_IP is the one associated to the peer in the IKE_SA and the CHILD_SA(s). The NEW_IP is in the IP header of the IP packet carrying IKEv2 message. In MOBIKE-X, the Initiator can use simultaneous IP Migault Expires March 5, 2010 [Page 14] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 addresses, thus we need to be able to explicitly specify in the Notify Payload, OLD_IP and NEW_IP. So the difference with MOBIKE is that the UPDATE_SA_ADDRESSES Payload can carry the following parameters : - OLD_IP : The replaced IP address. The parameter is a regular IP parameter, where we set the OLD bit to one. In case of tunnel mode Security Association, the I (inner) and the H (header) bit specifies if the OLD_IP is the inner or outer IP address. - NEW_IP : The replacing IP address. The parameter is a regular IP parameter where we set the NEW bit to one. - ID : The Identification Number of the Notify Payload. It is optional. It is recommended to add this option so that when an error occurs, the Notify Payload Notify Payload causing the error can be identified. If NEW_IP does not match the local policies then an UNACCEPTABLE_IP_ADDRESS Notify Payload is sent back. If NEW_IP does not fit the SPD, then a DOES_NOT_FIT_SPD Notify Payload is sent back. Note that checks do not include Return Routability Check. If the user wants to check the reachability of NEW_IP, and if that is possible -- the Initiator is multihomed -- , then the Initiator MUST perform it and initiate the exchange. The CHECK bit indicates if the Initiator expects the action to be performed or if the Initiator is only willing to check the action can be performed. O, N, bits specify which IP is the OLD_IP, and which IP is the NEW_IP. H and I bits specify where in the SA the IP address is located. In SA using tunnel mode, the bit I indicates the IP address is located inside the tunnel (Inner), and H specifies the IP address is in the outer tunnel header (Header). In SA using transport mode, the H bit indicates the IP address is in the outer IP header. H stands for routed IP Header. The OLD_IP and NEW_IP are not required. If there are omitted by the Initiator, then default values are considered. SELECTORs Notify Payload MAY be used to specify which on which Security Association the IP address change MUST occur. 6.7. ADD_SA_ADDRESS Notify Payload The ADD_SA_ADDRESS Notify Payload is very similar as the UPDATE_SA_ADDRESSES Notify Payload. The Initiator sends an ADD_SA_UPDATE Notify Payload so the Responder ADDs an IP address to Migault Expires March 5, 2010 [Page 15] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 the SA designated by the SELECTORs. The IP address is designated by the IP parameter. If IP parameter does not match the local policies then an UNACCEPTABLE_IP_ADDRESS Notify Payload is sent back. If the IP address does not fit the SPD, then a DOES_NOT_FIT_SPD Notify Payload is sent back. Note that checks do not include Return Routability Check. If the user wants to check the reachability of the IP address, and that is possible -- the Initiator is multihomed -- , then the Initiator MUST perform it and initiates the exchange. CHECK, H, I have the same signification as with the UPDATE_SA_ADDRESSES Notify Payload. The O bit and N bit are not considered, since only one IP address is being ADDed. The ADD_SA_ADDRESS Notify Payload can carry the following parameters : - IP : The IP address to be used as an alternate IP address. - ID : The Identification Number of the Notify Payload. It is optional. It is recommended to add this option so that when an error occurs, the Notify Payload Notify Payload causing the error can be identified. 6.8. REMOVE_SA_ADDRESS Notify Payload The REMOVE_SA_ADDRESS Notify Payload is very similar as the UPDATE_SA_ADDRESSES Notify Payload. The Initiator sends an REMOVE_SA_UPDATE Notify Payload so the Responder REMOVEs an IP address to the SA designated by the SELECTORs. If IP parameter does not match the local policies then an UNACCEPTABLE_IP_ADDRESS Notify Payload is sent back. If the IP address does not fit the SPD, then a DOES_NOT_FIT_SPD Notify Payload is sent back. Note that checks do not include Return Routability Check. If the user wants to check the reachability of IP address, and if that is possible -- the Initiator is multihomed --, then the Initiator MUST perform it and initiate the exchange. When the Initiator requests a REMOVEs on the last IP address of an SA, then the Responder REMOVEs the IP address -- or not depending on the CHECK bit value --- and sends a warning Notify Payload CLOSING_SA. CHECK, H, I have the same signification as with the UPDATE_SA_ADDRESSES Notify Payload. The O bit and N bit are not considered, since only one IP address is being REMOVEd. The REMOVE_SA_ADDRESS Notify Payload can carry the following parameters : Migault Expires March 5, 2010 [Page 16] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 - IP : The IP address to be used as an alternate IP address. - ID : The Identification Number of the Notify Payload. It is optional. It is recommended to add this option so that when an error occurs, the Notify Payload Notify Payload causing the error can be identified. 7. Protocol Exchanges This section provides a description on how Initiators and Responders are expected to behave when receiving or sending the different Notify Payloads involved in this paper. For clarification purpose we illustrate the behavior with state diagrams. State diagrams mostly rely on node's implementation. States and state diagrams are not normative. We also tried to point out different possible implementations. 7.1. Initial Exchange 7.1.1. MOBIKE_SUPPORTED Notify Payload The initial exchange enables the Initiator to check if the Responder supports MOBIKE-X and negotiates a given version of MOBIKE-X with the Responder. The Initial exchange is derived from [RFC4555] and shows how NAT is considered. As mentioned in the Introduction section NAT is treated in a similar manner as it is in MOBIKE [RFC4555]. Migault Expires March 5, 2010 [Page 17] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 Initiator Responder ----------- ----------- 1) (IP_I1:500 -> IP_R1:500) HDR, SAi1, KEi, Ni --> N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP) --> <-- (IP_R1:500 -> IP_I1:500) HDR, SAr1, KEr, Nr, N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP) 2) (IP_I1:4500 -> IP_R1:4500) HDR, SK { IDi, CERT, AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr, N(MOBIKE_SUPPORTED)} --> <-- (IP_R1:4500 -> IP_I1:4500) HDR, SK { IDr, CERT, AUTH, CP(CFG_REPLY), SAr2, TSi, TSr, N(MOBIKE_SUPPORTED) } Initial exchange As specified in [RFC4555], in order to be able to go through NAT, when using MOBIKE, the port used is 4500. The Initiator sends a MOBIKE_SUPPORTED Notify Payload in which it indicates the proposed versions. The Notify Payload SHOULD have its critical flag on. The version of MOBIKE considered in [RFC4555] is version 1, and the version of MOBIKE considered in this draft is version 2. If the Responder does not support MOBIKE, it does not understand the Notify Payload, the exchange is described in section 2.5 of [RFC4306]. If the Notify Payload has been set to critical by the Initiator, then the Responder MUST send as specified in [RFC4306] a UNSUPPORTED_CRITICAL_PAYLOAD Notify Payload. The Initiator knows that the Responder does not support any version of MOBIKE or MOBIKE-X. If the Notify Payload does not have its critical flag, then the Responder does not send any response and the Initiator SHOULD wait for a given time before assuming the Responder does not support MOBIKE or MOBIKE-X. If the Responder supports MOBIKE, but does not support MOBIKE-X : When it receives a MOBIKE_SUPPORTED Notify Payload, it does not understand parameters specified in data field. If the Responder wants to activate MOBIKE, then it sends a MOBIKE_SUPPORTED Notify Migault Expires March 5, 2010 [Page 18] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 Payload with no version specified in the data field of the Notify Payload. When the Initiator receives this Notify Payload, it understands that with no version specified, the Responder does only understand MOBIKE as specified in [RFC4555]. If the Responder does not want to activate MOBIKE, it MUST check the critical flag of the received Notify Payload and either MUST send a UNSUPPORTED_CRITICAL_PAYLOAD Notify Payload, or no response at all. When the Initiator receives the UNSUPPORTED_CRITICAL_PAYLOAD Notify Payload or no response, it understands that the Responder does not support MOBIKE. Note that the Initiator cannot make the distinction between a Responder that does not want to activate MOBIKE, or a responder do not support MOBIKE. If the Responder supports MOBIKE-X and does not want to activate MOBIKE or MOBIKE-X : When it receives the MOBIKE_SUPPORTED Notify Payload, the Responder MUST check the data field and check if there are any versions proposed. If no version is proposed, then the Initiator only supports MOBIKE. The Responder should check the critical flag of the Notify Payload and either sends a UNSUPPORTED_CRITICAL_PAYLOAD Notify Payload, or no response. If the MOBIKE_SUPPORTED Notify Payload carries version parameters in its data payload, then the Responder knows that the Initiator does support MOBIKE-X. It SHOULD send a MOBIKE_UNSUPPORTED_VERSION Notify Payload with a version set to NONE. The Responder knows the Initiator supports MOBIKE-X since the MOBIKE_SUPPORTED Notify Payload has version parameters. The Initiator will then understand the response. This case is an alternative to simulate the case the Responder does not event understand MOBIKE and sends only a UNSUPPORTED_CRITICAL_PAYLOAD. It clearly states the Responder does support MOBIKE-X, but does not want to activate it. If the Responder supports MOBIKE-X and does only want to activate MOBIKE as defined in [RFC4555] : When it receives the MOBIKE_SUPPORTED Notify Payload, it MUST check the MOBIKE_SUPPORTED Notify Payload carries version parameters in its data field. If no version number is found, the Responder assumes the Initiator does only supports MOBIKE as defined in [RFC4555]. It SHOULD send a MOBIKE_SUPPORTED Notify Payload. If the data field carries version numbers, then the Responder knows the Initiator supports MOBIKE-X. The Responder should check version 1 is proposed. If version 1 is proposed, then the Responder MUST send a MOBIKE_SUPPORTED Notify Payload with the chosen version, i.e. version 1. If the version 1 is not proposed, then the Responder MUST send a MOBIKE_UNSUPPORTED_VERSION Notify Payload indicating the accepted version by the Responder. In that specific case the Notify Payload data field MUST carry version 1. When the Initiator receives the Migault Expires March 5, 2010 [Page 19] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 response it is up to him to decide to restart a MOBIKE_SUPPORTED exchange with the version 1 proposed or to consider that neither MOBIKE nor MOBIKE-X are activated. If the Responder supports MOBIKE-X and wants to activate MOBIKE-X : When it receives the MOBIKE_SUPPORTED Notify Payload, it MUST check the data field of the Notify Payload carries version numbers in the data field. If no version numbers are specified, then the Initiator supports MOBIKE, but does not support MOBIKE-X. The Responder can choose to enable MOBIKE or not. This case is similar as the one when the Responder supports MOBIKE-X but only wants to activate MOBIKE. If the Initiator supports MOBIKE-X, the Responder should check version number 2 is proposed by the Initiator. If version number 2 is not proposed, the Responder MUST send a MOBIKE_UNSUPPORTED_VERSION Notify Payload with version set to 2. If version number 2 is proposed then the Responder MUST send a MOBIKE_SUPPORTED Notify Payload with the chosen version number, that is to say with version number 2. In this case MOBIKE-X is considered activated both on the Initiator side and on the Responder side. NOTE 1 : The case where the Initiator supports MOBIKE-X and starts a MOBIKE_SUPPORTED exchange with the Responder which does not supports is specified in [RFC4306] section 2.5. IKEv2 adds a "critical" flag to each payload header for further flexibility for forward compatibility. If the critical flag is set and the payload type is unrecognized, the message MUST be rejected and the response to the IKE request containing that payload MUST include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an unsupported critical payload was included. If the critical flag is not set and the payload type is unsupported, that payload MUST be ignored. NOTE 2 : There is one corner case. Consider the Initiator supports MOBIKE-X, and wants to activate MOBIKE-X but does NOT want MOBIKE, and the Responder does only supports MOBIKE. In that case, the Initiator sends a MOBIKE_SUPPORTED Notify Payload to the Responder. The Responder supports only MOBIKE, and sends back a MOBIKE_SUPPORTED Notify Payload. Responder and Initiators have agreed on version 1 of MOBIKE. MOBIKE as described in [RFC4555] does not provides any Notify Payload to remove the MOBIKE option. In other words, there is no equivalent of MOBIKE_UNSUPPORTED_VERSION in MOBIKE. So the situation is MOBIKE as been "agreed" between the Initiator and the Responder, the Initiator wants MOBIKE-X and cannot remove MOBIKE. Consequences are that the Initiator cannot use MOBIKE-X functionalities, but can be requested by the Responder some MOBIKE functions. If that bothers the Initiator, then it has to restart an Migault Expires March 5, 2010 [Page 20] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 IKE_SA_INT exchange without sending MOBIKE_SUPPORTED Notify Payload. 7.1.2. MOBIKE_UNSUPPORTED_VERSION Notify Payload The MOBIKE_UNSUPPORTED_VERSION is a MOBIKE-X specific Notify Payload. It MUST be sent by the Responder when it has checked the Initiator supports MOBIKE-X. The MOBIKE_UNSUPPORTED_VERSION Notify Payload can be received during the MOBIKE_SUPPORTED negotiation. The Responder as well as the Initiator supports MOBIKE-X but the Responder does not support the version of MOBIKE-X proposed by the Initiator. The other case this Notify Payload can be used is when the Initiator and the Responder have already agreed on which version of MOBIKE-X to activate, and one of them wants to deactivate the used of MOBIKE or MOBIKE-X. Suppose the Initiator has started its MOBIKE version negotiation, and both Initiator and Responder support MOBIKE-X. When the MOBIKE_UNSUPPORTED_VERSION Notify Payload is received, the Initiator knows the previously proposed versions are not supported by the Responder. The Initiator can read the version carried by the MOBIKE_UNSUPPORTED_VERSION. If the version is NONE, it means the Responder supports MOBIKE-X but does not want to activate the MOBIKE or MOBIKE-X extension. If the Responder supports another version than the one proposed by the Initiator, then it sends its version number into the MOBIKE_UNSUPPORTED_VERSION, the Initiator can then check if this version has not been previously been sent and if it supports this version. It can then restart a negotiation and send a MOBIKE_SUPPORTED Notify Payload with the version supported by the Responder. This gives the opportunity to the Initiator to have a preferred list sent in the first MOBIKE_SUPPORTED Notify Payload, and a backup of other versions in case the Responder does not support the versions of the "preferred list". The Responder is expected to send a MOBIKE_SUPPORTED Notify Payload with the proper version. If not the Initiator the Responder is probably badly configured and MOBIKE-X extension is not activated. The MOBIKE_UNSUPPORTED_VERSION Notify Payload can also be received by any of the peer while MOBIKE-X has been negotiated between the Initiator and the Responder. In this situation, the version MUST be set to NONE, and it means that MOBIKE-X is not active anymore. 7.1.3. Initial exchange state diagrams The diagrams and states descriptions provided in this section are not normative. There purpose is to clarify the text description. It Migault Expires March 5, 2010 [Page 21] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 might help for some implementations but implementations are not expected to implement them. The different states considered in this paper are : - INIT : This state corresponds to the starting point when no MOBIKE-X negotiation has been initiated. - MOBIKE_SUPPORTED_SENT : This Initiator is in this state when it has sent a MOBIKE_SUPPORTED Notify Payload. The Initiator is then waiting for a response. - MOBIKE_SUPPORTED : This state ends a MOBIKE_SUPPORTED negotiation. Initiator and the Responder agreed on activating version 1, that is to say MOBIKE as specified in [RFC4555]. MOBIKE-X as specified in this paper has not been agreed. - MOBIKE-X_SUPPORTED : This state ends a MOBIKE_SUPPORTED negotiation. Initiator and the Responder agree on activating version greater then 1, that is to say MOBIKE-X as specified in this paper is activated by the Initiator and the Responder. When MOBIKE-X is supported, then MOBIKE is also supported. - MOBIKE-X_UNSUPPORTED : This state ends the MOBIKE_SUPPORTED negotiation. Initiator and Responder did not agreed on the activation of MOBIKE-X as described in this paper. This state means the Initiator and the Responder agreed on MOBIKE but not MOBIKE-X. - MOBIKE_UNSUPPORTED : This state ends the MOBIKE_SUPPORTED negotiation. Initiator and Responder did not agree on the activation of MOBIKE-X as described in this paper nor MOBIKE as described in [RFC4555]. This state can also been considered as similar to the INIT state, except that one negotiation has been attempted. In the state diagram, we used a context called CTX. This is also not normative. The Context contains the following information : - INITIATOR The necessary information to identify the Initiator part of the MOBIKE-X negotiation. - RESPONDER The necessary information to identify the Responder part of the MOBIKE-X negotiation. - INITIATOR_VERSION MOBIKE-X versions proposed by the Initiator to the Responder. - RESPONDER_VERSION MOBIKE-X versions proposed by the Responder to the Initiator. - NEGOTIATED_VERSION MOBIKE-X versions agreed by the Responder and the Initiator. Migault Expires March 5, 2010 [Page 22] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 - STATUS The status of the negotiation the different values can be START, MOBIKE, MOBIKE-X or NULL. For simplification, we assume in the Initiator diagram that the Initiator supports MOBIKE-X and proposed to the Responder version 1 (MOBIKE) and version 2 (MOBIKE-X). We also assume in the Responder diagram that if the Responder supports MOBIKE-X, then it choose MOBIKE-X rather then MOBIKE. The Responder state diagram does not have MOBIKE_UNSUPPORTED or MOBIKE-X_UNSUPPORTED state, and when a negotiation fails, the Responder does not keep any context. This is an implementation consideration, and we thought that keeping a context to every negotiation could expose the Responder to DoS. +------------------------+ | INIT | +------------------------+ | +<--- Initiator want to enable MOBIKE-X | Create Context CTX = (INITIATOR, RESPONDER, INITIATOR_VERSION=1,2 RESPONDER_VERSION=NULL, NEGOTIATED_VERSION=NULL, STATUS=START ) Send a MOBIKE_SUPPORTED Notify Message with corresponding VERSION to RESPONDER Set the critical flag to 1 | +------------------------+ | MOBIKE_SUPPORTED_SENT | +------------------------+ Initiator : INIT to MOBIKE_SUPPORTED_SENT Migault Expires March 5, 2010 [Page 23] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +------------------------+ | MOBIKE_SUPPORTED_SENT | INITIATOR, CTX +------------------------+ | NO MESSAGE from CTX.RESPONDER ? --TIMEOUT-+--------------+ | YES YES | | MESSAGE.type == ----------+ CTX.STATUS=NULL UNSUPPORTED_CRITICAL_PAYLOAD ? | | NO +------------------------+ MESSAGE.type = MOBIKE_SUPPORTED && ---+ | MOBIKE_UNSUPPORTED | MESSAGE has no VERSION ? YES | +------------------------+ NO | NO +--------------+ +-- MESSAGE.type == MOBIKE_SUPPORTED && v | MESSAGE.VERSION in CTX.RESPONDER_VERSION=1 | CTX.INITIATOR_VERSION ? CTX.STATUS=MOBIKE | | YES CTX.NEGOTIATED_VERSION=1 | CTX.STATUS = MOBIKE-X | | CTX.NEGOTIATED_VERSION = +------------------------+ MESSAGE.VERSION | MOBIKE-X_UNSUPPORTED | | CTX.RESPONDER_VERSION=MESSAGE.VERSION +------------------------+ | | | +------------------------+ | | MOBIKE-X_SUPPORTED | | +------------------------+ | +-> MESSAGE.type == MOBIKE_UNSUPPORTED_VERSION | NO MESSAGE.VERSION == NONE ? ---------------------------+ | YES NO v CTX.RESPONDER_VERSION=1,2 +-------- MESSAGE.VERSION == 1 ? CTX.STATUS=NULL | | YES | | CTX.RESPONDER_VERSION=1,2 +------------------------+ | CTX.STATUS=MOBIKE | MOBIKE_UNSUPPORTED | | | +------------------------+ | +------------------------+ +-----------------+ | MOBIKE-X_UNSUPPORTED | v +------------------------+ CTX.RESPONDER_VERSION=1,2 CTX.STATUS=NULL | +------------------------+ | MOBIKE_UNSUPPORTED | +------------------------+ Initiator : MOBIKE_SUPPORTED_SENT to MOBIKE*_*SUPPORTED Migault Expires March 5, 2010 [Page 24] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +------------------------+ | INIT | RESPONDER, CTX +------------------------+ | | MESSAGE received && NO +------------------------+ MESSAGE.type == MOBIKE_SUPPORTED ? --->| INIT | | YES NO +------------------------+ RESPONDER supports MOBIKE ? -----------------------+ | YES NO v RESPONDER supports MOBIKE-X (')?-----+ Send UNSUPPORTED_CRITICAL_PAYLOAD | YES NO| | Does MESSAGE carries VERSION (*)?----+ +------------------------+ | YES | | INIT | MESSAGE.VERSION supported ? | +------------------------+ | YES | NO+--------------+ Chose a VERSION +------------+ v Send MOBIKE_SUPPORTED | Send MOBIKE_SUPPORTED -no version MESSAGE.VERSION | Create CTX( Create Context | INITIATOR, RESPONDER CTX = ( | INITIATOR_VERSION=1 INITIATOR, RESPONDER | RESPONDER_VERSION=[1'] [1, 2*] INITIATOR_VERSION=MESSAGE.VERSION, | NEGOTIATED_VERSION=1 RESPONDER_VERSION=VERSION, | STATUS=MOBIKE) NEGOTIATED_VERSION=VERSION, | | STATUS=MOBIKE-X ) | +------------------------+ | | | MOBIKE_SUPPORTED | +--------------------------+ | +------------------------+ | MOBIKE-X_SUPPORTED | +--------------+ +--------------------------+ v Send UNSUPPORTED_MOBIKE_VERSION with supported VERSIONs | +------------------------+ | INIT | +------------------------+ Responder : INIT to MOBIKE*_SUPPORTED Migault Expires March 5, 2010 [Page 25] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +------------------------+ | MOBIKE-X_SUPPORTED | +------------------------+ | +<----MESSAGE received | NO MESSAGE.type == ----------------------+ MOBIKE_UNSUPPORTED_VERSION ? | | YES NO v MESSAGE.VERSION == NONE ? ----------+ Treat MESSAGE | YES | | v | +------------------------+ +-------- ---------------+ | | MOBIKE-X_SUPPORTED | | MOBIKE_UNSUPPORTED | | +------------------------+ +------------------------+ +----------+ v Discard MESSAGE | +------------------------+ | MOBIKE-X_SUPPORTED | +------------------------+ MOBIKE-X_SUPPORTED to MOBIKE_UNSUPPORTED 7.2. Alternate IP Address Exchange When the Initiator wants to inform the Responder that it has an Alternate IP address, the Initiator sends an ADDITIONAL_IP_ADDRESS Notify Payload. In MOBIKE [RFC4555], this case is described in section 3.6. More specifically the data field contains the value of the IP address. In MOBIKE-X, the main difference is that we use parameter payload that specifies the type of the IP address. Furthermore, the IP parameter provides also some information on the IP addresses. The reason is that with multihoming, the Initiator might have more then one alternate IP address. If the current IP address is not in use, then the Responder has to choose the more adequate IP address. Multihoming Information Payload (MIP) associated to the IP address are intended to provide input for the Responder. As in the MOBIKE [RFC4555] document, ADDITIONAL_IP_ADDRESS Notify Payload contains only one IP address. More IP addresses could have been placed, but it is better for logs to have elementary actions. One difference with MOBIKE [RFC4555] is that the type of the expected IP address is specified in the action Notify Payload. In fact, if IPv6 (resp IPv4) Alternate IP Addresses have to be sent, then an ADDITIONAL_IP6_ADDRESS (resp. ADDITIONAL_IP4_ADDRESS) Notify Payload Migault Expires March 5, 2010 [Page 26] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 is used. MOBIKE-X does not need different Notify Payload since the type of the IP address is defined in the IP address parameter. MOBIKE-X only uses the ADDITIONAL_IP6_ADDRESS notify Payload, and it is called ADDITIONAL_IP_ADDRESS in this document. When the Responder receives an ADDITIONAL_IP_ADDRESS with a CHECK bit set to 0, the Responder MUST clear the list of Alternate IP address, and fill the list with the IP addresses provided in the multiple ADDITIONAL_IP_ADDRESSES Notify Payloads. In other words, Initiator can only send to full list and there is not incremental way to provide / remove Alternate IP Addresses. This mechanism is the one already existing in MOBIKE [RFC4555]. This draft only cares about Alternate IP Address associated to the IKE_SA. When an Alternate IP address is associated to an SA, IKEv2 application MUST forward the information to the ULP. How this is performed is beyond the scope of this document. In this document we mainly consider the Initiator sends an Alternate IP address to the IKEv2 application of the Responder. If the Initiator sends an ADDITIONAL_IP_ADDRESS Notify Payload with the CHECK bit set to 0, then the Initiator does not request for verifications. The Responder adds the IP address into the list of alternate IP addresses. If the Initiator wants to CHECK an alternate IP address is valid, then it MUST set the CHECK bit to 1. When the Responder receives an ADDITIONAL_IP_ADDRESS Notify Payload with the CHECK bit set to one, the Responder checks the Alternate IP address matches local policies. If the Alternate IP address does not match the local policies, then the Responder MUST send an UNACCEPTABLE_IP_ADDRESS Notify Payload. The Responder also checks the Alternate IP address matches with the SPD. If the Alternate IP address does not fit the SPD, then a DOES_NOT_FIT_SDP Notify Payload MUST be sent. Note that with IKE_SA, any IP address matches the SP policy. The Initiator indicates the Alternate IP Address thanks to IP parameter. The Initiator MAY set the PREFERENCE, CLASS fields. In this document Alternate IP addresses have their IP parameters payload with the O, N, I bits values set to 0 and the H bit set to 1. 7.3. Alternate IP Address Exchange State Diagram Migault Expires March 5, 2010 [Page 27] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +------------------------+ | MOBIKE-X_SUPPORTED | INITIATOR +------------------------+ | +<---- Want to ADD an | Alternate IP Address | matching SELECTORs Set the proper SELECTORs | Do I want CHECK ? ---------------+ | YES NO v v Set NEW_IP/OLD_IP Set NEW_IP/OLD_IP CHECK bit to 0 CHECK bit to 1 | | | +<-------------------+ | Set ID parameter Set the I, O, N to 0 Set the H bit to 1 Send it to Responder | +--------------------------+ |ADDITIONAL_IP_ADDRESS_SENT| +--------------------------+ Initiator : Sending SA_UPDATE_ADDRESSES +--------------------------+ |ADDITIONAL_IP_ADDRESS_SENT| INITIATOR +--------------------------+ | +<---- RESPONSE is received | from Responder Does RESPONSE carries ERROR -----+ | YES NO v The Alternate IP The Alternate IP Address cannot be used Address can be used. Eventually forward Eventually ACKnowledge ERROR to ULP it to ULP | | +<-------------------+ | +------------------------+ | MOBIKE-X_SUPPORTED | +------------------------+ Migault Expires March 5, 2010 [Page 28] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 Initiator : Going back to MOBIKE-X_SUPPORTED State +------------------------+ | MOBIKE-X_SUPPORTED | RESPONDER +------------------------+ | +<---- SA_ADDITIONAL_IP_ADDRESS | received | NO ADDITIONAL_IP_ADDRESS has one ------------+ and only one ID parameters ? v NO | YES There is no ID parameter ? ----+ Insert it in RESPONSE | YES | +<---------------------------+ | | RESPONSE = UNACCEPTABLE IP Address fits local policies ? ---------+ PARAMETER v | YES NO v | | RESPONSE=UNACCEPTABLE_ADDRESSES | IP Address fits SPD ? -------------------+ | | YES NO v | Replace OLD_IP by NEW_IP RESPONSE=DOES_NOT_FIT_SPD | where SELECTOR indicates it | | | YES | | RESPONSE=VOID | | | | | CHECK=0 ? ----------------------+ | | | YES NO | | | Clear Alternate IP Addresses | | | List associated to SELECTORs | | | | | | | | | | +<------------------+<------+<--------------------+ | Send RESPONSE | +------------------------+ | MOBIKE-X_SUPPORTED | +------------------------+ Responder : Receiving ADDITIONAL_IP_ADDRESS 7.4. UPDATE Exchange The figure below illustrates the different possible IPsec configuration between the responder and the Initiator. The figure represents the different IKE_SA negotiated by one of the peer. The Initiator can have various IKE_SA to which are associated different Migault Expires March 5, 2010 [Page 29] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 SAs. : +-IKE_SA_0 | iID: INITIATOR (iIP) | rID: RESPONDER (rIP_1, ...,IP_n) | | | +-SA_1 : mode=Transport | : iID: iIP rID: rIP_1 | +-SA_j : mode=Transport | : iID: iIP rID: rIP_k | +-SA_m : mode=Tunnel : iID: iIP_vitual rID: rIP_1 : Tunnel header : : iID:iIP rID:rIP_1 : +-IKE_SA_l | iID: INITIATOR (iIP) | rID: RESPONDER (rIP_1, ...,IP_n) | | | +-SA_1 : mode=Transport | : iID: iIP rID: rIP_1 | +-SA_p : mode=Transport | : iID: iIP rID: rIP_k | +-SA_q : mode=Tunnel : iID: iIP_vitual rID: rIP_1 : Tunnel header : : iID:iIP rID:rIP_1 IKE configuration The UPDATE_SA_ADDRESSES Notify Payload already exists in MOBIKE [RFC4555]. In MOBIKE OLD_IP and NEW_IP are implicit. In MOBIKE-X also they can be implicitly or explicitly specified. OLD_IP and NEW_IP are specified with the IP parameter. Distinction between OLD and NEW is done thanks to the O and N bit. According to the IP parameter in the data field we consider the following cases : - NO IP parameter : is specified. Then the NEW_IP is the IP address in the IP header carrying the Notify Payload. The OLD_IP are all IP addresses associated to the Initiator. In SAs using the tunnel mode, only the outer IP address is considered. Migault Expires March 5, 2010 [Page 30] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 - A single OLD_IP parameter : is specified. Then the NEW_IP address is the one in the IP header of the message carrying the Notify Payload. OLD_IP is specified, and replaced by NEW_IP. The H and I bits of the OLD_IP specifies where in the SA the change occurs. - A single NEW_IP parameter : is specified. Then OLD_IP are all IP address associated to the Initiator. OLD_IP are replaced by the specified NEW_IP address. The H and I bits in the OLD_IP specifies where the update MUST be done. - One OLD_IP and one NEW_IP parameters : are specified. OLD_IP MUST be replaced by NEW_IP. The H and I bits MUST be the same on both OLD_IP and NEW_IP. Those values specify where the change occurs. If the H and I bits are not the same, then a UNACCEPTABLE_PARAMETERS Notify Payload MUST be sent as a response. In any other cases, an UNACCEPTABLE_PARAMETERS Notify Payload MUST be sent. Section 3.5 of [RFC4555] provides a description on how to change an IPsec SA in the tunnel mode case. The Initiator decides if a return routability check needs to be performed before updating the IKE_SA and SAs or not. Then updates the IKE_SA with the new IP address and set the "pending flag" of the IKE_SA. If The Initiator does not require the return routability check to be performed before the update, then, the Initiator updates the SAs and the IKE_SA. When updating the SAs, the Initiator should also consider NAT traversal mechanisms and in some cases enables UDP encapsulation of outgoing ESP packets as well as NAT-Keepalive packets. The Initiator MUST retransmit requests for which it has not received any responses with the updated IKE_SA, that is to say with the new address, send a UPDATE_SA_ADDRESSES Notify Payload and clear the "pending update" flag. MOBIKE [RFC4555] specifies that when the Responder receives the UPDATE_SA_ADDRESSES Notify Payload, it checks if that is the latest one received. The main reasons to that check was that peers were only using one IP address always targeted by the UPDATE action. Such a check SHOULD NOT be performed with MOBIKE-X, since for a given Security Association different IP addresses can be updated independently. Some checks can be performed, but in this paper we believe the easiest way is to performed actions as they are being requested. The Responder considers the specified NAT options, checks the new IP address matches the local policy. If local policies do not match then the Responder MUST send a UNACCEPTABLE_ADDRESSES. If policies match, then the Responder updates the IKE_SA with the IP address Migault Expires March 5, 2010 [Page 31] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 taken from the IP header, send a response. Optionally it can perform a return routability check before updating the SAs. When updating the SAs, NAT options MUST be carefully considered. When the Initiator receives the response; it checks the considered UPDATE_SA_ADDRESSES is still to be considered. If no UNEXPECTED_NAT_DETECTED or UNACCEPTABLE_ADDRESSES Notify Payload are sent, the Initiator updates the SAs if not previously done, and take into account the NAT considerations. As mentioned in section 3.5 of [RFC4555], the Responder does not change the IPsec SA without receiving a UPDATE_SA_ADDRESSES Notify Payload unless the Initiator is unreachable. In that case, the Responder can use an Alternate IP Address. Updating a Security Association in a transport mode is done in a similar manner as it is done for a tunnel mode as described in in [RFC4555]. The difference is that updating a tunnel header requires to change one parameter of the SA. This requires to check if that new IP address matches local policies. Changing the IP address of a transport mode SA requires also to check and eventually update the Security Policy Database as well as modifying the binding between the SPD and the SA. If the update cannot be performed because the SPD does not allow it, then the Responder MUST send a DOES_NOT_FIT_SPD Notify Payload. The Initiator MUST try with other IP addresses, so to enable the mobility. The Initiator can also send an UPDATE_SA_ADDRESSES Notify Payload to check wherever the update is possible or not. This is done thanks to the CHECK bit set to one. The CHECK bit is on the IP parameters. When no IP parameters are specified, than the Responder considers that CHECK is set to 0 and that the update MUST occur. When only one IP parameter is specified, then the CHECK bit value is explicitly set by the Initiator. When two IP parameters are specified, then the CHECK value of both parameters MUST be the same. If not, a UNACCEPTABLE_PARAMETERS Notify Payload MUST be sent. If both CHECK values are set to 1, then the update MUST NOT occurs. When both of them are set to 0, and the NEW_IP addresses matches both local and Security Policies, then the update MUST be performed. 7.5. UPDATE Exchange State Diagram The state diagram is not normative, and is provided only for clarification purposes. In that state diagram we assumed the Initiator specifies the NEW_IP and OLD_IP addresses when it is multihomed. Deciding when the OLD_IP and NEW_IP or the ID parameters SHOULD be added depends on the local hosts policies. Migault Expires March 5, 2010 [Page 32] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +------------------------+ | MOBIKE-X_SUPPORTED | INITIATOR +------------------------+ | +<---- Want to UPDATE SA | matching SELECTORs Can I use default values ---------------+ for NEW_IP and OLD_IP ? NO v | YES Explicitly specify v NEW_IP or/and OLD_IP Do I want CHECK ? ------+ | | YES NO | Do I want CHECK ? ---------------+ v | | YES NO v I need to specify at | v Set NEW_IP/OLD_IP least OLD_IP or NEW_IP | Set NEW_IP/OLD_IP CHECK bit to 0 with CHECK bit = 1 | CHECK bit to 1 UPDATE the SA | UPDATE the SA | | | | | | +<---------+<--------------+<-------------------+ | v Set ID parameter Send it to Responder | +------------------------+ |SA_UPDATE_ADDRESSES_SENT| +------------------------+ Initiator : Sending SA_UPDATE_ADDRESSES Migault Expires March 5, 2010 [Page 33] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +------------------------+ |UPDATE_SA_ADDRESSES_SENT| INITIATOR +------------------------+ | +<---- RESPONSE is received | from Responder Does RESPONSE carries ERROR -----+ | YES NO | Responder could not Has CHECK bit set to 1 ? ----+ proceed to UPDATE v NO | Eventually forward UPDATE SAs if not already | ERROR to ULP performed | | | | Has CHECK bit set to 0 ? ----+ +<---------------+ v NO | | CANCEL UPDATE if already | | performed | | | | | +<---------------+ | | | +--------------------+ | +------------------------+ | MOBIKE-X_SUPPORTED | +------------------------+ Initiator : Going back to MOBIKE-X_SUPPORTED State Migault Expires March 5, 2010 [Page 34] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +------------------------+ | MOBIKE-X_SUPPORTED | RESPONDER +------------------------+ | +<---- UPDATE_SA_ADDRESSES | received | NO UPDATE_SA_ADDRESSES has one -------------+ and only one ID parameters ? v NO ID_PARAM=ID There is no ID parameter ? ----+ | YES ID_PARAM=VOID v | YES | RESPONSE = UNACCEPTABLE +<--------------------------+ _PARAMETER | Insert ID_PARAM -----+ Has the SA_UPDATE_ADDRESSES -------------+ | no NEW_IP and no OLD_IP NO v | parameters Has the SA_UPDATE_ADDRESS --+ | | YES one and only one NEW_IP and NO| | Set NEW_IP = IPHEADER.IP_src /or one and only one OLD_IP | | Set OLD_IP = All iIPs parameters ? | | | | YES | | Set CHECK=0, I=0, H=1 Check H, I and CHECK bit | | | Set OLD_IP and NEW_IP | | | | v | +<--------------------------+ RESPONSE=UNACCEPTABLE| | _PARAMETER | NEW_IP fits local policies ? -------------+ Insert ID_PARAM --+ | | YES NO v | | | RESPONSE=UNACCEPTABLE_ADDRESSES | | | Insert ID_PARAM ------------+ | | NEW_IP fits SPD ? -----------------------+ | | | | YES NO v | | | Replace OLD_IP by NEW_IP RESPONSE=DOES_NOT_FIT_SPD | | | where SELECTOR indicates it Insert ID_PARAM | | | | YES | | | | RESPONSE=VOID | | | | | | | | | +<--------------------------+<---------------+<-+<-+ Send RESPONSE | +------------------------+ | MOBIKE-X_SUPPORTED | +------------------------+ Responder : Receiving UPDATE_SA_ADDRESSES Migault Expires March 5, 2010 [Page 35] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 7.6. Multihoming Exchanges ADD and REMOVE are the Multihoming actions, and the Notify Payloads associated to those actions are the ADD_SA_ADDRESS and REMOVE_SA_ADDRESS Notify Payloads. The Initiator sends an ADD_SA_ADDRESS or REMOVE_SA_ADDRESS Notify Payload, when it wants to ADD or REMOVE one IP address to the SA specified by the SELECTORs. The draft does not consider the case of the IKE_SA, since we consider that the IKEv2 application does not support Simultaneous use of multiple IP addresses. In the draft, we consider that if an IKE_SA is specified by the SELECTORs, then the Multihoming actions are simply skipped. The Notify Payloads only need to specify one single IP address, i.e the IP address to be ADDed or REMOVEd to or from the SA. This IP address can be explicitly specified using the IP parameter, or implicitly specified. When the IP address is implicitly specified, no IP parameters are specified in the data field. The Responder assume the IP address to be considered is the one in the IP header. When the IP is specified, then the ADD or REMOVE action can be CHECKed, which means that the Initiator does not expect the change to be performed. Of course, when the IP address is implicitly specified, the Responder considers that the ADD or REMOVE operation MUST occur. When the IP address is specified, the I and H bits indicates, where the IP address MUST be ADDEd or UPDATEd -- in IP Header in transport or tunnel mode, or inside the tunnel when the tunnel mode is used. Of course, such bits cannot be specified when the IP address is implicitly specified. In that case, the Responder ADDs or REMOVE any IP address in the IP Header of tunnel and transport mode -- that is to say not the inner IP addresses. As with the UPDATE_SA_ADDRESSES Notify Payload, when the Responder receives it, it does not have to check if that is the last received Notify Payload. When the Responder receives an ADD_SA_ADDRESS or a REMOVE_SA_ADDRESS Notify Payload, it checks if the data field is formatted correctly or not. If other parameters then ID or IP parameter is specified or more then one IP parameter is specified, an UNACCEPTABLE_PARAMETER Notify Payload is sent as a response. If the data field does not carry one IP parameter, the Responder considers the IP address in the IP header of the received message, the operation has to be performed, and I bit is set to zero, H bit is set to 1. If the IP address is specified in the data field, the Responder reads the CHECK bit, the I Migault Expires March 5, 2010 [Page 36] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 bit and H bit values. Then the Responder performs a check-policy operation. When an ADD action is requested, then the Responder MUST check if the new IP address matches local and Security Policies. If the IP address does not match local policies, then an UNACCEPTABLE_IP_ADDRESS Notify Payload is sent as a response. If the IP address does not match the Security Policy, then a DOES_NOT_FIT_SPD Notify Payload is sent as a response. When a REMOVE action is requested, the Responder checks at least one IP address is still associated to the SA, if there is only one IP address associated to the SA, then REMOVing it will close the SA. 7.7. Multihoming Exchanges State Diagrams Multihoming Actions are very similar as UPDATE actions. Migault Expires March 5, 2010 [Page 37] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +------------------------+ | MOBIKE-X_SUPPORTED | RESPONDER +------------------------+ | +<---- ADD_SA_ADDRESS | received | NO ADD_SA_ADDRESS has one --------------+ and only one ID parameters ? v NO | YES There is no ID parameter ? ----+ ID_PARAM=ID ID_PARAM=VOID YES | | | v +<---------------------------+RESPONSE = UNACCEPTABLE | ID_PARAMETER Has the ADD_SA_ADDRESS -------------+ Insert ID_PARAM ----+ no IP parameters ? NO v | | YES Has the ADD_SA_ADDRESS one ----+ | Set IP= IPHEADER.IP_src and only one IP parameter ? NO| | | | YES | | | Check CHECK, I and H | | Set CHECK=0, I=0, H=1 bits value ? v | | | RESPONSE=UNACCEPTABLE| +<--------------------------+ ADD_SA_ADDRESS | | PARAMETER | IP fits local policies ? -----------------+ Insert ID_PARAM --+ | | YES NO v | | | RESPONSE=UNACCEPTABLE_ADDRESS | | | Insert ID_PARAM ----------+ | | IP fits SPD ? --------------------------+ | | | | YES NO v | | | ADD IP to the SA RESPONSE=DOES_NOT_FIT_SPD | | | where SELECTOR indicates it Insert ID_PARAM | | | | YES | | | | RESPONSE=VOID | | | | | | | | | +<--------------------------+<-------------+<---+<-+ Send RESPONSE | +------------------------+ | MOBIKE-X_SUPPORTED | +------------------------+ Responder : Receiving ADD_SA_ADDRESS Migault Expires March 5, 2010 [Page 38] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +------------------------+ | MOBIKE-X_SUPPORTED | RESPONDER +------------------------+ | +<---- REMOVE_SA_ADDRESS | received | NO REMOVE_SA_ADDRESS has one --------------+ and only one ID parameters ? v NO | YES There is no ID parameter ? ----+ ID_PARAM=ID ID_PARAM=VOID YES | | | v +<---------------------------+RESPONSE = UNACCEPTABLE | ID_PARAMETER Has the REMOVE_SA_ADDRESS -------------+ Insert ID_PARAM -----+ no IP parameters ? NO v | | YES Has REMOVE_SA_ADDRESS one ----+ | Set IP= IPHEADER.IP_src and only one IP parameter ? NO| | | | YES | | | Check CHECK, I and H | | Set CHECK=0, I=0, H=1 bits value ? | | | | v | +<--------------------------+ RESPONSE=UNACCEPTABLE| | YES ADD_SA_ADDRESS | ADD IP to the SA PARAMETER | where SELECTOR indicates it Insert ID_PARAM | | YES | | RESPONSE=VOID | | | | | +<------------------------------------+<-----------+ Send RESPONSE | +------------------------+ | MOBIKE-X_SUPPORTED | +------------------------+ Responder : Receiving REMOVE_SA_ADDRESS 8. SELECTOR Notify Payload The SELECTOR payloads are used to select one, a set of SA or IKE_SA where an ACTION MUST occur. ACTIONs are represented by the UPDATE_SA_ADDRESSES, ADD_SA_ADDRESS, REMOVE_SA_ADDRESS or ADDITIONAL_IP_ADDRESS Notify Payloads. The Initiator might use more than one SELECTOR that constitutes a SELECTOR_SET. The Initiator has to build the SELECTOR_SET carefully according to the considered Notify Payload that follows SELECTOR_SET. Migault Expires March 5, 2010 [Page 39] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 A SELECTOR_SET is a collection of SELECTOR Notify Payloads. An SA or an IKE_SA matches the SELECTOR_SET if a match occurs with at least one SELECTOR of the SELECTOR_SET. A SELECTOR Notify Payload carries different parameters. An SA or an IKE_SA matches a SELECTOR if all parameters of the SELECTOR Notify Payload match the SA or the IKE_SA. By default the SELECTOR value is IKE_SA_AND_CHILD_SA. In this document, this means that UPDATE_SA_ADDRESSES, ADD/REMOVE_SA_ADDRESS Notify Payload apply to the IKE_SA and the CHILD SAs, and the ADDTIONAL_IP_ADDRESS applies to the IKE_SA. The SELECTOR_SET precedes the action -- that is to say the UPDATE_SA_ADDRESSES, the ADD/REMOVE_SA_ADDRESS or the ADDITIONAL_IP_ADDRESS Notify Payloads. There can be multiple action Notify Payloads, and all of them apply to the SAs or IKE_SA that matches the SELECTOR_SET. To specify that the SELECTOR_SET MUST NOT be considered anymore, the Initiator MUST add an END_OF_SELECTOR Notify Payload. If an action Notify Payload is placed right after the END_OF_SELECTOR Notify Payload, then there is no SELECTOR_SET specified for this action and the default value is consider -- IKE_SA_AND_CHILD_SA or IKE_SA. On the other hand, another SELECTOR_SET can also be defined after the END_OF_SELECTOR Notify Payload. When a SELECTOR_SET is defined, any other Notify Payload different from UPDATE_SA_ADDRESSES or ADDITIONAL_IP_ADDRESS Notify Payload remove the SELECTOR_SET and set it to its default value. The SELECTOR_SET is a regular expression like, and can be modelized as SELECTOR_SET = SELECTOR_1 OR ... OR SELECTOR_n. . A match with the SELECTOR_SET occurs with an IKE_SA or an SA, if there is a match with SELECTOR_1 OR ... OR a match occurs with SELECTOR_n. If SELECTOR_i has k PARAMETERs, then a match occurs with SELECTOR_i and IKE_SA or a SA if a match occurs with PARAMETER_1 AND ... AND a match occurs with PARAMETERS_k. The initiator sending a SELECTOR Notify Payload it is recommended the Initiator proceeds as mentioned below : - 1 : When the Initiator wants to send actions, it SHOULD check to which SA or IKE_SA the action has to be proceeded. The different SAs or IKE_SA can be described with different SELECTOR. If no selectors applied, the default value is IKE_SA_AND_CHILD_SA. The Initiator either has set its SELECTOR_SET or consider the default values. Migault Expires March 5, 2010 [Page 40] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 - 2 : The Initiator might group the different actions that matches the same SELECTOR_SET. There are many way the different actions can be bound to SELECTOR_SET and SELECTOR_SET adapted to the actions so that to reduce the number of payload or the size of the message sent. This is not specified in this paper. - 3 : The Initiator appends all the action to the SELECTOR_SET. - 4 : If a SELECTOR_SET is explicitly built, append an END_OF_SELECTOR Notify Payload. The procedure described here is what we thought was the simplest way to implement it and is not normative. There are possible optimizations since without SELECTOR specification the assumed default value is IKE_SA_AND_CHILD_SA. When receiving a SELECTOR Notify Payload, the Responder MUST proceed as described below. We define states for the SELECTOR_SET variable. The SELECTOR_SET state is NULL when it has not been initiated. In that case the Responder will have to consider the default values of the SELECTOR_SET. When the SELECTOR_SET is being built, it is in a START state. This means the SELECTOR_SET value is not yet fixed, but is on its way to be set. When the SELECTOR_SET value is set then its state is ESTABLIHED. When an error is encounter, like an unexpected Notify Payload found, an unknown parameter, or badly formed parameter, then the SELECTOR_SET sets a variable ERROR to 1. When the Responder receives a message, the SELECTOR_SET value is set to NULL and the ERROR variable is set to 0. - 1 : If the Notify Payload type are UPDATE_SA_ADDRESSES, ADD_SA_ADDRESS, REMOVE_SA_ADDRESS or ADDITIONAL_IP_ADDRESSES, then check the SELECTOR_SET state value. If the SELECTOR_SET state value is NULL then perform the action with the default value of the SELECTOR_SET -- IKE_SA or IKE_SA_AND_CHILD_SA. If the SELECTOR_SET state value is START, then the Responder sets the SELECTOR_SET state to ESTABLISHED, and applies the Notify Payload to the SA or IKE_SA specified by the SELECTOR_SET value. If the SELECTOR_SET state value is ESTABLISHED, apply the Notify Payload to the IKE_SA and SA specified by the SELECTOR_SET value. - 2 : If the Notify Payload is of type SELECTOR, then check the SELECTOR_SET state value. If the SELECTOR_SET state value is NULL, then set the SELECTOR_SET state value to START and consider the SELECTOR parameters, and add them to the SELECTOR_SET value. If the SELECTOR_SET state value is START then add the SELECTOR parameters to the SELECTOR_SET value. If the SELECTOR_SET state value is ESTABLISHED then clear the SELECTOR_SET value, create a new SELECTOR_SET value, set the SELECTOR_SET state value to START and add the parameters of the SELECTOR to the SELECTOR_SET value. Migault Expires March 5, 2010 [Page 41] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 - 3 : If the Notify Payload is of type END_OF_SELECTOR clear the SELECTOR_SET value and set the SELECTOR_SET state value to NULL. - 4 : If the Notify Payload is of any other type, or if the Payload is different from the Notify type, then clear the SELECTOR_SET value and set the SELECTOR_SET value to NULL. The Responder MUST send a UNEXPECTED_PAYLOAD_AFTER_SELECTOR Notify Payload, set the variable ERROR to 1 and skip the Payloads - 5 : When the Responder performs the action Notify Payloads and do not find any SA or IKE_SA it SHOULD send an UNMATCHED_SELECTOR_SET. - 6 : When the Responder finds an Notify Payload, it does not understand, it sends an error message as specified in [RFC4306] if the critical flag is set to one. No error message otherwise. The Responder MUST set the variable ERROR to 1 and go on analyzing Notify Payload. - 7 : When the Responder do not understand the parameters of a SELECTOR Notify Payload, it MUST send an error UNACCEPTABLE_SELECTOR_PARAMETER Notify Payload. It MUST set the ERROR variable to 1. - 8 : When the Responder performs an action and the ERROR variable is set to 0, it performs it in a regular way. When the ERROR variable is set to 1. - 9 : When the Responder performs an action and the ERROR variable is set to 0, it performs it in a regular way. When the ERROR variable is set to 1. 9. SELECTOR State diagrams Migault Expires March 5, 2010 [Page 42] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +------------------------+ INITIATOR | MOBIKE-X_SUPPORTED | +------------------------+ | +<--- Initiator sends an ACTION | and prepares the SELECTOR_SET Does the IKE_SA_AND_CHILD value for SELECTOR_SETapplies ? -------+ NO | YES | Select the concerned SA | (can be a list of SPI) | | | Append all SELECTOR | | | Append ACTION | | | Append END_OF_SELECTOR | | | +<------------------------------+ | Send All Notify Payloads | +--------------------------+ |ACTION_NOTIFY_PAYLOAD_SENT| +--------------------------+ Initiator : Handling with SELECTORs Migault Expires March 5, 2010 [Page 43] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +--------------------+ SELECTOR_SET_VALUE= | MOBIKE-X_SUPPORTED | RESPONDER IKE_SA_AND_CHILD_SA +--------------------+ SELECTOR_STATE=NULL | NO ERROR=0 Notify Payload ------------------+ is SELECTOR ? v NO YES | Notify Payload is --------------+ SELECTOR_STATE= -----+ ACTION ? v NO NULL ? | YES | NO Notify Payload is ---+ YES | | SELECTOR_STATE ------+ END_OF_SELECTOR ? | Create a new | =ESTABLISHED | YES | | SELECTOR_SET | Apply ACTION to | SELECTOR_STATE=NULL | Add SELECTOR Value | SELECTOR_SET ? | SELECTOR_SET_VALUE= | SELECTOR_STATE=START | | | IKE_SA_AND_CHILD_SA | | | +--------------------+| | | +--------------------+| | MOBIKE-X_SUPPORTED || +--------------------+| | MOBIKE-X_SUPPORTED || +--------------------+| | MOBIKE-X_SUPPORTED || +--------------------+| | +--------------------+| +---------+ +-----------+ +-------------+ v NO v NO v NO SELECTOR_STATE= -----+ SELECTOR_STATE= ---+ SELECTOR_STATE ------+ START ? | NULL ? | =START ? | YES | | YES | | | | Add SELECTOR Value | Apply ACTION to | SEND UNEXPECTED_ | | | SELECTOR_SET | PAYLOAD_AFTER_SELECTOR| +--------------------+| =IKE_SA_AND_CHILD_SA | ERROR=1 | | MOBIKE-X_SUPPORTED || | | | | +--------------------+| +--------------------+| +--------------------+| +---------+ | MOBIKE-X_SUPPORTED || | MOBIKE-X_SUPPORTED || v +--------------------+| +--------------------+| SELECTOR_STATE= (SELECTOR +-----------+ +-------------+ ESTABLISHED ? _STATE=START)| |(SELECTOR_STATE YES | v |=ESTABLISHED or Clear SELECTOR_SET SELECTOR_STATE= v= NULL) Set ERROR=0 ESTABLISHED SELECTOR_STATE=NULL Create new SELECTOR_SET Set SELECTOR_SET_VALUE ERROR=0 Add SELECTOR Value Apply ACTION to | SELECTOR_STATE=START SELECTOR_SET +--------------------+ | | | MOBIKE-X_SUPPORTED | +--------------------+ +--------------------+ +--------------------+ | MOBIKE-X_SUPPORTED | | MOBIKE-X_SUPPORTED | +--------------------+ +--------------------+ Responder : Receiving SELECTOR Notify Payloads Add SELECTOR Value to SELECTOR_SET consists of check the SELECTOR syntax before adding it. If an error occurs, then the Responder set the ERROR value to 1. Migault Expires March 5, 2010 [Page 44] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 Apply ACTION to SELECTOR_SET consists of checking the ERROR value of SELECTOR_SET. If ERROR is set to 1, then the ACTION is not performed and a UNEXPECTED_PARAMETER Notify Payload is returned. When the ACTION cannot be performed because no SA matches the SELECTORs, then an UNMATCHED_SELECTOR_SET Notify Payload is sent. This latest Notify Payload is more a warning message than an error message. 10. ID Notify Payload Parameter The ID parameter purpose is to bind a query Notify Payload to the response Notify Payload. An Initiator can send multiple Notify Payload, some of them might require a response for example if the Notify Payload generating an error. When the Responder receives a Notify Payload with an ID parameter in its data field, which requires a response, it MUST insert the ID parameter in its response Payload. It is the responsibility of the Initiator to make sure the ID parameters are different, so that it can easily bind the response with the query Notify Payload. 11. Packet Format 11.1. Notify Payload The Notify Payload is define in[RFC4306] section 3.10. This Notify Payload is represented as below : 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol ID ! SPI Size ! Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Notification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notify Payload In our case, we would fill the different fields as defined below : Migault Expires March 5, 2010 [Page 45] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 - Protocol ID (1 octet) : As mentioned in [RFC4306] "If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment." In our case the Protocol is 1, since it is related to the IKE_SA - SPI Size (1 octet) : [RFC4306] mentions "h in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE_SA, the SPI Size MUST be zero.". In our case the SPI is set to zero. - Notify Message Type (2 octets) : [RFC4306] mentions "Specifies the type of notification message." - SPI (variable length) [RFC4306] mentions "Security Parameter Index." In our case this field should not appear. - Notification Data (variable length) [RFC4306] mentions "Informational or error data transmitted in addition to the Notify Message Type. Values for this field are type specific (see below)." 11.2. Notify Message -- status type In this section we provide assignment numbers for the different Type of Notify Payloads. Such numbers are added to the list provided by the IANA at http://www.iana.org/assignments/ikev2-parameters. 11.2.1. MOBIKE_SUPPORTED The MOBIKE_SUPPORTED Notify Payload MUST carry the VERSION parameter. They can be one or more VERSION parameter payload. The VERSION value for MOBIKE [RFC4555] is 1. The VERSION value for MOBIKE-X as defined in this draft is 2. The Protocol ID and SPI Size fields are set to zero. The Notify Message Type for MOBIKE_SUPPORTED is defined in [RFC4555] and the Type code is 16396. 11.2.2. ADDITIONAL_IP_ADDRESS The ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS are defined in MOBIKE [RFC4555], and type codes are 16397 and 16398. In this document, we consider only ADDITIONAL_IP6_ADDRESS as ADDITIONAL_IP_ADDRESS, so its type is 16398. Migault Expires March 5, 2010 [Page 46] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 11.2.3. NO_ADDITIONAL_ADDRESS The NO_ADDITIONAL_ADDRESS is defined in [RFC4555] and the type code is 16399. 11.2.4. SELECTOR The SELECTOR Notify Payload is used to define who the ADDITIONAL_IP_ADDRESS, the UPDATE_SA_ADDRESSES. The Notify Message Type for SELECTOR is 40961 -- We define it as private use number but it should be assigned by the IANA. The SELECTOR Payload MUST carry selectors parameters in its data payload. The currently supported parameters are IP, SPI, IKE_AND_CHILD_SA and ALL_IKE_SA. 11.2.5. END_OF_SELECTOR The END_OF_SELECTOR defines where the SELECTOR_SET stop being used. The Notify Message Type for SELECTOR is 40962. 11.2.6. UPDATE_SA_ADDRESSES The UPDATE_SA_ADDRESSES is described in [RFC4555] and in this paper. The type code is 16400. The main difference between description in [RFC4555] and this paper is the UPDATE_SA_ADDRESSES Notify Payload can carry the NEW_IP and the OLD_IP address as parameters in its data field. 11.2.7. ADD_SA_ADDRESS Notify Payload The ADD_SA_ADDRESS requests the Responder to ADD an IP address to an associated SA. The type code is 40962. This Notify Payload can specify the IP address to ADD. 11.2.8. REMOVE_SA_ADDRESS Notify Payload The REMOPE_SA_ADDRESS requests the Responder to REMOVE an IP address to an associated SA. The type code is 40963. This Notify Payload can specify the IP address to ADD. 11.2.9. Notify Message -- status type table Migault Expires March 5, 2010 [Page 47] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 Name Value Reference ---- ----- --------- MOBIKE_SUPPORTED 16396 [RFC4555] SELECTOR 40961 END_OF_SELECTOR 40962 ADDITIONAL_IP_ADDRESS 16398 [RFC4555] NO_ADDITIONAL_ADDRESS 16399 [RFC4555] UPDATE_SA_ADDRESSES 16400 [RFC4555] ADD_SA_ADDRESS 40963 REMOVE_SA_ADDRESS 40964 Notify Message -- status type -- Private values 11.3. Notify Message -- error type 11.3.1. MOBIKE_UNSUPPORTED_VERSION This Notify Payload is used by the Responder to indicate, it does not understand the MOBIKE version proposed by the Initiator. When sending this Notify Payload, the Responder MUST add the supported version of MOBIKE it supports. This Notify Payload can also be used to cancel the use of MOBIKE-X. In that specific case, the version number is NONE. The Type value associated to this message is the first value of Notify Message error type value assigned for private use, that is to say : 8192. 11.3.2. UNACCEPTABLE_ADDRESS This Notify Payload is defined in [RFC4555]. This Notify Payload is sent by the Responder when it cannot accept the IP address specified in an UPDATE_SA_ADDRESSES. This Notify Payload MUST be sent when the IP address does not match the local policies. More specifically it cannot be used instead of a DOES_NOT_FIT_SPD Notify Payload. The UNACCEPTABLE_ADDRESS type value is 40 as specified in [RFC4555]. 11.3.3. DOES_NOT_FIT_SPD This message MUST be send by the Responder when the proposed IP address is reject by the SPD. The type value associated to the message is 8193. 11.3.4. UNACCEPTABLE_PARAMETERS This message MUST be sent as response when parameters are not well understood by the Responder. Migault Expires March 5, 2010 [Page 48] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 11.3.5. UNEXPECTED_PAYLOAD_AFTER_SELECTOR The message is sent when the responder does not find a expected payload after the SELECTOR payload. It is more a warning message then an error message. The type value associated to it is 8195. 11.3.6. UNMATCHED_SELECTOR_SET This message MUST be sent when no SA matches the mentioned SELECTOR_SET. The type value associated to the message is 8196. 11.3.7. Notify Message -- error type table Name Value Reference ---- ----- --------- MOBIKE_UNSUPPORTED_VERSION 8192 UNACCEPTABLE_ADDRESS 40 [RFC4555] DOES_NOT_FIT_SPD 8193 UNACCEPTABLE_PARAMETER 8194 UNEXPECTED_PAYLOAD_AFTER_SELECTOR 8195 UNMATCHED_SELECTOR_SET 8196 Notify Message -- error type -- Private values 11.4. Notify Parameters 11.4.1. VERSION 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | NBR | VERS | VERS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VERS | VERS | PADDING | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VERSION parameter Where : Migault Expires March 5, 2010 [Page 49] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 TYPE : 16 bits to define the VERSION parameter (1) NBR : 8 bits to define the number of proposed version. This field defines the where the PADDING bits starts as well as the length of the PADDING field. VERS : 8 bits to define the version number. MOBIKE is being assigned the version number 1, the current description in this paper is being assigned the version number 2. The NONE value MUST be only carried by the MOBIKE-X_UNSUPPORTED Notify Payload, and means that MOBIKE-X messages MUST NOT be anymore considered. PADDING : 8, 16 or 24 bits set to zero. The PADDING length is such that the VERSION parameter length is a multiple of 32 bits. Its length is derived from NBR. Consider L = (NBR+1) %4. This value represents the PADDING number of bytes. Name Value Reference ---- ----- --------- Reserved 0 MOBIKE 1 MOBIKE-X 2 Reserved to IANA 3-254 NONE 255 VERSION 11.4.2. SPI 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | SPI_SIZE | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SPI ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SPI size Where : TYPE : 8 bits to define the SPI parameter. Migault Expires March 5, 2010 [Page 50] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 SPI_SIZE : 8 bits to define the size of the SPI. The size is expressed in number of bytes. RESERVED : 16 bits set to zero and reserved for future use. SPI : the SPI value. 11.4.3. IP 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE |M| V |C|O|N|H|I| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multihoming Information (optional) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IP address value : IPv4 or IPv6 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Where : TYPE : 8 bits to define the IP parameter. M (Multihoming) bit : 1 bit that specifies whether Multihoming Information Payload (MIP) is present in the IP parameter. M set to 1 means that the MIP is present; otherwise M is set to 0. This bit is not optional and its value MUST be set properly. V (Version) bits : 2 bits that specifies the version of the IP address. . V set to 0 means the IP is an IPv4, V set to 1 means the IP is an IPv6. Those bits MUST be set properly and their value is not optional. C (CHECK) bit : 1 bit that specifies the Initiator does not want the action to be performed but does only want to check the IP address matches local and security policies. When this bit is set to 1, then the ACTION is only CHECKed, otherwise, the ACTION is performed. O (Old) bit : 1 bit that specifies that the IP address is considered as the OLD_IP, that is to say the address to replace. To specify the IP parameter is an OLD_IP, the bit MUST be set to 1. O bit or N bit MUST be used when the IP address is a parameter of the UPDATE_SA_ADDRESSES Notify Payload. Other ACTION ignores those bits. If both OLD_IP and NEW_IP are explicitly specified and the CHECK bit has not the same value in both IP parameter, then a UNACCEPTABLE_PARAMETER Migault Expires March 5, 2010 [Page 51] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 will be sent by the Responder. N (New) bit : 1 bit that specifies that the IP address is considered as the NEW_IP, that is to say the value replacing the OLD_IP. To specify the IP parameter is a NEW_IP, the N bit MUST be set to 1. (see O bit for more information). H (IP Header) bit : 1 bit that specifies the IP address is use for routing purpose. If the SA is using the transport mode, then setting H to 1 means the IP address has to be considered. If the SA is using the tunnel mode, the outer IP address is considered. The H and I bits are not optional and MUST be set for ADD, REMOVE and UPDATE actions. ADDITIONAL_IP_ADDRESS assumes H=1, I=0. I (Inner IP) bit : 1 bit that specifies the IP address is a inner IP address. When set to 1, it means the IP address is the inner IP address of a tunnel mode. (see the H bit for more explanation). RESERVED : 16 bits set to zero and reserved for future. IP4 : 32 bits to define the IPv4 address. IP6 : 128 bits to define the IPv6 address. Name Value Reference ---- ----- --------- IPv6 0 IPv4 1 Reserved to IANA 2-3 Version 11.4.4. Multihoming Information Payload (MIP) This section defines the Multihoming Information Payload. Multihoming Information can be useful for Multihoming purposes. That is to say such information is only useful for multihoming management entity. In this document the only Multihoming Management Entity is the IKEv2 application. In fact we do not consider here communication between IKEv2 and ULP. As a result, the MIP SHOULD be only used associated with ADDITIONAL_IP_ADDRESS Notify Payload. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PREFERENCE | CLASS | R | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address Start Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address Life Time | Migault Expires March 5, 2010 [Page 52] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multihoming Information Payload Where : PREFERENCE : 8 bits preference associated to every IP addresses in the range. The PREFERENCE bits are especially useful to select the more adequate IP address. CLASS : 8 bits the class of the IP, that is to say specify whether the IP address is a HoA, a CoA when using MIP6, or NONE when the IP address has no specific class value. If there is no class associated to the IP address, then the class field MUST be set to NONE. R (Reachability) : 2 bits that specifies is the peer is reachable with this IP address, or not. NO_INFO means the Initiator does not have specific information on the reachability of the IP address. This is the default value. RESERVED : 15 bits set to zero and reserved for future. IP address Start Time : 32 bits that indicates the time the Responder SHOULD wait after it has received the IP parameter before considering it. This time expresses the number of seconds the Responder has to wait. By default, the Initiator should set it to zero. IP address Life Time : 32 bits that specifies how long the data is valid. A zero value means an infinite number of seconds. Name Value Reference ---- ----- --------- NONE 0 HoA 1 CoA 2 Reserved to IANA 3-255 CLASS Name Value Reference ---- ----- --------- NO_INFO 0 REACHABLE 1 UNREACHABLE 2 Reserved to IANA 4 R Migault Expires March 5, 2010 [Page 53] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 11.4.5. IPSEC_MODE 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | IPSEC_MODE | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPSEC_MODE Where : TYPE : 8 bits to define the IPSEC_MODE parameter. IPSEC_MODE : 8 bits the IPsec mode to consider. Encapsulation Mode is defined in [RFC2407] and in http://www.iana.org/assignments/isakmp-registry. RESERVED : 16 bits set to zero and reserved for future. From http://www.iana.org/assignments/isakmp-registry, we get the following values : Name Value Reference ---- ----- --------- Reserved 0 [RFC2407] Tunnel 1 [RFC2407] Transport 2 [RFC2407] UDP-Encapsulated-Tunnel 3 [RFC3947] UDP-Encapsulated-Transport 4 [RFC3947] Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use. IPSEC_MODE 11.4.6. IPSEC_PROTO 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | IPSEC_PROTO | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPSEC_PROTO Where : Migault Expires March 5, 2010 [Page 54] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 TYPE : 8 bits to define the IPSEC_PROTO parameter. IPSEC_MODE : 8 bits the IPsec protocol to consider. Protocols are defined [RFC4306] and in http://www.iana.org/assignments/ikev2-parameters RESERVED : 16 bits set to zero and reserved for future. From http://www.iana.org/assignments/ikev2-parameters, we get the following values : Protocol ID Protocol Reference ----------- ---------------------- --------- 0 Reserved [RFC4306] 1 IKE [RFC4306] 2 AH [RFC4306] 3 ESP [RFC4306] 4 FC_ESP_HEADER [RFC4595] 5 FC_CT_AUTHENTICATION [RFC4595] 6-200 Unassigned [RFC4306] 201-255 Private use [RFC4306] Registry Name: IKEv2 Traffic Selector Types Reference: [RFC4306] Registration Procedures: Expert Review IPSEC_PROTO 11.4.7. SELECTOR_SPECIFIC_VALUE_PARAMETER 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | VALUE | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SELECTOR_SPECIFIC_VALUE_PARAMETER Where : TYPE : 8 bits to define the SELECTOR_PARAMETER parameter. VALUE : 8 bits that specifies special SELECTORS values. RESERVED : 16 bits set to zero and reserved for future. The different values for VALUES are the following : Migault Expires March 5, 2010 [Page 55] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 SELECTOR VALUES Protocol Reference ----------- ---------------------- --------- 0 Reserved 2 IKESA_AND_CHILD_SA 3 ALL_IKE_SA 4-255 Reserved to IANA SELECTOR_SPECIFIC_VALUE_PARAMETER 11.4.8. ID 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | RESERVED | IDENTIFIER | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ID parameter Where : TYPE : 16 bits to define the VERSION parameter. RESERVED : 8 bits set to zero and reserved for future. IDENTIFIER : 16 bits The identifier for the Notify Payload. The identifier does not need to be chosen randomly, and do not intend to provide any protection, it only reason is to distinguish different Notify Payloads. 11.4.9. Parameter Code Type Registry: Value NOTIFY PARAMETER - MOBIKE-X Reference ------------ ---------------------------- --------- 0 Reserved 1 VERSION 2 SPI 3 IP 4 IPSEC_MODE 5 IPSEC_PROTO 6 SELECTOR_SPECIFIC_VALUE_PARAMETER 7 ID 8-255 Reserved to IANA Parameter code types Migault Expires March 5, 2010 [Page 56] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 12. Security Considerations Security considerations are the same as those expressed in MOBIKE [RFC4555]. This document extends the Security Associations manipulation. More specifically, with the use of SELECTORs payloads, one user can select a random SPI, or other IKE_SAs. For this reason, we recommend that unless specified otherwise for special uses, the SELECTORs SHOULD apply to only a subset of Security Associations. The subset of Security Association is Security Association that has been negotiated between the same peer's ID and with the same authentication method. By doing so, we protect peer from weak authentication method. An attacker will not be able to hijack a peer's identity using a weak authentication method. We also prevent, a peer to interfere with others peer Security Associations. 13. IANA Considerations The new Notify Message status Type to be added are : Name Value Reference ---- ----- --------- SELECTOR 40961 END_OF_SELECTOR 40962 Notify Message -- status type -- Private values The new Notify Message error Type to be added are : Name Value Reference ---- ----- --------- MOBIKE_UNSUPPORTED_VERSION 8192 DOES_NOT_FIT_SPD 8193 UNACCEPTABLE_PARAMETER 8194 UNEXPECTED_PAYLOAD_AFTER_SELECTOR 8195 UNMATCHED_SELECTOR_SET 8196 Notify Message -- error type -- Private values A New field is created : MOBIKE-X parameters. The following values are : Migault Expires March 5, 2010 [Page 57] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 Registry: Value NOTIFY PARAMETER - MOBIKE-X Reference ------------ ---------------------------- --------- 0 Reserved 1 VERSION 2 SPI 3 IP 4 IPSEC_MODE 5 IPSEC_PROTO 6 SELECTOR_SPECIFIC_VALUE_PARAMETER 7 ID MOBIKE-X PARAMETERS A New field is created : SELECTOR_VALUE parameters. The following values are : SELECTOR VALUES Protocol Reference ----------- ---------------------- --------- 0 Reserved 2 IKESA_AND_CHILD_SA 3 ALL_IKE_SA 4-255 Reserved to IANA SELECTOR_PARAMETER Name Value Reference ---- ----- --------- NONE 0 HoA 1 CoA 2 Reserved to IANA 3-255 CLASS Name Value Reference ---- ----- --------- NO_INFO 0 REACHABLE 1 Unreachable 2 Reserved to IANA 4 R Migault Expires March 5, 2010 [Page 58] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 14. Acknowledgments Daniel Migault is partly funded by 3MING, a research project supported by the French 'National Research Agency'(ANR). 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. 15.2. Informative References [I-D.mglt-ipsec-mm-requirements] Migault, D., "IPsec mobility and multihoming requirements : Problem statement", draft-mglt-ipsec-mm-requirements-00 (work in progress), September 2009. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006. Migault Expires March 5, 2010 [Page 59] Internet-Draft MOBIKE-X for mobility and multihoming September 2009 Author's Address Daniel Migault Orange Labs R&D 38 rue du General Leclerc 92794 Issy-les-Moulineaux Cedex 9 France Phone: +33 1 45 29 60 52 Email: mglt.ietf@gmail.com Migault Expires March 5, 2010 [Page 60]