IKEv2 Mobility and Multihoming                                T. Kivinen
(mobike)                                                   Safenet, Inc.
Internet-Draft                                             H. Tschofenig
Expires: July 1, 2005                                            Siemens
                                                       December 23, 31, 2004

                     Design of the MOBIKE protocol
                    draft-ietf-mobike-design-00.txt Protocol
                    draft-ietf-mobike-design-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with subject to all provisions
   of Section 10 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 RFC2026.
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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.
   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 December 23, 2004. July 1, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   The MOBIKE (IKEv2 Mobility and Multihoming) working group is
   developing protocol extensions to the Internet Key Exchange Protocol
   version 2 (IKEv2) to enable its use in the context where there are
   multiple IP addresses per host or where IP addresses of an IPsec host
   change over time (for example due to mobility).

   This document discusses the potential design involved network entities, and the
   relationship between IKEv2 signaling and information provided by
   other protocols and the rest of the network.  Design decisions in for
   the base MOBIKE (IKEv2 Mobility and Multihoming) protocol. It also tries to
   provide some protocol, background information about different choices and tries
   to record the decisions made by discussions
   within the working group, so that we do not
   need to repeat discussion later. group are recorded.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Roaming Laptop Scenario
   2.  Terminology  . . . . . . . . . . . . . . . . .  3
     1.2   Multihoming SGW Scenario . . . . . . . .  4
   3.  Scenarios  . . . . . . . . .  4
   2.  Issues . . . . . . . . . . . . . . . . .  6
     3.1   Mobility Scenario  . . . . . . . . . . .  5
   3.  Adopting a new address / multihoming support . . . . . . . . .  6
     3.1   IP-address list or one IP-address  . .
     3.2   Multihoming Scenario . . . . . . . . . .  6
     3.2   Indirect or direct indication (issue #1) . . . . . . . . .  7
     3.3   Dead peer detection and IKEv2 (issue #11)  . .   Multihomed Laptop Scenario . . . . . .  7
   4.  Simultaneous Movements (issue #2) . . . . . . . . . .  8
   4.  Framework  . . . .  9
   5.  Interaction with NAT-T (issue #3) . . . . . . . . . . . . . . 10
   6.  Changing addresses or changing the paths (issue #10, #14) . . 11
   7.  How and When to do Return Routability Checks (issue #6,
       #12, #15) . . . . . .  9
   5.  Design Considerations  . . . . . . . . . . . . . . . . . . . . 12
   8.  Scope of SA changes (issue #8) . .
     5.1   Indicating Support for MOBIKE  . . . . . . . . . . . . . . 14
   9.  Zero 12
     5.2   Changing a Preferred Address Set (issue #5)  . . . and Multihoming Support . . . 12
       5.2.1   Storing a single or multiple addresses . . . . . . . . 13
       5.2.2   Indirect or Direct Indication  . . . 15
   10.   What modes we support (issue #7) . . . . . . . . . 14
       5.2.3   Connectivity Tests using IKEv2 Dead-Peer Detection . . 15
     5.3   Simultaneous Movements . . . 16
   11.   Message representation . . . . . . . . . . . . . . . 16
     5.4   NAT Traversal  . . . . 17
   12.   Security Considerations . . . . . . . . . . . . . . . . . . 17
     5.5   Changing addresses or changing the paths . . . . . . . . . 18
     5.6   Return Routability Tests . . . . . . . . . . . . . . . . . 19
   13.
     5.7   Employing MOBIKE results in other protocols  . . . . . . . 21
     5.8   Scope of SA changes  . . . . . . . . . . . . . . . . . . . 22
     5.9   Zero Address Set . . . . . . . . . . . . . . . . . . . . . 23
     5.10  IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 24
     5.11  Message Representation . . . . . . . . . . . . . . . . . . 24
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 20
   14. . 27
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . 21
   14.1 . 29
   9.1   Normative references . . . . . . . . . . . . . . . . . . . . 21
   14.2  Non-normative references 29
   9.2   Informative References . . . . . . . . . . . . . . . . . . 21
       Author's Address . 29
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 30
       Intellectual Property and Copyright Statements . . . . . . . . 22 32

1.  Introduction

   IKEv2 is used for performing mutual authentication and establishing
   and maintaining IPsec security associations (SAs).  IKEv2 establishes
   both cryptographic state (such as session keys and algorithms) as
   well as non-cryptographic information (such as IP addresses).

   The current IKEv2 and IPsec documents explicitly say that the IPsec
   and IKE SAs are created implicitly between the IP-addresses IP address pair used in
   during the protocol execution when establishing the IKEv2 SA.  This
   means that there is only one IP-address IP address pair attached stored for the IKEv2 SA,
   and the only one IP-address this single IP address pair is used as a gateway an outer endpoint address
   for tunnel mode IPsec SAs. Also after  After the IKE SA is created there is no
   way to change those addresses. them.

   There are scenarios which require that the where this IP address might change
   rapidly. change, even
   frequently.  In some cases the problem could be solved by rekeying
   all the IPsec and IKE SAs after the IP-address IP address has changed. In some
   scenarios  However,
   this might 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 user interaction (SecurID cards etc).
   Due to these reasons, a mechanism to update the
   IP-addresses IP addresses tied to
   the IPsec and IKEv2 SAs is needed.

   The charter of  MOBIKE provides solution to the
   problem of the updating the IP addresses stored with IKE SAs and
   IPsec SAs.

   The charter of the MOBIKE working group requires IKEv2, IKEv2
   [I-D.ietf-ipsec-ikev2], and as IKEv2 assumes that the RFC2401bis
   architecture [I-D.ietf-ipsec-rfc2401bis] is used, all protocols
   developed will use both IKEv2 and RFC2401bis (issue #9). RFC2401bis.  No effort is to be
   made to make protocols for IKEv1 [RFC2409] or old RFC2401 architecture.

   MOBIKE protocol provides solution
   architecture [RFC2401].

   This document is structured as follows.  After introducing some
   important terms in Section 2 we list a few scenarios in Section 3, to the problem of the updating the
   IP-addresses. The
   illustrate possible deployment environments.  MOBIKE protocol should take care following:
   o  Notifying the depends on
   information from other end of IP-address(es) change
   o  Update sources (e.g., detect an address change) which
   are discussed in Section 4.  Finally, Section 5 discusses design
   considerations effecting the IKE SA endpoint MOBIKE protocol.  The document concludes
   with security considerations in Section 6.

2.  Terminology

   This section introduces some terms in useful for a MOBIKE protocol.

   Peer:

      Within this document we refer to IKEv2 endpoints as peers.  A peer
      implements MOBIKE and therefore IKEv2.

   Available address:

      This definition is reused from
      [I-D.arkko-multi6dt-failure-detection] and refers to addresses based on the notifications
   o  Switching
      which are available by an peer.  A few conditions must hold before
      an address in such a state.

   Locally Operational Address:

      An available address is said to be locally operational when its
      use new IP-address if old one does not work anymore
   o  Updating the tunnel mode IPsec SA tunnel endpoint addresses
   o  Ensuring that the given new is known to be possible locally.  This definition is taken
      from [I-D.arkko-multi6dt-failure-detection].

   Operational address pair:

      A pair of operational addresses belong are said to the peer

   The MOBIKE protocol be an operational
      address pair, iff bidirectional connectivity can be used in different scenarios. Two such
   scenarios are discussed below.

1.1  Roaming Laptop Scenario

   In the roaming laptop scenario shown between
      the device two addresses.  Note that moves around sometimes it is
   laptop, which might have several ways necessary to connect
      consider a 5-tuple when connectivity between two endpoints need to internet. It
      be tested.  This differentiation might for example have fixed ethernet, WLAN and GPRS access be necessary to net, address
      load balancers, certain Network Address Translation types or
      specific firewalls.  This definition is taken from
      [I-D.arkko-multi6dt-failure-detection] and some of those can be used in different times. It tries enhanced to use fit the
   most efficient connection
      MOBIKE context.  Although it is possible to further differentiate
      unidirectional and bidirectional operational address pairs only
      bidirectional connectivity is relevant for this document and
      unidirectional connectivity is out of scope.

   Path:

      The route taken by the MOBIKE and/or IPsec packets sent via the IP
      address of one peer to a specific destination address of the other
      peer.  Note that the path might be effected not only by the source
      and destination IP addresses but also by the selected transport
      protocol and transport protocol identifier.  Since MOBIKE and
      IPsec packets have a different appearance on the wire they might
      be routed along a different path.  This definition is taken from
      [RFC2960] and modified to fit the MOBIKE context.

   Primary Path:

      The primary path is the destination and source address that will
      be put into a packet outbound to the peer by default.  This
      definition is taken from [RFC2960] and modified to fit the MOBIKE
      context.

   Preferred Address:

      An address on which a peer prefers to receive MOBIKE messages and
      IPsec protected data traffic.  A given peer has only one active
      preferred address at a given point in time (ignoring the small
      time period where it needs to switch from the old preferred
      address to a new preferred address).  This definition is taken
      from [I-D.ietf-hip-mm] and modified to fit the MOBIKE context.

   Peer Address Set:

      A subset of locally operational addresses that will sent
      communicated to another peer.  A policy available at the peer
      indicates which addresses to include in the peer address set.
      Such a policy might be impacted by manual configuration or by
      interaction with other protocols which indicate newly available
      addresses.  Note that the addresses in the peer address set might
      change over time.

   Preferred Address Pair:

      This address pair taken from the peer address set is used for
      communication.  The preferred address pair is used (1) for MOBIKE
      communication where only two IP addresses are used and (2) as the
      outer IP addresses (source and destination IP address) of the
      IPsec packet in tunnel mode.

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

3.  Scenarios

   The MOBIKE protocol can be used in different scenarios.  Three of
   them are discussed below.

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
   to some security gateway.  This security gateway might connect the
   mobile node to a corporate network, to a UTMS network or to some
   other network.  The initial IKEv2 exchange takes place along the path
   labeled as 'old path' from the MN using its old IP address via the
   old access router (OAR) towards the security gateway (GW).  The IPsec
   tunnel mode terminates there but the decapsulated data packet will
   typically address another destination.  Since only MOBIKE is relevant
   for this discussion the end-to-end communication between the MN and
   some destination server is not shown in Figure 1.

   When the MN moves to a new network and obtains a new IP address from
   a new access router (NAR) it is the responsibility of MOBIKE to avoid
   restarting the IKEv2 exchange from scratch.  As a result, some form
   of protocol exchange, denoted as 'MOBIKE Address Update', will
   perform the necessary state update.  The protocol messages will
   travel along a new path whereby the old path and the new path will
   meet at the cross-over router.

   Note that in a break-before-make mobility scenario the MN obtains a
   new IP address after reachability to 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 the new IP address while
   still being reachable at the old IP address.

                          (Initial IKEv2 Exchange)
                    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
       Old IP   +--+        +---+                    v
       address  |MN|------> |OAR| -------------V     v
                +--+        +---+ Old path     V     v
                 .                          +----+   v>>>>> +--+
                 .move                      | CR | -------> |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 is between two peers
   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 IP_A1 and IP_A2.  Additionally, 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
   used for communication.  Various reasons, such as problems with the
   interface card, might require a peer to switch from one IP address to
   the other one.

     +------------+                                  +------------+
     | 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 chance their preferred
                      address)

                     Figure 2: Multihoming Scenario

   Note, that the load-balancing inside one IKE SA is not provided by
   the MOBIKE protocol.  Each client uses only one of the available IP
   addresses at a given point in time.

3.3  Multihomed Laptop Scenario

   In the multihomed laptop scenario we consider a laptop, which has all the time, but that connection
   multiple interface cards and therefore several ways to connect to a
   network.  It might change. For for example have a fixed Ethernet, WLAN, GPRS,
   Bluetooth or USB hardware in order to sent IP packets.  Some of these
   interfaces might connected to a network over the time depending on a
   number of reasons (e.g., cost, availability of certain link layer
   technologies, user convenience).  For example, the user can
   disconnect himself from the fixed
   ethernet, Ethernet, and then use the office
   WLAN, and then later leave the office and start using GPRS during the trip to home. In home he might
   again use again WLAN (but with different IP-addresses) etc.

   The device
   trip to home.  At home he might again use again WLAN.  At a certain
   point in time multiple interfaces might be connected.  As such, the
   laptop is a multihomed device.  In any case, the IP address of the
   individual interfaces are subject to change.

   The user desires to keep the established IKE-SA and IPsec SAs alive
   all time without the need to re-run the initial IKEv2 exchange which
   could require user interaction as part of the authentication process.
   Furthermore, 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 the IPsec tunnel
   remains unaffected, i.e., applications might not detect any change at
   all.

4.  Framework

   Initially, when a MOBIKE peer starts and executes the initial
   protocol exchange with its MOBIKE peer it needs to setup a peer
   address set based on the available addresses.  It might want to make
   this peer address set available to the other peer.  The Initiator
   does not need to explicitly indicate its preferred address since
   already using its preferred address.  The outgoing IKEv2 and MOBIKE
   messages use this preferred address as the source IP address and
   expects incoming signaling messages to be addressed to this address.

   Interaction with other protocols at the MOBIKE host is required to
   build the peer address set and the preferred address.  In some cases
   the peer address set is available before the initial protocol run and
   does not use Mobile IP or anything similar, it simply
   wants to keep change during the VPN connection lifetime of the IKE-SA.  The preferred
   address might change due to policy reasons.  In many other cases, as
   motivated in Section 3 the corporate security gateway
   (SGW) up peer address set is modified (by adding or
   deleting addresses) and running all the time. Even if preferred address needs to be changed as
   well.

   Modifying the interface peer address set or changing the
   IP-addresses change, the internal addresses used inside the IPsec
   tunnel remains same (allocated from the SGW), i.e. preferred address is
   effected by the applications
   might not detect host's local policy and by the changes interaction with other
   protocols (such as DHCP or IPv6 Neighbor Discovery).

   Figure 3 shows an example protocol interaction at all.

1.2  Multihoming SGW Scenario

   Another possible scenario which might use a MOBIKE is peer.
   MOBIKE interacts with the SGW of IPsec engine using the
   other end of PF_KEY interface to
   create entries in the roaming laptop scenario. Security Association and Security Policy
   Databases.  The SGW IPsec engine might have multiple
   interfaces to different ISPs, also interact with IKEv2 and wants to provide connection even
   when some of those connections are broken. One of
   MOBIKE.  Established state at the interface might
   also be IPsec databases has an impact on
   the WLAN access point incoming and outgoing data traffic.  MOBIKE receives information
   from other protocols running in both kernel-mode and user-mode, as
   previously mentioned.  Information relevant for MOBIKE is stored in a
   database, referred as Trigger database which guides MOBIKE in its
   decisions regarding the office. The SGW will know
   beforehand what available addresses, peer address set of IP-addresses it will use, but it might need to
   dynamically send update notifications and the clients to tell them which
   addresses to use. It might also use this to do some sort of load
   balancing, i.e. giving different clients different
   preferred address,
   to utilize all address.  Policies might affect the connections. selection process.

   Building and maintaining a peer address set and selecting or changing
   a preferred address based on locally available information is,
   however, insufficient.  This kind of load balancing is
   completely internal information needs to be available to the SGW (i.e. the clients will simply see that
   the preferred IP-address
   other peer and in order to address various failure cases it is
   necessary to test connectivity along a path.  A number of address
   pairs might be used available for tunnel endpoint changes, connectivity tests but
   they do not know why or how most important is
   the SGW decided to do that), source and the
   actual algorithms how to do that is outside the scope destination IP address of MOBIKE
   protocol (i.e. the whole issues is that preferred address
   pair since these addresses are selected for sending and receiving
   MOBIKE does not disallow the
   SGW signaling messages and for sending and receiving IPsec
   protected data traffic.  If a problem along this primary path is
   detected (e.g., due to give different sets of IP-addresses in different preference
   order a router failure) it is necessary to switch to different clients).

   Note, that the load-balancing inside
   the one IKE SA (i.e. one client) new preferred address pair.  Testing other paths might also be
   useful to notice when a disconnected path is not handled in operational again.

                           +-------------+       +---------+
                           |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

   Although the interaction with other protocols is important for MOBIKE protocol. Each client uses only one of
   to operate correctly the IP-addresses given by working group is chartered to leave this
   aspect outside the SGW at one time.

2.  Issues scope.  The base working group will develop a MOBIKE
   protocol which needs to perform the following things: functionality:
   o  Ability to inform the a peer about the current or changed
      address(es) of the sender peer address set
   o  Ability to inform the a peer about the preferred address
   o  Ability to test connectivity along a path and thereby to detect an
      outage situation and in order to fall back to another preferred
      address, if necessary, or to change the peer address set
   o  Ability to deal with Network Address Translation devices

   In addition to the above-listed functionality security is important
   to the use of
      another address
   o  Ability working group.  For example, the ability to prevent flooding
   attacks based on announcing someone else's address
   o  Ability needs to affect be dealt
   with.

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

   Note that MOBIKE is somewhat different compared to, for example, SCTP
   mobility since both the IKE IKE-SA and the IPsec SAs

   One of SA is affected by the key issues
   change of addresses.

5.  Design Considerations

   This section discusses aspects affecting the design of the MOBIKE protocol is, whether
   protocol.

5.1  Indicating Support for MOBIKE protocol

   A node needs to recover from be able to guarantee that its address change messages
   are understood by its corresponding peer.  Otherwise an address
   change may render the case where packets simply
   dont get through. If connection useless, and it is important that
   both sides realize this as early as possible.

   Ensuring that the node messages are understood can locally detect in be arranged either
   by marking some problems with
   the interfaces (IP-address change, interface disappearing, link going
   down), it can act based on IKEv2 payloads critical so that and fix they are either
   processed or an error message is returned, by using Vendor ID
   payloads or via a Notify.

   The first solution approach is to use Vendor ID payloads during the situation. If
   initial IKEv2 exchange using a specific string denoting MOBIKE to
   signal the packets
   are simply disappearing somewhere in support of the net, MOBIKE protocol.  This ensures that in all
   cases a MOBIKE capable node knows whether its peer supports MOBIKE or
   not.

   The second solution approach uses the Notify payload which is also
   used for NAT detection of (via NAT_DETECTION_SOURCE_IP and
   NAT_DETECTION_DESTINATION_IP).

   Both, a Vendor ID and a Notify payload, might be used to indicate the
   problem requires noticing
   support of certain extensions.

   Note that we cannot get packets through. If the
   protocol only need node could also attempt MOBIKE optimistically with the
   critical bit set to fix problems appearing one when a movement has occurred.  The drawback
   of this approach is, however, that the an unnecessary MOBIKE message
   round is introduced on the first movement.

   Although Vendor ID payloads and Notifications are technically
   equivalent Notifications are already used in the local interfaces,
   then the protocol IKEv2 as a capability
   negotiation mechanism and is much simpler.

3.  Adopting therefore the preferred mechanism.

5.2  Changing a new address / multihoming support Preferred Address and Multihoming Support

   From the MOBIKE's point of view the multihoming support is the integrated by
   supporting a peer address set of
   rules how rather than a single address and when
   protocol mechanisms to change to use a new IP-address for preferred IP address.
   From a protocol point of view each peer needs to learn the other end.

3.1  IP-address list preferred
   address and the peer address set somehow, implicitly or one IP-address explicitly.

5.2.1  Storing a single or multiple addresses

   One design decision is whether an IKE-SA should store a single IP
   address or multiple IP addresses as part of the peer address set.
   One option is that the other end can provide a list of addresses
   which can be used as destination addresses, and the local end needs
   to decide which of them to use. The addresses.  MOBIKE does not include
   load-balancing, i.e. the local end
   load balancing, i.e., only uses one IP-address IP address is set to a preferred
   address at time, a time and it only changes to use new IP-address after changing the preferred address typically
   requires some kind of
   indication. MOBIKE signaling.

   Another option is to only communicate one address for each end, towards the other
   peer and both ends peers only use that address when communicating. When the
   something changes, the end whose situation changes, sends  If
   this preferred address cannot be used anymore then an address update
   notification
   is sent to the other end, peer changing that one the primary address.

   If the other end peer A provides the full list of possible IP-addresses, a peer address set with multiple IP addresses then the other end
   peer B can recover from a failure of the movements preferred address on its
   own, meaning that when it detects that the primary path does not work
   anymore it cannot get packets through it can try another
   IP-address. If the other end either switch to a new preferred address locally
   (i.e., causing the source IP address of outgoing MOBIKE messages to
   have a non-preferred address) or to try an IP address from A's peer
   address set.  If peer B only received a single IP address as the A's
   peer address set then peer B can only provides one IP-address to be used,
   then the change its own preferred
   address.  The other end has to wait for the an address update from peer A
   with a new IP-address before IP address in order to fix the
   situation is fixed. problem.  The good thing main
   advantage about only one IP-address using a single IP address for the remote host is that
   it makes retransmission easy, and it also makes
   it clear which end should do the recovery (i.e. simplifies the end, recover
   procedure.  The peer, whose
   IP-address IP address changed, MUST must start recovery
   process and send the new
   IP-address IP address to the other end). peer.  Failures
   along the path are not well covered with advertising a single IP
   address.

   The one IP-address single IP address approach will not work if both ends peers happen to
   loose their IP-address IP address at the same time (routing problems, which
   causes (due to, say, the failure of
   one link between the hosts to go down, thus either end
   cannot get recovery packets through as of the link is down). links that both nodes are connected to).  It also may
   cause the requirement for also
   require the IKEv2 window size to be larger than 1, especially if only
   direct indications are used.  This is because the host needs to be
   able to send the IP-address IP address change notifications before it can switch
   to another address, and depending on the return routability checks,
   retransmissions policies etc, it might be hard to make the protocol
   such that it works with window size of 1 too (issue
   #11). Also one IP-address too.  Furthermore, the
   single IP address approach does not really benefit much from
   the indirect
   indications as the end getting those indirect peer receiving these indications cannot often might not be able
   to fix the situation by itself (i.e. (e.g., even if
   the host gets a peer receives an ICMP
   host unreachable message for the old IP-address, IP address, it cannot try other IP-addresses, as it does not know them).
   IP addresses, since they are unknown).

   The problems with IP-address IP address list are mostly in its complexity.

   Notification and recovery processes are more complex, as both end can
   recover from the IP-address IP address changes.  There is also possibilities
   that both ends tries to recover at the same time and this must be taken
   care in
   taken care in the protocol.

   Please note that the discussed aspect is partially different from the
   question how many addresses to sent 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 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).  Furthermore, a MOBIKE message carrying the peer address
   set could be idempotent (i.e., always resending the full address
   list) or does the protocol allow add/delete operations to be
   specified.  [I-D.dupont-ikev2-addrmgmt], for example, offers an
   approach which defines add/delete operations.  The same is true for
   the protocol.

3.2 dynamic address reconfiguration extension for SCTP
   [I-D.ietf-tsvwg-addip-sctp].

5.2.2  Indirect or direct indication (issue #1)

   The Direct Indication

   An indication that the situation regarding to change the IP-address has
   changed preferred IP address might be either
   direct or indirect. The

   Direct indication:

      A direct indication means that the other end peer will send specific indication that now
   something changed. The indirect indication is something which can be
   observed from infrastructure or lack of packets, not directly from an message
      with the other end.

   The direct indication can be address change.  Such a message can, for example the other end IKEv2 example,
      accomplished by having MOBIKE sending an authenticated address
      update notification, which have notification with a different
   IP-address(es) than used earlier.

   The preferred address.

   Indirect indication:

      An indirect indication to change the preferred address can be many things. One example might be that
   the local end notices that suddenly
      obtained by observing the other ends start using
   different source address environment.  An indirect indication
      might, for example, be be the packets than what it used before, or receipt of an ICMP message or routing
      information change.

   Another type of indirect information might that there has been no
   traffic from the other end for some time (i.e. the current connection
   might be broken). a link failure.  This kind of indirect information should be seen as
      a hint and might not directly cause any changes to the IP-addresses, but they should be used as indication
   that there preferred
      address.  Depending on the local policy MOBIKE might be need decide to do dead-peer-detection
      perform a dead-peer detection exchange for the currently
   used address. I.e. when preferred address
      pair (or another address pair from the local end peer address set).  When a
      peer detects that the other end started to use different source IP-address IP
      address than which was used before, it should initiate dead-peer-detection for might want to authorize the new preferred
      address (if not already authorized).  A peer might also start a
      connectivity test of this particular address.If a bidirectionally
      operational address pair is selected then MOBIKE needs to
      communicate this new preferred address to its remote peer.

   MOBIKE will utilize both mechanisms, direct and indirect indications,
   to make a more intelligent decision which address
   currently in use. If that dead-peer-detection tells that the
   connection is alive, then there is no need pair to do anything. If local
   end does not receive any reply select as
   the preferred address.  The more information will be available to
   MOBIKE the dead-peer-detection, then it
   should do dead-peer-detection for faster a new operational preferred address pair can be
   selected among the other addresses in available candiates.

5.2.3  Connectivity Tests using IKEv2 Dead-Peer Detection

   This section discusses the list (if
   available, in suitability of the preferred order). If it can find an IKEv2 dead-peer
   detection (DPD) mechanism for connectivity tests between address which
   works,
   pairs.  The basic IKEv2 DPD mechanism is not modified by MOBIKE but
   it will switch needs to that.

3.3  Dead peer detection and IKEv2 (issue #11) be investigated whether it can be used for MOBIKE
   purposes as well.

   The IKEv2 dead-peer-detection DPD mechanism is done by sending an empty informational
   exchange packet to the other end, peer, in which case the other end will
   acknowledge that.
   respond with an acknowledgement.  If no acknowledge acknowledgement is received
   after certain timeout (and after couple of retransmissions), the local end should try
   other
   IP-addresses (if available). The packets peer is considered to be not reachable.  Note that the receipt
   of IPsec protected data traffic is also a guarantee that the other
   peer is alive.

   When reusing dead-peer detection in MOBIKE for connectivity tests it
   seems to be reasonable to try other IP-addresses IP addresses (if they are
   available) in case of 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 dead-peer
   detection message (i.e.  they are simply retransmissions of the dead-peer-detection
   dead-peer detection packet using different destination IP-address). IP address).
   If different message-id is used that then it violates constraints placed
   by the IKEv2 constraints specification on the DPD message with regard to the
   mandatory ACK for each message-id, causing the IKEv2 SA to be teared down.
   deleted.

   If MOBIKE strictly follows the local end does not receive acknowledge message back from any guidelines of the IP-addresses, it dead-peer detection
   mechanism in IKEv2 then an IKE-SA should mark be marked as dead and
   deleted if the IKE SA dead, connectivity test for all 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 it
   (as mandated by
   state.  Connectivity tests will be continued for the IKEv2 specification). address pairs in
   hope that the problem will recover soon.

   Note, that as IKEv2 implementations might have window size of 1, it
   means that
   which prevents to initiate a dead-peer detection exchange while we are doing some other exchange, we cannot initiate
   dead-peer-detection. This means that
   another exchange.  As a result all other exchanges should also
   receive experience the
   identical retransmission policy than what is as used for the
   dead-peer-detection (issue #11). dead-peer detection.

   The dead-peer-detection dead-peer detection for the other IP-addresses IP address pairs can also be done
   simultaneously,
   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 IP-addresses. The problem here address pairs.  It is that we need
   necessary to distinguish
   from the acknowledge packets differentiate individual acknowledgement messages in
   order to determine which IP-address actually works now
   (i.e. we will check address pair is operational.  Therefore the acknowledge packets
   source IP-address, as it IP address of the acknowledgement should match the destination
   IP we sent out). towards the message was previously sent.

   Also the other end peer is most likely going to reply only to the first
   packet it receives, and that first packet might not be the most
   preferred IP-address. best (by
   whatever criteria) address pair.  The reason the other end peer is only
   responding to the first packet it receives, is that implementations
   should not send retransmissions if they have just sent out identical retransmissions.
   response message.  This is to protect the packet multiplication
   problem, which can happen if some node in the network queues up
   packets and then send them to the destination.  If destination will
   reply to all of them then the other end will again see multiple
   packets, and will reply to all of them etc.

   The protocol should also be nice to the network, meaning, that when
   some core router link goes down, and all those a large number of MOBIKE clients
   notice
   that, it, they should not start sending lots a large number of messages
   while trying to recover from the problem.  This might be especially
   bad if this happens because packets are dropped because of the
   congested network.  If MOBIKE clients will try simultaneously try to test all IP-addresses
   sending lots of packets to the net, because they lost one packet
   because of
   possible address pairs by executing connectivity tests then the congestion, it simply make
   congestion problem only gets worse.

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

4.

5.3  Simultaneous Movements (issue #2)

   We do

   MOBIKE does not need aim to solve the simultaneous movement recovery problem,
   as we are not creating provide a full mobility solution (charter forbids that),
   but are instead concentrating on which allows
   simultaneous movements.  Instead, the VPN style scenarios. In MOBIKE working group focuses on
   selected scenarios as described in Section 3.  Some of the scenarios we
   assume that the one end (SGW) will have peer has a fixed set of addresses (from which some
   subset might be in use), thus use).  Thus it cannot move to the address not known by unknown
   to the other end. This means that the
   solutions how to recover from cases peer.  Situations where both ends peers move and the movement
   notifications do not cannot reach the other ends, peer, is outside the scope of
   the MOBIKE WG.  MOBIKE has not being chartered to deal with the
   rendezvous problem, or with the introduction of any new entities in
   the network.

   Note, that if we use only one a single address per each end, instead is stored in the peer address set
   (instead of an address list, list) we might end up in the case where it
   seems that both
   ends peers changed their addresses at the same time.  This
   is something that the protocol must take care of.

   There is three different deal with.

   Three cases here: can be differentiated:

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

   o  Simultaneous changes to addresses such that at least one of the
      new addresses was is known by both peers to the other peer before the change
      occurred.
      The primary problem in first case

   o  No simultaneous changes at all.

5.4  NAT Traversal

   IKEv2 has support of legacy NAT traversal built-in.  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 the source and
   possibly the destination IP address.  With NAPT even the transport
   protocol identifiers are modified (which then requires UDP
   encapsulation for subsequent IPsec protected data traffic).
   Therefore, the required IP address information is taken from the IP
   header (if a NAT was not knowing detected who rewrote IP header information)
   rather than from the protected payload.  This problem is not new and
   was discovered during the design of mobility protocol where the only
   valuable information is IP address information.

   One of the goals in the MOBIKE protocol is to securely exchange one
   or more addresses beforehand. Here we know of the peer address so there set and to securely set the
   primary address.  If not other protocol is no
      problem. Example 1: two SGWs failover used to another path. Example 2:
      roaming laptop gets a new securely retrieve
   the IP address at and port information allocated by the same time NAT then it is
   not possible to tackle all attacks against MOBIKE.  Various solution
   approaches 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 its SGW's
      primary interface goes down.
      No simultaneous changes at all.

5.  Interaction MIDCOM and NSIS, already deal with NAT-T (issue #3)

   In some this problem.
      The MOBIKE protocol can benefit from the interaction with these
      protocols.

   o  Design a protocol in such a way the MOBIKE and NAT-T that NAT boxes are not compatible. The NAT-T tries able to work regardless of the IP-addresses, i.e. regardless whether
   someone modifies its IP-address or not. One of the goals inspect
      (or even participate) in the
   MOBIKE is to AUTHENTICATE the change of the IP-address, i.e. when the
   IP-address changes we want to verify that this change protocol exchange.  This approach was
      taken with HIP but is actually
   legitimate change done by the other end, not something done an option for IKEv2 and MOBIKE.

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

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

   If MOBIKE

   A design question is whether NAT detection capabilities should be
   enabled for only during the IKE SA (i.e. initial exchange or even at subsequent
   message exchanges.  If MOBIKE is executed with no NAT along the path
   when the IKE SA was created), then if NAT is later added then MOBIKE can
   detect that, but it cannot securely do anything for the issue. We can
   disable MOBIKE extensions completely at that time and move to use
   NAT-T, but as we loose all the security offered by the MOBIKE, it
   might be better to rekey the IKE SA (if policy allows that) so that
   we do not use MOBIKE at all and start using normal NAT-T.

   If we start using NAT-T, created, then there is no defined way to detect that
   we moved away from the inside of the NAT. Thus we need to modify
   NAT-T and add that kind of detection capability there, if we want to
   start using MOBIKE at that point.

   As a summary, if the policy accepts the risks caused by enabling
   NAT-T, then it can switch to NAT-T when it detects we are behind NAT.
   Easiest way to do it is NAT which appears after moving to create
   a new IKE SA, as NAT-T can only network might cannot be dealt with if NAT detection is enabled by
   only during the initial IKE SA creation, and exchange.  Hence, it cannot might be enabled by
   rekeys. Moving back from NAT-T desirable to
   also support scenario where a MOBIKE is harder as it requires
   changes to NAT-T. On the other hand keeping NAT-T enabled simply adds
   few bytes of extra overhead.

   If we define some additions and extensions peer moves from a network which
   does not deploy a NAT to NAT-T we a network which uses a private address
   space.

   A NAT prevention mechanism can probably be used to make it work better with MOBIKE, but there are quite a lot open
   issues. One way of seeing this is, sure that we have few other parameters
   we might want to turn on during no adversary
   can interact with the address update, i.e. protocol if no NAT is expected between the NAT-T
   parameters. Those include turning
   Initiator and the Responder.

   The support for NAT traversal is certainly one of the most important
   design decisions with an impact on or off keepalives, UDP
   encapsulation, or automatic address updating.

6. other protocol aspects.

5.5  Changing addresses or changing the paths (issue #10, #14)

   The question here is, if

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

   Doing the dead-address detection

   While performing just an address change is simpler, and there is less probe
   packets to be sent, thus it does not cause that much stress to the
   network. It also is enough for the scenarios where the connection
   problems existence of
   locally operational addresses are local (i.e. interfaces going down, WLAN access
   disappearing etc). It does not help if some router somewhere along
   the path breaks down, in which case rerouting the packets along
   another path might get around that broken router. The question is,
   whether rerouting around not, however, a guarantee that problem inside
   communications can be established with the peer.  A failure in the core network is
   routing infrastructure can prevent the sent packets from reaching
   their destination.  Or a
   problem that MOBIKE needs to solve.

7.  How and When to do Return Routability Checks (issue #6, #12, #15)

   One failure of the decisions that needs to an interface on one side can be done is when to do return
   routability checks. The simple approach is
   related to do the failure of an interface on the other side, making it always. Another
   option is
   necessary to do it every time change more than one address at a time.

5.6  Return Routability Tests

   Setting a new IP-address preferred address which is taken in to use. The
   basic format of the return routability check could be similar than
   dead-peer-detection, but the problem subsequently used for
   communication is that if that fails then 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
   IKEv2 specification requires past to allow a peer to compute
   the IKE SA answer to be deleted. Because of this we might need to do some kind question:

   o  The addresses a peer is using is part of other exchange. a certificate.  [RFC3554]
      introduced this approach.  If the other end is SGW peer is, for example, a
      security gateway with a limited set of fixed IP-addresses, IP addresses, then
      the SGW security gateway may have a certificate having with all the IP-addresses IP
      addresses in the certificate. If the certificate includes all the IP-addresses, it is
   no point to do weaker

   o  A return routability check, the data in check is performed before the
   certificate address is already properly authenticated after used
      to ensure that the IKE SA peer is
   created, so reachable at the indicated address.

   Without performing an authorization decision a malicious peer might simply use that and ignore can
   redirect traffic towards a third party or a blackhole.

   An IP address should not be used as a primary address without
   computing the authorization decision.  If the addresses are part of
   the certificate then it is not necessary execute the weaker return
   routability checks for the test.  If multiple addresses are communicated to another
   peer as part of the peer address set then some of these addresses
   might be already verified even if the SGW. primary address is still
   operational.

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

   Final option

   Finally it would simply be possible not to do execute return routability checks
   at all.
   If we use  In case of indirect change notifications then we only move
   to the new
   IP preferred address after successful dead-peer-detection dead-peer detection on
   the new address, which is already a return routability check. In the  With a
   direct change notifications the authenticated peer may have given out provided an
   authenticated
   IP-address, IP address, thus we could simply trust the other end.
   There is no way external attacker can cause any attacks, but we are
   not protected by the internal attacker, i.e.  the authenticated peer
   forwarding its traffic to the new address.  On the other hand we do
   know the identity of the peer in that case.

   As such, it sees 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
   than 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 of other exchange.

   There are some potential attacks which can be launched unless the if a return routability checks include
   some kind of nonce (issue #15). nonce.  In this attack the valid end points sends
   address update notification for the third party, trying to get all
   the traffic to be sent there, causing denial of service attack.  If
   the return routability checks does not contain any cookies or other
   random information not known by 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 to turn the traffic to
   there, even when the real true original recipient isn't cannot be reached at that
   this address.

   The IKEv2 NAT-T mechanism does not do perform any return routability
   checks.  It simply uses the last seen source IP address used by the
   other end, as and address peer where to send return packets back. The attacker response packets.  An adversary can change
   those IP-addresses, IP addresses, and can cause the return response packets to be sent to
   wrong IP-address. IP address.  The situation is fixed immediately self-fixing when the attacker adversary is
   no longer changes
   the packets, able to modify packets and the first packet with real IP-address true IP
   address reaches the other end. peer.  In a certain sense mobility handling
   makes this attack difficult for an adversary since it needs to be
   located somewhere along the path where 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 mobility patterns.  With IKEv2 NAT-T the valid 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
   should protect against those these attacks.

   There might be also return routability information available from the
   other parts of the system too (IP-stack, Mobile IP or so), (as shown in Figure 3), but the checks
   done might be have a different (issue #12). quality.  There are multiple
   different levels for the
   return routability checks:

   o  None, no tests

   o  A party willing to answer is on the path to the claimed 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.

   o  There was an authenticated answer from the peer, but it is not
      guaranteed to be from 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) authenticated).

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

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

   Other levels might only return provide information saying that yes, there is someone there in at
   the IP-address which replied to my request. Or say
   that I sent request IP address which replied to IP-address and got reply back, but I am the request.  There might not
   sure whether be an
   indication that the reply was freshly generated or repeated, or sent the
   request might have been transmitted from a different source address. The

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

5.7  Employing MOBIKE might also want to export results in other protocols

   If MOBIKE has learned about new locations or verified the validity of
   an address through a return routability test, 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 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 has done 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 be useful for SCTP to learn about the new
   addresses at the same time as MOBIKE learns them.  Similarly, various
   IP layer mechanisms might make use of the fact that a return
   routability checks test of a specific type has already been performed.
   However, in all of these cases careful consideration should be
   applied.  This consideration should answer to the questions such as
   whether other modules, like Mobile IP, so
   Mobile alternative sources exist for the information, whether
   dependencies are created between parts that prior to this had no
   dependencies, and what the impacts in terms of number of messages or
   latency are.

   [I-D.crocker-celp] discussed the use of common locator information
   pools in IPv6 multihoming context; it assumed that both transport and
   IP does not need layer solutions would be used for providing multihoming, and that
   it would be beneficial for different protocols to coordinate their
   results in some manner, for instance by sharing experienced
   throughput information for address pairs.  This may apply to do return routability checks again, if MOBIKE
   as well, assuming it
   is satisfied co-exists with non-IPsec protocols that are
   faced with the level same multiaddressing choices.

   Nevertheless, all of checks done by this is outside the MOBIKE.

8. scope of current MOBIKE base
   protocol design and may be addressed in future work.

5.8  Scope of SA changes (issue #8)

   Most sections of this document discuss design considers for updating
   and maintaining addresses for the IKE-SA.  However, changing the
   preferred address also has an impact for IPsec SAs.  The outer tunnel
   header addresses (source IP and destination IP addresses) need to be
   modified according to the preferred address pair 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).

   The basic question is that how the IPsec SAs are changed to use the
   new
   address. address pair (the same address pair as the MOBIKE signaling
   traffic -- the preferred address pair).  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. address pair.  Another option
   is to have separate exchange to move the IPsec SAs separately.

   If we want to update each IPsec SA separately, we probably need SAs should be updated separately then a more efficient
   format than notification payload, as it payload is needed.  A notification payload
   can only store one SPI per payload. I.e. we want  A separate payload which would
   have list of IPsec SA SPIs and new address set for them. preferred address.  If we have lots there are
   large number of IPsec SAs, those payloads can be quite large unless we support
   ranges in
   SPIs or at least have some kind of notation of move those SAs not
   moved separately (i.e. rest of the SAs indication). The
   implementations need also keep state of IP-addresses per IPsec SA,
   not per IKE SA. 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 from that (Note, 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). SA.

   If we do allow each IPsec SAs address sets to be updated separately,
   then we can support scenarios, where the machine have has fast and/or
   cheap connection connections and slow and/or expensive connection, connections, and it wants
   to allow moving some of the SAs to the slower and/or more expensive
   connection, and forbid some SAs prevents to move. I.e. never move 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, i.e. 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.

9.

5.9  Zero Address Set (issue #5)

   One of the features which might be useful would be 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 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.  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, i.e. 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, i.e. 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 the Monday
   morning to support all those people connecting back to network).

10.  What modes we support (issue #7) network).

   From a technical point of view this features 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, nothing breaks if this feature
      is not provided.

   o  MOBIKE signaling messages are also ignored and need to be
      suspended.  The charter mostly talks about VPN style usage, IKE-SA must not be deleted and all scenarios are
   using tunnel mode, so that is where this document mostly
   concentrates. For transport mode the suspend
      functionality (realized with the zero address set) might require
      the IKE-SA to be used we first need tagged with a lifetime value since the IKE-SA
      will not be kept in memory an arbitrary amount of time.  Note that
      the IKE-SA has no lifetime associated with it.  In order to define
      prevent the scenarios where it is needed. XXX someone IKE-SA to be deleted the dead-peer detection mechanism
      needs to write more
   text here.

11.  Message representation

   One of be suspended as well.

   Due to the basic design choices that is needed for enhanced complexity of this extension 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
   format of the messages. The IKEv2 offers some formatting alternatives
   for the protocol. 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 IP address change notifications can be sent either via an
   informational exchange already specified in the IKEv2, or we could also have our own via a
   MOBIKE specific message exchange.  Using informational exchange has
   the main advantage that it is already specified in the IKEv2 and the
   implementations should already have
   code for those.

   One advantage of creation of the new exchange would be that we could
   incorporate the return routability checks to the exchange in this
   state (i.e. create 3-4 packet exchange). The problem here is that we
   might need to do incorporated the return routability checks for each IP-address
   separately, thus we might not be able to do it in this phase. functionality already.

   Another question is the basic format of the address update
   notifications.  The address update notifications can include multiple
   addresses, which some can be IPv4 and some IPv6 addresses.  The
   number of addresses is most likely going to be quite small (less than
   10).  The format might need to give out senders indicate a preference value for each
   address Furthermore, one of the use of
   the addresses, i.e. the sender will tell this is addresses in the preferred peer address to set
   must be used. labeled as the preferred address.  The format could either
   contain the preference number, giving out the relative order of the
   addresses, or it could simply be ordered list of IP-addresses in the order of the most
   preferred first. Benefits of the ordered list is, that then we do not
   need to define what happens if IP addresses in the preference numbers are identical,
   and we do not need to reserve space for
   order of the numbers. Normally we do
   not need any priority values, we simply need most preferred first.  While two addresses can have the
   same preference value an ordered list. list avoids this problem.

   Even when the load-balancing inside the one connection if load balancing is currently outside the scope of the MOBIKE,
   there might be future work to include that. this feature.  The format
   selected needs to be flexible enough to allow addition of some
   kind of extra include additional
   information for the load-balancing features in the
   future. (e.g., to enable load balancing).  This might be
   something like one reserved field, which can later be used to store that
   additional information.  As there is other potential information
   which might have to be tied to the address in the future, a reserved
   field seems like a prudent design in any case.

   There are two basic formats for putting IP-address IP address list in to the
   exchange, we can include each IP-address 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 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. IP
   addresses.

   Having multiple payloads each having one IP-address 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.  It also offers
   easy way for the extensions, as the payload probably contains only
   the type of the IP-address IP address (or the type is encoded to the payload
   type), and the IP-address 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. IP address.  Some implementations might have problems
   parsing too long list of IKEv2 payloads, but if the sender sends them
   in the most preferred first, the other end can simply only take n
   first addresses and use them. It might loose connection in some cases
   if all the n first address are not in use anymore, and the other end
   hasn't sent new list, but in most cases everything will still work.

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

   The next choice is which type of payloads to use.  IKEv2 already
   specifies a notify payload, which could be used for that. 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 our own a custom payload type, which then
   include
   includes the information needed for the MOBIKE protocol.

   The basic protocol is most likely going to be something where we

   MOBIKE might send the full peer address list once one of all IP-addresses every time the list IP
   addresses changes (either addresses are added, removed, the order
   changes or the preferred order changes).
   Another option address is that we send some kind of updated) or an incremental updates to
   the IP-address list.
   update.  Sending incremental updates provides more compact packets
   (meaning we can support more IP-addresses), IP addresses), but on the other hand
   have more problems in the synchronization and packet reordering cases i.e.
   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).

   The address update notification protocol is not restricted

   Note that each peer needs to only
   one way, i.e. both ends might have multiple IP-addresses and both
   ends might send communicate its peer address updates. Example of that is when the roaming
   laptop connects set to the multihoming SGW.

12.
   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 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 not cause any direct actions.

   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 denial of service and/or the use of non-preferred addresses,
   so it is not that serious.

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

13.

7.  IANA Considerations

   No

   This document does not introduce any IANA assignments are needed.

14. 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 and Joe Touch
   for their discussion input.

9.  References

14.1

9.1  Normative references

   [I-D.ietf-ipsec-ikev2]
              Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              draft-ietf-ipsec-ikev2-14
              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", draft-ietf-ipsec-rfc2401bis-05 (work
              in progress), December 2004.

9.2  Informative References

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

   [Kiv04]    Kivinen, T., "MOBIKE protocol",
              draft-kivinen-mobike-protocol-00

   [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", draft-dupont-mipv6-3bombing-00 (work in progress),
              February 2004.

14.2  Non-normative references

   [I-D.nikander-mobileip-v6-ro-sec]

   [I-D.ietf-mip6-ro-sec]
              Nikander, P., "Mobile IP version 6 Route Optimization
              Security Design Background",
              draft-nikander-mobileip-v6-ro-sec-02 draft-ietf-mip6-ro-sec-02
              (work in progress),
              December October 2004.

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

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

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

   [I-D.dupont-mipv6-3bombing]

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, 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",
              draft-ietf-tsvwg-addip-sctp-09 (work in progress), June
              2004.

   [I-D.dupont-ikev2-addrmgmt]
              Dupont, F., "A note about 3rd party bombing in Mobile
              IPv6", draft-dupont-mipv6-3bombing-00 "Address Management for IKE version 2",
              draft-dupont-ikev2-addrmgmt-06 (work in progress),
              February October
              2004.

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

   [Aur02]    Aura, T., Roe, 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.

Author's Address

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
   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; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose at
   ietf-ipr@ietf.org.

Disclaimer of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees. Validity

   This document and the information contained herein is 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 DISCLAIMS 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 (2004).  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.