[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]