IKEv2 Mobility and Multihoming                                T. Kivinen
(mobike)                                                   Safenet, Inc.
Internet-Draft                                             H. Tschofenig
Expires: August 24, 2005 January 19, 2006                                        Siemens
                                                       February 20,
                                                           July 18, 2005

                     Design of the MOBIKE Protocol
                    draft-ietf-mobike-design-02.txt
                    draft-ietf-mobike-design-03.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she become becomes
   aware will be disclosed, in accordance with
   RFC 3668. Section 6 of 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.

   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 August 24, 2005. January 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The MOBIKE (IKEv2 Mobility and Multihoming) working group is
   developing protocol extensions to for the Internet Key Exchange Protocol version
   2 (IKEv2) to (IKEv2).  These extensions should enable its use in the context where there are an efficient management of
   IKE and IPsec Security Associations when a host possesses multiple IP
   addresses per host or and/or where IP addresses of an IPsec host change over time
   (for example, due to mobility).

   This document discusses the involved network entities, and the
   relationship between IKEv2 signaling and information provided by
   other protocols and the rest of the network. protocols.  Design decisions for the base MOBIKE protocol,
   background information and discussions within the working group are
   recorded.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1   Mobility Scenario  . . . . . . . . . . . . . . . . . . . .  7
     3.2   Multihoming Scenario . . . . . . . . . . . . . . . . . . .  8
     3.3   Multihomed Laptop Scenario . . . . . . . . . . . . . . . .  9
   4.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Design Considerations  . . . . . . . . . . . . . . . . . . . . 13
     5.1   Indicating Support for MOBIKE  . . . . . . . . . . . . . . 13
     5.2   Changing a Preferred Address and Multihoming Multi-homing Support  . . . 13
       5.2.1   Storing a single or multiple addresses . . . . . . . . 14
       5.2.2   Indirect or Direct Indication  . . . . . . . . . . . . 15
       5.2.3   Connectivity Tests using IKEv2 Dead-Peer Detection . . 16
     5.3   Simultaneous Movements . . . . . . . . . . . . . . . . . . 17
     5.4   NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 18
     5.5   Changing addresses or changing the paths . . . . . . . . . 19 20
     5.6   Return Routability Tests . . . . . . . . . . . . . . . . . 20
     5.7   Employing MOBIKE results in other protocols  . . . . . . . 22 23
     5.8   Scope of SA changes  . . . . . . . . . . . . . . . . . . . 23 24
     5.9   Zero Address Set . . . . . . . . . . . . . . . . . . . . . 24 25
     5.10  IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25
     5.11  Message Representation . . . . . . . . . . . . . . . . . . 25 26
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 30
   9.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 31
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 32
     10.1  Normative references . . . . . . . . . . . . . . . . . . . 32
     10.2  Informative References . . . . . . . . . . . . . . . . . . 32
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
       Intellectual Property and Copyright Statements . . . . . . . . 35

1.  Introduction

   The purpose of IKEv2 is used for performing mutual authentication and establishing
   and maintaining to mutually authenticate two hosts, establish
   one or more IPsec security associations (SAs). Security Associations (SAs) between them, and
   subsequently manage these SAs (for example, by rekeying or deleting).
   IKEv2 establishes enables the hosts to share information that is relevant to both
   the usage of the cryptographic state (such as algorithms that should be employed
   (e.g., parameters required by cryptographic algorithms and session keys
   keys) and algorithms) as
   well to the usage of local security policies, such as non-cryptographic
   information (such as IP addresses).

   The current about the traffic that should experience protection.

   IKEv2 and IPsec documents explicitly say assumes that the IPsec
   and an IKE SAs are SA is created implicitly between the IP
   address pair that is used during the protocol execution when
   establishing the IKEv2 SA.  This means that there is that, in each host, only one
   IP address pair is stored for the IKEv2 SA,
   and this single IP address pair is used SA as an outer endpoint address part of a single IKEv2
   protocol session, and, for tunnel mode IPsec SAs.  After SAs, the IKE SA is created there is hosts places this
   single pair in the outer IP headers.  Existing documents make no
   way
   provision to change them. this pair after an IKE SA is created.

   There are scenarios where this one or both of the IP address might change, even
   frequently. addresses of this
   pair may change during an IPsec session.  In some cases principle, the problem could be solved by rekeying IKE SA
   and all the corresponding IPsec and IKE SAs could be re-established after the IP
   address has changed.  However, this can be problematic, as the device
   might be too slow to rekey the
   SAs that often, and other scenarios the rekeying and required IKEv2
   authentication might require for this task.  Moreover, manual user interaction (SecurID cards etc).
   Due to these reasons, a mechanism to update the IP addresses tied to
   (for example when using SecurID cards) might be required as part of
   the IPsec and IKEv2 SAs authentication procedure.  Therefore, an automatic
   mechanism is needed.  MOBIKE provides solution to the
   problem of the updating neeed that updates the IP addresses stored associated with the
   IKE SAs SA and the IPsec SAs.  MOBIKE provides such a mechanism.

   The charter work of the MOBIKE working group requires IKEv2
   [I-D.ietf-ipsec-ikev2], and as IKEv2 assumes therefore this document is
   based on the assumption that the RFC2401bis
   architecture [I-D.ietf-ipsec-rfc2401bis] mobility and multi-homing extensions
   are developed for IKEv2 [I-D.ietf-ipsec-ikev2].  As IKEv2 is used, built on
   the architecture described in RFC2401bis [I-D.ietf-ipsec-rfc2401bis],
   all protocols developed will use within the MOBIKE working group must be
   compatible with both IKEv2 and the architecture described in
   RFC2401bis.  MOBIKE  The document does not aim to neither provide support
   IKEv1 [RFC2409] or nor the old RFC2401 architecture described in RFC2401 [RFC2401].

   This document is structured as follows.  After introducing some
   important terms in Section 2 we list a few number of relevant usage scenarios are
   discussed in Section 3, to
   illustrate possible deployment environments. 3.  Section 4 discusses the interoperation of
   MOBIKE depends on
   information from with other sources (e.g., detect an address change) which
   are discussed protocols and processes that may run in Section 4. the local
   machine.  Finally, Section 5 discusses design considerations effecting
   affecting the MOBIKE protocol.  The document concludes
   with security considerations in Section 6. 6
   with security considerations.

2.  Terminology

   This section introduces some useful terms for a MOBIKE protocol.

   Peer:

      Within the terminology that is used in this document we refer to IKEv2 endpoints as peers.
   document.

   Peer:

      A peer is an IKEv2 endpoint.  In addition, a peer implements the
      MOBIKE extensions, as defined in this and therefore IKEv2. related documents.

   Available address:

      An address is said to be available if the following conditions are
      fulfilled:
      met:

      *  The address has been assigned to an interface of the node. interface.

      *  If the address is an IPv6 address, we additionally require that (a)
         that the address is valid as defined in the sense of RFC 2461 [RFC2461], and that
         (b) that the address is not tentative as defined in the sense of RFC 2462
         [RFC2462].  In other words, we require the address assignment is
         complete so that communications can
         to be started. complete.

         Note that this explicitly allows an address to be optimistic as
         defined in [I-D.ietf-ipv6-optimistic-dad].

      *  If the
         sense of [I-D.ietf-ipv6-optimistic-dad] even though
         implementations are probably better off using other addresses
         as long as there address is an alternative.
      *  The address IPv6 address, it is a global unicast or
         unique site-local address
         [I-D.ietf-ipv6-unique-local-addr]. address, as defined in [I-D.ietf-ipv6-unique-
         local-addr].  That is, it is not an IPv6
         link-local or site-local address. link-local.  Where
         IPv4 is considered, it is not an RFC 1918 [RFC1918] address.

      *  The address and interface is acceptable for use sending and
         receiving traffic according to a local policy.

      This definition is reused taken from
      [I-D.arkko-multi6dt-failure-detection] [I-D.arkko-multi6dt-failure-
      detection]

      .

   Locally Operational Address:

      An available address is said to be locally operational when if it is available
      and its use is locally known to be possible locally. and permitted.  This
      definition is taken from [I-D.arkko-multi6dt-failure-detection].

   Operational address pair:

      A pair of operational addresses are said to be an operational
      address pair, iff if and only if bidirectional connectivity can be
      shown between the two addresses.  Note that sometimes it is
      necessary to consider a 5-tuple when connectivity on a per-flow level between two
      endpoints need needs to be tested.  This differentiation might be
      necessary to address
      load balancers, certain Network Address Translation types or
      specific firewalls.  This definition is taken from
      [I-D.arkko-multi6dt-failure-detection] [I-D.arkko-
      multi6dt-failure-detection] and enhanced to fit adapted for the MOBIKE context.
      Although it is possible to further differentiate unidirectional
      and bidirectional operational address pairs pairs, only bidirectional
      connectivity is relevant for to this document and unidirectional
      connectivity is out of scope.

   Path:

      The route taken sequence of routers traversed by the MOBIKE and/or and IPsec packets sent via the IP
      address of one peer to a specific destination address of
      exchanged between the other
      peer. two peers.  Note that the this path might may be effected
      affected not only by the involved source and destination IP addresses
      addresses, but also by the selected transport
      protocol and transport protocol identifier. protocol.  Since MOBIKE and
      IPsec packets have a different appearance on the wire they might
      be routed along a different path. path, for example by load balancers.
      This definition is taken from [RFC2960] and modified adapted to fit the MOBIKE
      context.

   Primary Path:

      The primary path is sequence of routers traversed by an IP packet that carries the destination and
      default source address that will
      be put into a packet outbound and destination addresses is said to be the peer by default. Primary
      Path.  This definition is taken from [RFC2960] and modified adapted to fit the
      MOBIKE context.

   Preferred Address:

      An

      The IP address on which of a peer prefers to receive which MOBIKE messages and IPsec protected data traffic. traffic should
      be sent by default.  A given peer has only one active preferred
      address at a given point in time (ignoring time, except for the small time period
      where it needs to switch switches from the an old preferred
      address to a new preferred address). address.  This
      definition is taken from [I-D.ietf-hip-mm] and modified adapted to fit the
      MOBIKE context.

   Peer Address Set:

      We denote the two peers in this Mobike of a MOBIKE session by peer A and peer B.
      A peer address set is a the subset of locally operational addresses
      of peer A that are is sent to peer B. A policy available at peer A
      indicates which addresses to include are included in the peer address set.
      Such a policy might be impacted by manual configuration created either manually or
      by automatically
      through interaction with other protocols mechanisms that indicate new
      available addresses.

   Terminology for different regarding NAT types, such as types (e.g.  Full Cone, Restricted Cone,
   Port Restricted Cone and Symmetric, Symmetric), can be found in Section 5 of
   [RFC3489].  For mobility related terminology, such as terminology (e.g.  Make-before-break
   or Break-before-make Break-before-make) see [RFC3753].

3.  Scenarios

   The

   In this section we discuss three typical usage scenarios for the
   MOBIKE protocol can be used in different scenarios.  Three of
   them are discussed below. protocol.

3.1  Mobility Scenario

   Figure 1 shows a break-before-make mobility scenario where a mobile
   node attaches to, for example a wireless LAN, to obtain connectivity changes its point of network attachment.  Prior to some security gateway.  This security gateway might connect the change,
   the mobile node to had established an IPsec connection with a corporate network, security
   gateway which offered, for example, access to a 3G network or to some other corporate network.
   The initial IKEv2 exchange takes that facilitated the set up of the IPsec SA(s)
   took place along over the path labeled as 'old path' from path'.  The involved packets
   carried the MN using its old MN's "old" IP address via and were forwarded by the
   old "old"
   access router (OAR) towards to the security gateway (GW).  The IPsec
   tunnel mode terminates there but the decapsulated data packet will
   typically address another destination.  Since only MOBIKE
   communication from the MN to the gateway is relevant for this
   discussion the end-to-end communication between the MN and some
   destination is not shown in Figure 1.

   When the MN moves to a new changes its point of network and attachment, it obtains a new
   IP address from
   a new access router (NAR) it is using statefu address configuration techniques or via the responsibility
   stateless address autoconfiguration mechanism.  The goal of MOBIKE MOBIKE,
   in this scenario, is to avoid
   restarting enable the IKEv2 exchange from scratch.  As a result, MN and the GW to continue using
   the existing SAs and to avoid setting up a new IKE SA.  A protocol
   exchange, denoted by 'MOBIKE Address Update' , will perform Update', enables the
   necessary peers to
   update their state update. as necessary.

   Note that in a break-before-make mobility scenario the MN obtains a the new IP
   address after reachability to it can no longer be reached at the old IP address has been
   lost.  MOBIKE is also assumed to work in scenarios where the mobile
   node is able to establish connectivity with address.  In
   a make-before-break scenario, the new IP address while
   still being MN is, for a given period of time,
   reachable at both the old and the new IP address.  MOBIKE should work
   in both the above scenarios.

                          (Initial IKEv2 Exchange)
                    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
       Old IP   +--+        +---+                    v
       address  |MN|------> |OAR| -------------V     v
                +--+        +---+ Old path     V     v
                 .                          +----+   v>>>>> +--+
                 .move                      | R  | -------> |GW|
                 .                          |    |    >>>>> |  |
                 v                          +----+   ^      +--+
                +--+        +---+ New path     ^     ^
       New IP   |MN|------> |NAR|--------------^     ^
       address  +--+        +---+                    ^
                    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
                          (MOBIKE Address Update)

              ---> = Path taken by data packets
              >>>> = Signaling traffic (IKEv2 and MOBIKE)
              ...> = End host movement

                        Figure 1: Mobility Scenario

3.2  Multihoming Scenario

   Another scenario where MOBIKE might be used usage scenario is between two depicted in Figure 2.  In this
   scenario, the MOBIKE peers are equipped with multiple interfaces (and
   multiple IP addresses).
   Figure 2 shows two such multi-homed peers.  Peer A has two interface cards with two IP addresses
   addresses, IP_A1 and IP_A2.  Additionally, Peer IP_A2, and peer B
   also has two IP addresses, IP_B1
   and IP_B2.  Each peer selects one of its IP addresses as the
   preferred address which will subsequently be is used for subsequent communication.
   Various reasons, such as problems with the
   interface card, might (e.g hardware or network link failures), may require
   a peer to switch from one IP address interface to
   the other one. another.

     +------------+                                  +------------+
     | Peer A     |           *~~~~~~~~~*            | Peer B     |
     |            |>>>>>>>>>> * Network   *>>>>>>>>>>|            |
     |      IP_A1 +-------->+             +--------->+ IP_B1      |
     |            |         |             |          |            |
     |      IP_A2 +********>+             +*********>+ IP_B2      |
     |            |          *           *           |            |
     +------------+           *~~~~~~~~~*            +------------+

              ---> = Path taken by data packets
              >>>> = Signaling traffic (IKEv2 and MOBIKE)
              ***> = Potential future path through the network
                     (if Peer A and Peer B change their preferred
                      address)
                      Figure 2: Multihoming Scenario

   Note that MOBIKE does not aim to support load balancing between
   multiple IP addresses.  That is, each peer uses only one of the
   available IP addresses at a given point in time.

3.3  Multihomed Laptop Scenario

   In the multihomed laptop

   The third scenario we consider is about a laptop, which has multiple
   interface cards and therefore several ways to connect to a the network.
   It might may for example have a fixed Ethernet, WLAN, GPRS, Ethernet card, a WLAN interface, a
   GPRS adaptor, a Bluetooth interface or USB hardware in order to send IP packets.  A number of hardware.  Not all
   interfaces might are connected to a the network over time depending on at all times for a number of
   reasons (e.g., cost, availability of certain link layer technologies,
   user convenience).  Note  The mechanism that a policy for selecting a
   network interface based on cost, etc.  is out of scope for MOBIKE.
   For example, the user can disconnect himself from the fixed Ethernet,
   use the office WLAN, and then later leave the office and start using
   GPRS during determines which interfaces
   are connected to the trip home.  At home he might use WLAN.  At a certain network at any given point in time multiple interfaces might be connected.  As such, the
   laptop is a multihomed device.  In any case, outside
   the IP address scope of the
   individual interfaces are subject to change.

   The user desires to keep the established IKE-SA and IPsec SAs alive
   all the time without MOBIKE protocol and, as such, this document.
   However, as the need laptop changes its point of attachment to re-run the initial IKEv2 exchange
   which could require user interaction as part
   network, the set of IP addresses under which the authentication
   process.  Furthermore, even laptop is reachable,
   changes too.

   Even if IP addresses change due to interface switching or mobility,
   the IP source and destination address obtained via the configuration payloads within IKEv2 and used inside
   remain unaffected.  The IP address obtained via the IKEv2
   configuration payloads allow the configuration of the inner IP
   address of the IPsec
   tunnel remains unaffected, i.e., tunnel.  As such, applications might not detect
   any change at all.

4.  Framework

   The working group will develop a MOBIKE protocol which needs to
   perform the following functionality: operations:

   o  Ability to  inform the other peer about the peer address set

   o  Ability to  inform the other peer about the preferred address

   o  Ability to  test connectivity along a path and thereby to detect an outage
      situation

   o  Ability to  change the preferred address

   o  Ability to  change the peer address set

   o  Ability to deal with Network Address Translation devices

   The technical details of these functions are discussed below.
   Although the interaction with other protocols is important for MOBIKE will have to operate correctly interact with other mechanisms, the
   working group is chartered to leave this aspect outside the scope.

   When a MOBIKE peer initiates a protocol exchange with its MOBIKE peer it needs to define a
   peer address set based on the IP addresses available
   addresses.  It might to it.  The peer
   may want to make this peer address set available to the other peer.  The IKEv2
   Initiator does not need to explicitly indicate
   its preferred which of the addresses in the
   peer address since it set is already using its preferred address.  The outgoing IKEv2 and MOBIKE messages use this  This is because the
   Initiator has to place its preferred address as into the source IP
   address and field of the MOBIKE peer IP header with the initial message exchange.
   Additionally, the Initiator expects incoming signaling messages to be sent to
   arrive at this address.  Interaction with
   other protocols at the MOBIKE host is required to build the  The peer address set and the preferred address.
   address are defined based on interaction with other components within
   a host.  In some cases cases, the peer address set is may be available before
   the initial protocol exchange and does not change during the lifetime
   of the IKE-SA.  The preferred address might change due to policy
   reasons.  Section 3 describes three scenarios in which the peer
   address set is modified (by adding or deleting addresses).  In these
   scenarios the preferred address
   needs to be changed may change as well.

   Modifying

   A modification of the peer address set or changing a change of the preferred
   address typically is
   effected by the host's result of the MOBIKE peer's local policy and
   by the interaction with other protocols (such as DHCP or IPv6
   Neighbor Discovery).

   Figure 3 shows an example protocol interaction at between a pair of
   MOBIKE peer. peers.  MOBIKE interacts with the IPsec engine using the
   PF_KEY interface
   [RFC2367] to API [RFC2367].  Using this API, the MOBIKE daemon can create
   entries in the Security Association (SAD) and Security Policy Databases.
   Databases (SPD).  The IPsec engine might may also interact with IKEv2 and MOBIKE.  Established state at
   MOBIKE daemon using this API.  The content of the Security Policy and
   Security Association Databases determines what traffic is protected
   with IPsec databases has an impact in which fashion.  MOBIKE, on the incoming and outgoing data traffic.  MOBIKE other hand, receives
   information from other protocols running in a number of sources that may run both in kernel-mode
   and
   user-mode, as previously mentioned. in user-mode.  Information relevant for MOBIKE
   is might be stored in
   a database.  The contents of such a database, referred as Trigger database, that guides along with the
   occurrence of events of which the MOBIKE in its decisions process is notified, form
   the basis on which MOBIKE decides regarding the set of available
   addresses, the peer address set, and the preferred address.  Policies might
   may also affect the selection process.

   Building and maintaining

   The a peer address set and selecting or changing
   a the preferred address based on locally available information is,
   however, insufficient.  This information needs to be
   available to the other peer and in peer.  In order to address various certain failure cases it is
   necessary to test
   cases, MOBIKE should perform connectivity along tests between the peers
   (potentially over a number of different paths).  Although a path.  A number of
   address pairs might may be available for connectivity tests but such tests, the most important
   are the source and is
   the pair (source address, destination IP address address) of the primary path
   since these addresses are path.
   This is because this pair is selected for sending and receiving
   MOBIKE signaling messages and for sending and receiving IPsec protected data traffic.  If a problem along this primary
   path is detected (e.g., due to a router failure) it is necessary to
   switch to the a new primary path.  Optionally, periodic testing  In order to be able to do so quickly,
   it may be helpful to perform connectivity tests of other paths might be useful to
   determine when
   periodically.  Such a technique would also help in identifying
   previously disconnected path becomes paths that become operational.

                           +-------------+       +---------+
                           |User-space   |       | MOBIKE  |
                           |Protocols    |  +-->>| Daemon  |
                           |relevant for |  |    |         |
                           |MOBIKE       |  |    +---------+
                           +-------------+  |         ^
   User Space                    ^          |         ^
   ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++
   Kernel Space                  v          |         v
                               _______      |         v
       +-------------+        /       \     |    +--------------+
       |Routing      |       / Trigger \    |    | IPsec        |
       |Protocols    |<<-->>|  Database |<<-+  +>+ Engine       |
       |             |       \         /       | | (+Databases) |
       +-----+---+---+        \_______/        | +------+-------+
             ^   ^               ^             |        ^
             |   +---------------+-------------+--------+-----+
             |                   v             |        |     |
             |             +-------------+     |        |     |
      I      |             |Kernel-space |     |        |     |   I
      n      |   +-------->+Protocols    +<----+-----+  |     |   n
      t      v   v         |relevant for |     |     v  v     v   t
      e +----+---+-+       |MOBIKE       |     |   +-+--+-----+-+ e
      r |  Input   |       +-------------+     |   | Outgoing   | r
      f |  Packet  +<--------------------------+   | Interface  | f
    ==a>|Processing|===============================| Processing |=a>
      c |          |                               |            | c
      e +----------+                               +------------+ e
      s                                                           s
              ===> = IP packets arriving/leaving a MOBIKE node
              <->  = control and configuration operations

                            Figure 3: Framework

   Please note that Figure 3 is only one way illustrates an example of implementing MOBIKE. how a MOBIKE
   implementation could work.  Hence, it serves illustrative purposes
   only.

   Extensions of the PF_KEY interface required by MOBIKE are also within
   the scope of the working group.  Finally, certain optimizations in for
   wireless
   environment will environments are also be covered.

5.  Design Considerations

   This section discusses aspects affecting the design of the MOBIKE
   protocol.

5.1  Indicating Support for MOBIKE

   In order for MOBIKE to function correctly, function, both peers must implement
   this extension.  We propose extensions to IKEv2 described below for the MOBIKE support.
   extension of IKEv2.  If only one peer supports MOBIKE, then or none of the peers supports MOBIKE,
   then, whenever an IP address changes, IKEv2 will just run IKEv2.  Specifically, have to be re-run in
   order to create a node new IKE SA and the respective IPsec SAs.  In
   MOBIKE, a peer needs to be able confident that its address change messages
   are understood by the other peer.  If these messages are not
   understood, it is possible that connectivity between the peers is
   lost.

   One way to
   guarantee ensure that a peer receives feedback on whether or not its address change
   messages are understood by its
   corresponding peer.  Otherwise an address change may render the
   connection useless, and it other peer, is important that both sides realize this
   as early by using IKEv2
   messaging for MOBIKE and to mark some messages as possible.

   Ensuring that "critical".
   According to the IKEv2 specification, such messages are understood can in be arranged either have to be
   understood by marking some IKEv2 payloads critical so that they are either
   processed the receiver, or an error message has to be returned to
   the sender.

   A second way to ensure receipt of the above-mentioned feedback is returned, by
   using Vendor ID payloads or via a Notify.

   The first solution approach is to use Vendor ID payloads that are exchanged during the initial IKEv2 exchange using a specific string denoting MOBIKE to
   signal the support of the MOBIKE protocol.  This ensures that in all
   cases a MOBIKE capable node knows
   exchange.  These payloads would then indicate whether its or not a given
   peer supports the MOBIKE or
   not.

   The second solution protocol.

   A third approach uses would use the Notify payload which is also used for
   NAT detection (via NAT_DETECTION_SOURCE_IP and
   NAT_DETECTION_DESTINATION_IP).
   NAT_DETECTION_DESTINATION_IP payloads).

   Both a Vendor ID and a Notify payload might may be used to indicate the
   support of certain extensions.

   Note that the node a MOBIKE peer could also attempt to execute MOBIKE
   opportunistically with the critical bit set when an address change
   has occurred.  The drawback of this approach is, however, that the an
   unnecessary MOBIKE message exchange is introduced.

   Although Vendor ID payloads and Notifications are technically
   equivalent
   equivalent, Notifications are already used in IKEv2 as a capability
   negotiation mechanism mechanism.  Hence, Notifications and is therefore Vendor ID payloads
   are the preferred mechanism. mechanisms.

5.2  Changing a Preferred Address and Multihoming Multi-homing Support

   From MOBIKE's point of view multihoming view, support for multi-homing is integrated inherently
   provided by
   supporting the fact that it manages a peer address set of peer addresses, rather
   than a single address and
   protocol address.  Further, MOBIKE provides mechanisms to change to use
   a new peer's preferred IP address.

   From a protocol point of view each  Each peer needs to learn the
   preferred address and the peer address set either implicitly or explicitly. set.

5.2.1  Storing a single or multiple addresses

   One design decision is whether an IKE-SA should store be associated with a
   single IP address or multiple IP addresses as part of the peer address set. addresses.  One option is that the other end a
   peer can provide a list of addresses to its counterpart which can
   then be used as destination addresses.

   Note that MOBIKE does not support load balancing, i.e., only one IP
   address is set to a preferred address at a time and changing the
   preferred address typically requires some MOBIKE signaling.

   Another option is to only communicate one address to the other peer
   and both peers only use that address when communicating.  If this
   preferred
   address cannot be used anymore then an address update is sent to the
   other peer changing that changes the preferred address.

   If

   Alternatively, if peer A provides A, for example,provides a peer address set
   with multiple IP addresses then peer B can recover from a failure of
   the preferred address on its
   own, meaning that when without further communication with peer A. That
   is, if it detects that the primary path does not work anymore it can
   either switch to a new preferred address locally (i.e., causing changing the
   source IP address of outgoing MOBIKE messages to
   have a non-preferred address) messages) or to try an IP
   address from A's peer address set. set (i.e., changing the destination
   address).  If peer B only received a single IP address as the A's
   peer IP address set from peer A
   for A then peer B can only change its own preferred address.  The other end has  Peer B
   would have to wait for an address update from peer A with a new IP
   address in order to fix the problem.

   The main advantage about using of storing only a single IP address for the remote host
   peer is that it makes retransmission easy, and handling easier.  Moreover, it also
   simplifies the recovery procedure.  The peer, peer whose IP address changed, changed
   must start the recovery process and send the new IP address to the
   other peer.
   Failures  However, connectivity failures along the path are not
   well covered addressed with advertising a single IP address.

   The single IP address approach will does not work if both peers happen to
   loose change
   their IP address addresses at the same time (due to, say, the failure of
   one of the links that time, for example if both nodes hosts move
   simultaneously, even though multiple addresses are connected to).  It may also
   require available to the
   two peers.  The IKEv2 implementation might also require window size
   to be larger than 1, especially if only
   direct indications are used.  This is 1 because the host MOBIKE peer needs to be able to send
   the IP address change notifications before it can switch switches to another address, and depending
   address.  Depending on the occurrence of return routability checks,
   retransmissions policies etc, it and similar message exchanges a window size
   larger than 1 might be hard required to make the protocol
   such that it works deal with window size of 1 too. more than one pending
   response at the same time.  Furthermore, the single IP address
   approach does not really benefit much from indirect indications as
   the peer receiving these indications might not be able to fix the
   situation by itself (e.g., even if a peer receives an ICMP host
   unreachable message for the old IP address, it cannot try other another IP addresses,
   address, since they are unknown). it does not know any).

   The problems with IP address lists are lie mostly in its their complexity.
   Notification and recovery processes are more complex. complicated.  Both ends
   can recover from the IP address changes.  However, both peers should
   not attempt to recover at the same time or nearly the same time as it
   this could cause them to lose connectivity.  The MOBIKE protocol is
   required to prevent this.

   The previous discussion is independent of the question of how many
   addresses to send in a single MOBIKE message.  A MOBIKE message might
   be able to carry more than one IP address (with the IP address list
   approach) or a single address only.  The latter approach has the
   advantage of dealing with NAT traversal in a proper fashion.  A NAT
   cannot does not change addresses
   carried inside the MOBIKE message but it can change IP address (and
   transport layer addresses) in the IP header and Transport Protocol
   header (if NAT traversal is enabled). enabled as part of configuration or
   dynamically through the NAT discovery mechanism.  Furthermore, a
   MOBIKE message carrying the peer address set could be idempotent
   (i.e., always resending the full address list) or the protocol may
   allow add/delete operations to be specified.
   [I-D.dupont-ikev2-addrmgmt],  [I-D.dupont-ikev2-
   addrmgmt], for example, offers an approach which defines add/delete
   operations.  The same is true for the dynamic address reconfiguration
   extension for SCTP [I-D.ietf-tsvwg-addip-sctp].

5.2.2  Indirect or Direct Indication

   An indication to change the preferred IP address might be either
   direct or indirect.

   Direct indication:

      A direct indication means that the other peer will send an message
      with the address change.  Such a message  This can, for example, be accomplished
      by having MOBIKE sending an authenticated address update
      notification with a different preferred address.

   Indirect indication:

      An indirect indication to change the preferred address can be
      obtained by observing the environment.  An indirect indication
      might, for example, be be the receipt of an ICMP message or
      information of about a link failure.  This information should be seen
      as a hint and might should not directly cause any changes to a change of the remote peer's
      preferred address.  Depending on the local policy policy, MOBIKE might may
      decide to perform a dead-peer detection exchange for the preferred
      address pair (or another address pair from the peer address set).
      When a peer detects that the other end started to use a different
      source IP address than before, it might want to authorize the new
      preferred address (if not already authorized).  A peer might also
      start  Authorization aims
      to ensure that a connectivity test of this particular address.  If a
      bidirectionally operational address pair peer is selected then MOBIKE
      needs to communicate this new preferred address allowed to its remote
      peer.

   MOBIKE will utilize both mechanisms, direct and indirect indications, use the indicated
      address.  Claiming to make be at an arbitrary address without
      performing a more intelligent decision which return-routability test or without verifying that the
      IP address pair to select as is listed within a certificate opens the preferred door for
      various denial of service attacks.  Hence a peer may also start a
      connectivity test of this particular address.  The

   If more information will be is available to the MOBIKE daemon then a more
   intelligent decision regarding the faster selection of a new primary path
   can be selected among the
   available candiates. made.

5.2.3  Connectivity Tests using IKEv2 Dead-Peer Detection

   This section discusses the suitability of the IKEv2 dead-peer
   detection (DPD) mechanism for connectivity tests between address
   pairs.  The basic IKEv2 DPD mechanism is not modified by MOBIKE but
   it needs to be investigated whether it can be used for MOBIKE
   purposes as well.

   The IKEv2 DPD mechanism is done by involves sending an empty informational
   exchange packet to a given address of the other peer, in which case remote peer.  On receipt,
   the other end will
   respond remote peer responds with an acknowledgement.  If no
   acknowledgement is received after a certain timeout period (and after
   couple of retransmissions), the
   other remote peer is considered to be not reachable.  Note that
   reachable at the address in question.  On the other hand, receipt of
   IPsec protected data traffic acknowledgement is also a guarantee that the other peer is alive.
   reachable at the address in question.

   When reusing dead-peer detection in MOBIKE for connectivity tests it
   seems to be reasonable to try other IP addresses (if they are
   available) in case of an unsuccessful connectivity test for a given
   address pair.  Dead-peer detection messages using a different address
   pair should use the same message-id as the original dead-peer
   detection message (i.e. they are simply retransmissions of the
   dead-peer dead-
   peer detection packet using different destination IP address).  If
   different message-id is used then it violates constraints placed by
   the IKEv2 specification on the DPD message with regard to the
   mandatory ACK for each message-id, causing the IKEv2 SA to be
   deleted.

   If MOBIKE strictly follows the guidelines of the dead-peer detection
   mechanism in IKEv2 then an IKE-SA should be marked as dead and
   deleted if the connectivity test for all available address pairs
   fails.  Note that this is not in-line with the approach used, for
   example, in SCTP where a failed connectivity test for an address does
   not lead to (a) the IP address or IP address pair to be marked as
   dead and (b) delete state.  Connectivity tests will be continued for
   the address pairs in hope that the problem will recover soon.  This
   comparison with SCTP aims to point at another IETF protocol that aims
   to address the multi-homing problem (although with a different scope
   and a different layer).

   Note that as IKEv2 implementations might may have a window size of 1, which
   prevents it from initiating and
   therefore be unable to initiate a dead-peer detection exchange while
   doing
   another exchange. exchange is pending.  As a result, all other exchanges experience
   the identical retransmission policy as used for the dead-peer
   detection.

   The dead-peer detection for the other IP address pairs can also be
   executed simultaneously (with a window size larger than 1), meaning
   that after the initial timeout of the preferred address expires, we
   send packets simultaneously to all other address pairs.  It is
   necessary to differentiate individual acknowledgement messages in
   order to determine which address pair is operational.  Therefore the
   source IP address of the acknowledgement should match the destination
   IP towards the message that was previously sent.

   Also the other peer is most likely going to reply only to the first
   packet it receives, and that first packet might not be the best (by
   whatever criteria) address pair.  The reason the other peer is only
   responding are
   subject to the first packet it receives is that implementations
   should not send retransmissions if they have just sent out an identical response message.  This is retransmission policy as used for the dead-
   peer detection.  To use a different policy for different message
   types seems to protect be reasonable.

   The dead-peer detection mechanism for the packet
   multiplication problem, which other IP address pairs can happen
   also be executed simultaneously if some node in the network
   queues up packets and then sends them to window size larger than 1,
   meaning that after the destination.  If initial timeout period of the
   destination were to reply preferred
   address expires, DPD packets are sent simultaneously to all of them then the other end will
   again see multiple packets, and will reply
   address pairs.  It is necessary to all differentiate acknowledgement
   messages in order to determine which address pair is operational.
   The source IP address of them, etc. the acknowledgement can be used for this
   purpose.

   The protocol should also be nice to the network, meaning, that when
   some core router link goes down, and a large number of MOBIKE clients notice it,
   this, they should not start sending a large number of messages while
   trying to recover from the problem.  This might may be especially
   bad particularly
   unfortunate because packets are may be dropped because of congestion in
   the congested network. first place.  If MOBIKE clients simultaneously try to test all
   possible address pairs by executing connectivity tests then the
   congestion problem only gets worse.

   Also note that the IKEv2 dead-peer detection is not sufficient for
   the return routability check.  See Section 5.6 for more information.

5.3  Simultaneous Movements

   MOBIKE does not aim to provide a full mobility solution which that allows
   simultaneous movements.  Instead, the MOBIKE working group focuses on
   selected scenarios as described in Section 3.  Some of the scenarios
   assume that one peer has a fixed set of addresses (from which some
   subset might be in use).  Thus it cannot move to the an address that is
   unknown to the other peer.  Situations in which both peers move and the
   movement notifications cannot reach the other peer
   simultaneously are outside the scope of the MOBIKE WG.  MOBIKE has
   not being been chartered to deal with the rendezvous problem, or with the
   introduction of any new entities in the network.

   Note that if only a single address is stored in the peer address set
   (instead of an address list) we might end up in the case where it
   seems that both peers changed their addresses at the same time. time (e.g.,
   if both nodes change their addresses at the same time).  This is
   something that the MOBIKE protocol must deal with.

   Three cases can be differentiated:

   o  Two mobile nodes obtain a new address at the same time, and then
      being unable to tell each other where they are (in a
      break-before-make break-before-
      make scenario).  This problem is called the rendezvous problem,
      and is traditionally solved by introducing another third entity,
      for example, the home agents (in Mobile IPv4/IPv6) or forwarding
      agents (in the Host Identity Protocol).  Essentially, solving this
      problem requires the existence of a
      stable additional infrastructure node somewhere. nodes.

   o  Simultaneous changes to addresses such that at least one of the
      new addresses is known to the other peer before the change
      occurred.

   o  No simultaneous changes at all.

5.4  NAT Traversal

   IKEv2 has support of supports legacy NAT traversal built-in. traversal.  This feature is known as NAT-T
   which allows IKEv2 to work even if a NAT along the path between the
   Initiator and the Responder modified modifies the source and possibly the
   destination IP address.  With NAPT even the transport protocol
   identifiers are modified (which then requires UDP encapsulation for subsequent
   exchanged IPsec protected data traffic).  Therefore, the MOBIKE
   daemon needs to obtain to required IP address information is taken from informationfrom the IP
   header (if a NAT was detected who rewrote that modified the IP header information) header) rather
   than from the protected payload.  This problem is not new and
   was discovered during the design is an
   issues of every mobility protocol where the only
   valuable most important
   information exchanged is the IP address information. .

   One of the goals in the MOBIKE protocol is to securely exchange one
   or more addresses of the peer address set and to securely set the
   primary address.  If no other protocol is used to securely retrieve
   the IP address and port information allocated by the NAT then it is
   not possible to tackle all attacks against MOBIKE.  Section 6
   discusses this aspect in more detail.  Various solution approaches to solve
   the problem have been presented:

   o  Securely retrieving IP address and port information allocated by
      the NAT using a protocol different from MOBIKE.  This approach is
      outside the scope of the MOBIKE working group since other working
      groups, such as MIDCOM and NSIS, already deal with this problem.
      The MOBIKE protocol can benefit from the interaction with these
      protocols.
      protocols but the interaction with these protocols it outside the
      scope of this document.

   o  Design a protocol in such a way that NAT boxes are able to inspect
      (or even participate) in the protocol exchange.  This approach was
      taken with HIP the Host Identity Protocol but is not an option for
      IKEv2 and MOBIKE. MOBIKE since most IKEv2 messages are encrypted with the
      established IKE SA.  This prevents the NAT from learning required
      information from the protocol exchange in a similar fashion as in
      HIP.

   o  Disable NAT-T support by indicating the desire never to use information
      from the (unauthenticated) header.  While this approach prevents
      some security problems it effectively disallows the protocol to
      work in certain environments. environments with NATs.

   There is no way to distinguish the cases where whether there is a NAT device
   along the path that modifies the header information in packets or whether an
   adversary mounts mounting an attack.  If a NAT is detected in during the
   creation of an IKE SA
   creation, SA, that should automatically disable the MOBIKE
   extensions and use NAT-T.

   A design question is whether NAT detection capabilities should be
   enabled only during the initial IKEv2 exchange or even at also during
   subsequent message exchanges.  If MOBIKE is executed with no NAT
   along the path when the IKE SA was created, then a NAT which appears
   after moving to a new network cannot be dealt with if NAT detection
   is enabled only during the initial exchange.  Hence, it might be is desirable
   to also support a scenario where a MOBIKE peer moves from a network which
   does subnet
   that is not deploy behind a NAT to a network which uses a private address
   space. that is.

   A NAT prevention mechanism can be used to make sure that no adversary
   can interact with the protocol if no NAT is expected between the
   Initiator and the Responder.

   The (reference?  Explanation?)

   Whether or not MOBIKE should support for NAT traversal is certainly one of the most
   important design decisions with an impact on other protocol aspects. decisions.

5.5  Changing addresses or changing the paths

   A design decision is whether it is enough for the MOBIKE protocol to
   detect dead address, addresses, or does it need also needs to detect also dead paths.  Dead
   address detection means that we only detect that we cannot get
   packets through refers to that remote address by using the local IP address ability to establish whether or not a
   given by the local IP-stack (i.e., local IP address selected normally by
   the routing information). pair is operational.  Dead path detection means that we need refers to
   try all possible local interfaces/IP addresses for each remote
   addresses, i.e., find all possible paths between
   the hosts and try
   them all ability to see which of them work establish whether or not all possible (local/remote)
   address pairs are operational (or at least find one working
   path). such pair).

   While performing just an one address change is simpler, the existence of
   locally operational addresses are is not, however, a guarantee that
   communications can be established with the peer.  A failure in the
   routing infrastructure can prevent the sent packets from reaching
   their destination.  Or a failure of an interface on one side can be
   related to the failure of an interface on the other side, making it
   necessary to change more than one address at a time.

5.6  Return Routability Tests

   Setting a new

   Changing the preferred address which is and subsequently used using it for
   communication is associated with an authorization decision: Is a peer
   allowed to use this address?  Does this peer own this address?  Two
   mechanisms have been proposed in the past to allow a peer to
   determine the answer to this question:

   o  The addresses a peer is using are part of a certificate.
      [RFC3554] which is introduced by this approach.  If the other peer
      is, for example, a security gateway with a limited set of fixed IP
      addresses, then the security gateway may have a certificate with
      all the IP addresses appear in the certificate.

   o  A return routability check is performed by the remote peer before
      the address is used
      to ensure updated in that peer's Security Association
      Database.  This is done in order provide a certain degree of
      confidence to the remote peer that local peer is reachable at the
      indicated address.

   Without performing taking an authorization decision a malicious peer can
   redirect traffic towards a third party or a blackhole.

   An IP address

   A MOBIKE peer should not be used use an IP addressed provided by another
   MOBIKE peer as a primary address without computing the authorization
   decision.  If the addresses are part of
   the certificate then it is not necessary to execute the weaker return
   routability test. the certificate then it is
   not necessary to execute the weaker return-routability test.  The
   return-routability test is a form of authorization check, although it
   provides weaker guarantees then the inclusion of the IP address as
   part of a certificate.  If multiple addresses are communicated to another
   peer as part of the
   remote peer address set then some of these addresses
   might may be already verified even
   if the primary address is still operational.

   Another option is to use the [I-D.dupont-mipv6-3bombing] approach
   which suggests to do perform a return routability test only if you have to
   send when an
   address update needs to be sent from some other address other than the
   indicated preferred address.

   Finally it would be possible not to execute return routability checks
   at all.  In case of indirect change notifications then we only move to the
   new preferred address after successful dead-peer detection (i.e., a
   response to a DPD test) on the new address, which is already a return
   routability check.  With a direct notifications notification the authenticated peer
   may have provided an authenticated IP address, thus we could address.  Thus it is would be
   possible to simply trust the other end. MOBIKE peer to provide a proper IP
   address.  There is no way external attacker an adversary can cause any attacks, but we are successfully launch an
   attack by injecting faked addresses since it does not protected from know the IKE SA
   and the corresponding keying material.A protection against an
   internal attacker, i.e. the authenticated peer forwarding its traffic
   to the new address. address, is not provided.  This might be an issue when
   extensions are added to IKEv2 that do not require authentication of
   end points (e.g., opportunistic security using anonymous Diffie-
   Hellman).  On the other hand we
   do know the identity of the peer in that
   case.

   As such, it  The identity of the IKEv2 Initiator and the IKEv2 Responder
   can take various forms: IP address, FQDN, DN, email address alike
   identifiers, etc.

   It seems that there it is also a policy issue when to schedule a
   return routability test.

   The basic format of the return routability check could be similar to
   dead-peer detection, but the problem is that if that fails then the
   IKEv2 specification requires the IKE SA to be deleted.  Because of
   this we might need to do some kind a different type of other exchange. exchange is required and thereby avoiding
   modifications to the IKEv2 specification.

   There are potential attacks if a return routability check does not
   include some kind of nonce.  In this attack the  The valid end point sends could send an
   address update notification for the a third party, trying to get all the
   traffic to be sent there, causing a denial of service attack.  If the
   return routability checks does not contain any cookies or other
   random information not known by to the other end, then that valid node
   could reply to the return routability checks even when it cannot see
   the request.  This might cause the other end a peer to turn move the traffic to
   there, even when a
   location where the true original recipient cannot be reached at
   this address. reached.

   The IKEv2 NAT-T mechanism does not perform any return routability checks.

   It simply uses the last seen source IP address used by the other peer
   as the destination address to send response packets.  An adversary
   can change those IP addresses, and can cause the response packets to
   be sent to wrong IP address.  The situation is self-fixing when the
   adversary is no longer able to modify packets and the first packet
   with true an unmodified IP address reaches the other peer.  In a certain
   sense mobility handling makes  Mobility
   environments make this attack more difficult for an adversary since
   it needs requires the adversary to be located somewhere along the path where on the individual
   paths ({CoA1, ..., CoAn} towards the destination IP address) have a
   shared path or if the adversary is located near the MOBIKE client
   then it needs to follow the users user mobility patterns.  With IKEv2
   NAT-T, the genuine client can cause third party bombing by
   redirecting all the traffic pointed to him to third party.  As the
   MOBIKE protocol tries to provide equal or better security than IKEv2
   NAT-T the MOBIKE protocol mechanism it should protect against these attacks.

   There might may be also return routability information available from the other
   parts of the system too (as shown in Figure 3), but the checks done might
   may have a different quality.  There are multiple levels for return
   routability checks:

   o  None, no tests

   o  A party willing to answer the return routability check is on located
      along the path to the claimed address. address ().  This is the basic form
      of return routability test.

   o  There is an answer from the tested address, and that answer was
      authenticated (including the address) to be from our peer.
      authenticated, integrity and replay protected.

   o  There was an authenticated authenticated, integrity and replay protected answer
      from the peer, but it is not guaranteed to be from originate at the tested
      address or path to it (because the peer can construct a response
      without seeing the request).

   The basic return routability checks do not protect against 3rd party
   bombing if the attacker is along the path, as the attacker can
   forward the return routability checks to the real peer (even if those
   packets are cryptographically authenticated).

   If the address to be tested is carried inside the MOBIKE packet too, payload,
   then the adversary cannot forward packets, thus it prevents forward packets.  Thus 3rd party
   bombings. bombings
   are prevented.

   If the reply packet can be constructed without seeing the request
   packet (for example, if there is no nonce, challenge or similar
   mechanism to show liveness), then the genuine peer can cause 3rd
   party bombing, by replying to those requests without seeing them at
   all.

   Other levels might only provide information a guarantee that there is someone a node at
   the IP address which replied to the request.  There might not be an is no indication that
   as to whether or not the reply was freshly generated or repeated, is fresh, and whether or not the
   request might may have been transmitted from a different source address.

   Requirements for a MOBIKE protocol for the return routability test
   might be able to verify that there is the same (cryptographically)
   authenticated node at the other peer and it can now receive packets
   from the IP address it claims to have.

5.7  Employing MOBIKE results in other protocols

   If MOBIKE has learned about new locations or verified the validity of
   an
   a remote address through a return routability test, check, can this
   information be useful for other protocols?

   When considering the basic MOBIKE VPN scenario, the answer is no.
   Transport and application layer protocols running inside the VPN
   tunnel have no consideration about are unaware of the outer addresses or their status.

   Similarly, IP layer tunnel termination at a gateway rather than a
   host endpoint limits the benefits for "other protocols" that could be
   informed -- all application protocols at the other side are running
   in a node that is unaware
   of IPsec, IKE, or MOBIKE.

   However, it is conceivable that future uses or extensions of the
   MOBIKE protocol make such information distribution useful.  For
   instance, if transport mode MOBIKE and SCTP were made to work
   together, it would likely potentially be useful for SCTP to learn about the
   new addresses at the same time as MOBIKE learns them. MOBIKE.  Similarly, various IP
   layer mechanisms might may make use of the fact that a return routability
   test of a specific type has already been performed.  However, in all of these cases careful consideration care should be
   applied.  This consideration should answer to questions such as
   whether other alternative sources exist for the information, whether
   dependencies are created between parts that prior to this had no
   dependencies, and what the impacts
   exercised in terms of number of messages or
   latency are. all these situations .

   [I-D.crocker-celp] discussed discusses the use of common locator information
   pools in a IPv6 multihoming multi-homing context; it assumed that both transport
   and IP layer solutions would are be used for providing multihoming, in order to support multi-homing,
   and that it would be beneficial for different protocols to coordinate
   their results in some manner, way, for instance by sharing experienced throughput
   information for of address pairs.  This may apply to MOBIKE as well,
   assuming it co-exists with non-IPsec protocols that are faced with
   the same multiaddressing or similar multi-homing choices.

   Nevertheless, all of this is outside the scope of current MOBIKE base
   protocol design and may be addressed in future work. (so why do you
   elaborate so much on this stuff?)

5.8  Scope of SA changes

   Most sections of this document discuss design considerations for
   updating and maintaining addresses for in the database entries that
   relate to an IKE-SA.  However, changing the preferred address also has an impact for
   affects the entries of the IPsec SAs. SA database.  The outer tunnel
   header addresses (source IP and destination IP addresses) need to be
   modified according to the primary path to allow the IPsec protected
   data traffic to travel along the same path as the MOBIKE packets (if
   we only consider the IP header information).  If the MOBIKE messages
   and the IPsec protected data traffic travel along a different path
   then NAT handling is severely complicated.

   The basic question is then how the IPsec SAs are changed to use the
   new address pair (the same address pair as the MOBIKE signaling
   traffic -- the primary path).  One option is that when the IKE SA
   address is changed then automatically all IPsec SAs associated with
   it are moved along with it to new address pair.  Another option is to
   have a separate exchange to move the IPsec SAs separately.

   If IPsec SAs should be updated separately then a more efficient
   format than the notification payload is needed. needed to preserve bandwidth.
   A notification payload can only store one SPI per payload.  A
   separate payload which would have list of IPsec SA SPIs and new
   preferred address.  If there are is a large number of IPsec SAs, those
   payloads can be quite large unless ranges of SPI values are
   supported.  If we automatically move all IPsec SAs when the IKE SA
   moves, then we only need to keep track which IKE SA was used to
   create the IPsec SA, and fetch the IP addresses.  Note that IKEv2
   [I-D.ietf-ipsec-ikev2] already requires implementations to keep track
   which IPsec SAs are created using which IKE SA.

   If we do allow each IPsec SAs SA address set to be updated separately,
   then we can support scenarios, where the machine has fast and/or
   cheap connections and slow and/or expensive connections, and it wants
   to allow moving some of the SAs to the slower and/or more expensive
   connection, and prevent the move, for example, of the news video
   stream from the WLAN to the GPRS link.

   On the other hand, even if we tie the IKE SA update to the IPsec SA
   update, then we can create separate IKE SAs for this scenario, e.g.,
   we create one IKE SA which have both links as endpoints, and it is
   used for important traffic, and then we create another IKE SA which
   have only the fast and/or cheap connection, which is then used for
   that kind of bulk traffic.

5.9  Zero Address Set

   One of the features which might be is potentially useful would be is for the peer to
   announce the other end that it will now disconnect for some time,
   i.e., i.e. it will not
   be reachable at all.  For instance, a laptop might go to suspend
   mode.  In this case the peer it could send address notification with zero
   new addresses, which means that it will not have any valid addresses
   anymore.  The responder of that kind of notification would then
   acknowledge that, and could then temporarily disable all SAs. SAs and
   therefore stop sending traffic.  If any of the SAs gets any packets
   they are simply dropped.  This could also include some kind of ACK
   spoofing to keep the TCP/IP sessions alive (or simply set the TCP/IP
   keepalives and timeouts large enough not to cause problems), or it
   could simply be left to the applications, e.g., e.g. allow TCP/IP sessions
   to notice the link is broken.

   The local policy could then decide how long the peer would allow
   other peers to be disconnected, e.g., whether this is only allowed
   for few minutes, or do they allow users to disconnect Friday evening
   and reconnect Monday morning (consuming resources during weekend too,
   but on the other hand not more than is normally used during week
   days, but we do not need lots of extra resources on then indicate how long the Monday
   morning to support all those people connecting back peer should allow
   remote peers to network). remain disconnected.

   From a technical point of view this feature addresses two aspects:

   o  There is no need to transmit IPsec data traffic.  IPsec protected
      data needs to be dropped which saves bandwidth.  This does not
      provide a functional benefit i.e, benefit, i.e., nothing breaks if this feature
      is not provided.

   o  MOBIKE signaling messages are also ignored and need to be
      suspended. ignored.  The IKE-SA must not
      be deleted and the suspend functionality (realized with the zero
      address set) might may require the IKE-SA to be tagged with a lifetime
      value since the IKE-SA
      will should not be kept in memory alive for an arbitrary amount
      undefined period of time.  Note that IKEv2 does not require that
      the IKE-SA has no a lifetime associated with it.  In order to prevent
      the IKE-SA to be from being deleted the dead-peer detection mechanism
      needs to be suspended as well.

   Due to the enhanced complexity of fact that this extension would be complicated, a first
   version of the MOBIKE protocol will not provide this feature.

5.10  IPsec Tunnel or Transport Mode

   Current MOBIKE design is focused only on the VPN type usage and
   tunnel mode.  Transport mode behaviour would also be useful, but will
   be discussed in future documents.

5.11  Message Representation

   The basic IP address change notifications can be sent either via an
   informational exchange already specified in the IKEv2, or via a
   MOBIKE specific message exchange.  Using informational exchange has
   the main advantage that it is already specified in the IKEv2 and
   implementations incorporated incorporate the functionality already.

   Another question is the basic format of the address update notifications.
   The address update notifications can include multiple addresses, of
   which some can may be IPv4 and some IPv6 addresses.  The number of
   addresses is most likely going to be quite small (less limited in typical environments
   (with less than
   10). 10 addresses).  The format might may need to indicate a
   preference value for each address.  Furthermore, one of the addresses in the peer address set
   must be labeled as the preferred address.  The format could either contain the a
   preference number, giving out number that determines the relative order of the
   addresses, or it could simply be ordered ordered, according to preference,
   list of IP addresses in the
   order of the most preferred first. addresses.  While two addresses can have the same
   preference value an ordered list avoids this problem. situation.

   Even if load balancing is currently outside the scope of MOBIKE,
   there might be
   future work to include this feature. might include.  The format selected format needs to be flexible
   enough to include additional information (e.g., (e.g. to enable load
   balancing).  This might may be
   something like one realized with an reserved field, which can
   later be used to store additional information.  As there is may arise
   other potential information which might may have to be tied to the an address in the
   future, a reserved field seems like a prudent design in any case.

   There are two basic formats for putting that place IP address list in to the
   exchange, we can include lists into a message.
   One includes each IP address as separate payload (where the payload
   order indicates the preference value, or the payload itself might
   include the preference value), or we can put the IP address list as
   one payload to the exchange, and that one payload will then have
   internal format which includes the list of IP addresses.

   Having multiple payloads with each one having carrying one IP address
   makes the protocol probably easier to parse, as we can already use
   the normal IKEv2 payload parsing procedures to get the list out. procedures..  It also offers an easy
   way for the extensions, as the payload probably contains only the
   type of the IP address (or the type is encoded to the payload type),
   and the IP address itself, and as each payload already has length
   associated to it, we can detect if there is any extra data after the
   IP address.  Some implementations might have problems parsing too long of a list of IKEv2 payloads,
   payloads that are longer than a certain threshold, but if the sender
   sends them in the most preferred first, the other end receiver can simply only take use the
   first addresses and use them. addresses.

   Having all IP addresses in one big MOBIKE specified internal format
   provides more compact encoding, and keeps the MOBIKE implementation
   more concentrated to one module.

   The next  It also avoids problems of packets
   arriving in an order different from what they were sent.

   Another choice is which type of payloads to use.  IKEv2 already
   specifies a notify payload.  It includes some extra fields (SPI size,
   SPI, protocol etc), which gives 4 bytes of the extra overhead, and
   there is the notify data field, which could include the MOBIKE
   specific data.

   Another option would be to have a custom payload type, which then
   includes the information needed for the MOBIKE protocol.

   MOBIKE might send the full peer address list once one of the IP
   addresses changes (either addresses are added, removed, the order
   changes or the preferred address is updated) or an incremental
   update.  Sending incremental updates provides more compact packets
   (meaning we can support more IP addresses), but on the other hand
   have more problems in the synchronization and packet reordering
   cases, i.e., the incremental updates must be processed in order, but
   for full updates we can simply use the most recent one, and ignore
   old ones, even if they arrive after the most recent one (IKEv2
   packets have message id which is incremented for each packet, thus we
   know the sending order easily).

   Note that each peer needs to communicate its peer address set to the
   other peer.

6.  Security Considerations

   As all the messages are already authenticated by the IKEv2 there is
   no problem that any attackers would modify the actual contents of the
   packets.  The IP addresses in the IP header of the packets are not
   authenticated, thus the protocol defined must take care that they are
   only used as an indication that something might be different, they
   should and
   that do not cause any direct actions.

   Attacker

   An attacker can also spoof ICMP error messages in an effort to
   confuse the peers about which addresses are not working.  At worst
   this causes denial of service and/or the use of non-preferred addresses,
   so it is not that serious.
   addresses.

   One type of attack that needs to be taken care of in the MOBIKE
   protocol is also various flooding attacks. the "flooding attack" type.  See [I-D.ietf-mip6-ro-sec]
   and [Aur02] for more information about flooding attacks.

   [EDITOR's NOTE: This section needs more work.]

7.  IANA Considerations

   This document does not introduce any IANA considerations.

8.  Acknowledgments

   This document is the result of discussions in the MOBIKE working
   group.  The authors would like to thank Jari Arkko, Pasi Eronen,
   Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld,
   James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch,
   Udo Schilcher, Tom Henderson Henderson, Andreas Pashalidis and Maureen Stillman
   for their input.

   We would like to particularly thank Pasi Eronen for tracking open
   issues on the MOBIKE mailing list.  He helped us to make good
   progress on the document.

9.  Open Issues

   This document is not yet complete, the following open issues need to
   be addressed in a future version:

   o  Section 4 needs an example to better illustrate the functionality
      of MOBIKE

   o  Section 6 requires a more detailed discussion about the potential
      security vulnerabilities and their solution. corresponding countermeasures.

   o  Some text is need needed to address the implications of unidirectional
      connectivity aspect for MOBIKE (see also issue #19).

   o  A discussion about the scalability aspects of connectivity tests
      would be benefical.

   o  More details are necessary to describe the implications of NAT
      traversal for MOBIKE.

   A complete list of issues is available at TBD.
   http://www.vpnc.org/ietf-mobike/issues.html.

10.  References

10.1  Normative references

   [I-D.ietf-ipsec-ikev2]
              Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              Internet-Draft draft-ietf-ipsec-ikev2-17,
              draft-ietf-ipsec-ikev2-17 (work in progress),
              October 2004.

   [I-D.ietf-ipsec-rfc2401bis]
              Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol",
              Internet-Draft draft-ietf-ipsec-rfc2401bis-05, December
              2004. draft-ietf-ipsec-rfc2401bis-06 (work
              in progress), April 2005.

10.2  Informative References

   [I-D.arkko-multi6dt-failure-detection]
              Arkko, J., "Failure Detection and Locator Selection in
              Multi6",
              Internet-Draft draft-arkko-multi6dt-failure-detection-00, draft-arkko-multi6dt-failure-detection-00 (work
              in progress), October 2004.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [I-D.dupont-mipv6-3bombing]
              Dupont, F., "A note about 3rd party bombing in Mobile
              IPv6", Internet-Draft draft-dupont-mipv6-3bombing-01,
              January draft-dupont-mipv6-3bombing-02 (work in progress),
              June 2005.

   [I-D.ietf-mip6-ro-sec]
              Nikander, P., "Mobile IP version 6 Route Optimization
              Security Design Background",
              Internet-Draft draft-ietf-mip6-ro-sec-02, October 2004. draft-ietf-mip6-ro-sec-03
              (work in progress), May 2005.

   [I-D.ietf-hip-mm]
              Nikander, P., "End-Host Mobility and Multi-Homing with
              Host Identity Protocol",
              Internet-Draft draft-ietf-hip-mm-00, October 2004. draft-ietf-hip-mm-01 (work in
              progress), February 2005.

   [I-D.crocker-celp]
              Crocker, D., "Framework for Common Endpoint Locator
              Pools", Internet-Draft draft-crocker-celp-00, draft-crocker-celp-00 (work in progress),
              February 2004.

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C. C., and R. Mahy,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L. L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

   [I-D.ietf-tsvwg-addip-sctp]
              Stewart, R., "Stream Control Transmission Protocol (SCTP)
              Dynamic Address  Reconfiguration",
              Internet-Draft draft-ietf-tsvwg-addip-sctp-10, January
              draft-ietf-tsvwg-addip-sctp-12 (work in progress),
              June 2005.

   [I-D.dupont-ikev2-addrmgmt]
              Dupont, F., "Address Management for IKE version 2",
              Internet-Draft draft-dupont-ikev2-addrmgmt-06, October
              2004.
              draft-dupont-ikev2-addrmgmt-07 (work in progress),
              May 2005.

   [RFC3554]  Bellovin, S., Ioannidis, J., Keromytis, A. A., and R.
              Stewart, "On the Use of Stream Control Transmission
              Protocol (SCTP) with IPsec", RFC 3554, July 2003.

   [I-D.ietf-ipv6-optimistic-dad]
              Moore, N., "Optimistic Duplicate Address Detection for
              IPv6", Internet-Draft draft-ietf-ipv6-optimistic-dad-05, draft-ietf-ipv6-optimistic-dad-05 (work in
              progress), February 2005.

   [I-D.ietf-ipv6-unique-local-addr]
              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses",
              Internet-Draft draft-ietf-ipv6-unique-local-addr-09, draft-ietf-ipv6-unique-local-addr-09 (work in
              progress), January 2005.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2367]  McDonald, D., Metz, C. C., and B. Phan, "PF_KEY Key
              Management API, Version 2", RFC 2367, July 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC2461]  Narten, T., Nordmark, E. E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [Aur02]    Aura, T., Roe, M. M., and J. Arkko, "Security of Internet
              Location Management", In Proc. 18th Annual Computer
              Security Applications Conference, pages 78-87, Las Vegas,
              NV USA, December 2002.

Authors' Addresses

   Tero Kivinen
   Safenet, Inc.
   Fredrikinkatu 47
   HELSINKI  FIN-00100
   FI

   Email: kivinen@safenet-inc.com

   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.