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

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

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with 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 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 January 19, April 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The MOBIKE (IKEv2 Mobility and Multihoming) working group is
   developing extensions for the Internet Key Exchange Protocol version
   2 (IKEv2).  These extensions should enable an efficient management of
   IKE and IPsec Security Associations when a host possesses multiple IP
   addresses 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.  Design decisions for the MOBIKE protocol,
   background information and discussions within the working group are
   recorded.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   3.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1  8
     3.1.  Mobility Scenario  . . . . . . . . . . . . . . . . . . . .  7
     3.2  8
     3.2.  Multihoming Scenario . . . . . . . . . . . . . . . . . . .  8
     3.3  9
     3.3.  Multihomed Laptop Scenario . . . . . . . . . . . . . . . .  9 10
   4.  Framework  . . .  Scope of MOBIKE  . . . . . . . . . . . . . . . . . . . . . . . 10 11
   5.  Design Considerations  . . . . . . . . . . . . . . . . . . . . 13
     5.1   Indicating Support for MOBIKE 14
     5.1.  Choosing addresses . . . . . . . . . . . . . . 13
     5.2   Changing a Preferred Address . . . . . . 14
       5.1.1.  Inputs and Multi-homing Support triggers  . . . . . . . . . 13
       5.2.1   Storing a single or multiple addresses . . . . . . . . 14
       5.2.2   Indirect or Direct Indication
       5.1.2.  Connectivity . . . . . . . . . . . . . . . . . . . . . 14
       5.1.3.  Discovering connectivity . . . . . . . . . . . . . . . 15
       5.2.3   Connectivity Tests using IKEv2 Dead-Peer Detection
       5.1.4.  Decision making  . . . 16
     5.3   Simultaneous Movements . . . . . . . . . . . . . . . . 15
       5.1.5.  Suggested approach . . 17
     5.4 . . . . . . . . . . . . . . . . 15
     5.2.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 18
     5.5   Changing addresses or changing the paths 16
       5.2.1.  Background and constraints . . . . . . . . . 20
     5.6   Return Routability Tests . . . . . 16
       5.2.2.  Fundamental restrictions . . . . . . . . . . . . 20
     5.7   Employing MOBIKE results in other protocols . . . 16
       5.2.3.  Moving to behind NAT and back  . . . . 23
     5.8   Scope of SA changes . . . . . . . . 16
       5.2.4.  Responder behind NAT . . . . . . . . . . . 24
     5.9   Zero Address Set . . . . . . 17
       5.2.5.  NAT Prevention . . . . . . . . . . . . . . . 25
     5.10  IPsec Tunnel or Transport Mode . . . . . 17
       5.2.6.  Suggested approach . . . . . . . . . 25
     5.11  Message Representation . . . . . . . . . 17
     5.3.  Scope of SA changes  . . . . . . . . . 26
   6.  Security Considerations . . . . . . . . . . 18
     5.4.  Zero address set functionality . . . . . . . . . 28
   7.  IANA Considerations . . . . . 19
     5.5.  Return routability test  . . . . . . . . . . . . . . . . 29
   8.  Acknowledgments . 19
       5.5.1.  Employing MOBIKE results in other protocols  . . . . . 22
       5.5.2.  Suggested approach . . . . . . . . . . . . . . . . . 30
   9.  Open Issues . 23
     5.6.  IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 23
   6.  Protocol detail issues . . . . . . . . . . 31
   10.   References . . . . . . . . . . 24
     6.1.  Indicating support for mobike  . . . . . . . . . . . . . . 24
     6.2.  Path Testing and Window size . 32
     10.1  Normative references . . . . . . . . . . . . . . 25
     6.3.  Message presentation . . . . . 32
     10.2  Informative References . . . . . . . . . . . . . . 26
     6.4.  Updating address list  . . . . 32
       Authors' Addresses . . . . . . . . . . . . . . 27
   7.  Security Considerations  . . . . . . . . 34
       Intellectual Property and Copyright Statements . . . . . . . . 35

1.  Introduction

   The purpose of IKEv2 is to mutually authenticate two hosts, establish
   one or more IPsec Security Associations (SAs) between them, and
   subsequently manage . . . 28
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 30
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     10.1. Normative references . . . . . . . . . . . . . . . . . . . 31
     10.2. Informative References . . . . . . . . . . . . . . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 35

1.  Introduction

   The purpose of IKEv2 is to mutually authenticate two hosts, establish
   one or more IPsec Security Associations (SAs) between them, and
   subsequently manage these SAs (for example, by rekeying or deleting).
   IKEv2 enables the hosts to share information that is relevant to both
   the usage of the cryptographic algorithms that should be employed
   (e.g., parameters required by cryptographic algorithms and session
   keys) and to the usage of local security policies, such as
   information about the traffic that should experience protection.

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

   There are scenarios where one or both of the IP addresses of this
   pair may change during an IPsec session.  In principle, the IKE SA
   and all corresponding IPsec SAs could be re-established after the IP
   address has changed.  However, this can be problematic, as the device
   might be too slow for this task.  Moreover, manual user interaction
   (for example when using SecurID cards) might be required as part of
   the IKEv2 authentication procedure.  Therefore, an automatic
   mechanism is neeed need that updates the IP addresses associated with the
   IKE SA and the IPsec SAs.  MOBIKE provides such a mechanism.

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

   This document is structured as follows.  After introducing some
   important terms in Section 2 a number of relevant usage scenarios are
   discussed in Section 3.  The next section Section 4 discusses will describe the interoperation
   scope of
   MOBIKE with other protocols and processes that may run in the local
   machine. MOBIKE protocol.  Finally, Section 5 discusses design
   considerations affecting the MOBIKE protocol.  The document concludes
   in Section 6 7 with security considerations.

2.  Terminology

   This section introduces the terminology that is used in this
   document.

   Peer:

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

   Available address:

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

      *  The address has been assigned to an interface.

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

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

      *  If the address is an IPv6 address, it is a global unicast or
         unique site-local address, as defined in [I-D.ietf-ipv6-unique-
         local-addr].  That is, it is not an IPv6 link-local.  Where
         IPv4 is considered, it is not an RFC 1918 [RFC1918] address.

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

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

      .
      detection].

   Locally Operational Address:

      An address is said to be locally operational if it is available
      and its use is locally known to be possible 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, if and only if bidirectional connectivity can be
      shown between the two addresses.  Note that sometimes it is
      necessary to consider connectivity on a per-flow level between two
      endpoints needs to be tested.  This differentiation might be
      necessary to address certain Network Address Translation types or
      specific firewalls.  This definition is taken from [I-D.arkko-
      multi6dt-failure-detection] and adapted for the MOBIKE context.
      Although it is possible to further differentiate unidirectional
      and bidirectional operational address pairs, only bidirectional
      connectivity is relevant to this document and unidirectional
      connectivity is out of scope.

   Path:

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

   Primary Path:

      The sequence of routers traversed by an IP packet that carries the
      default source and destination addresses is said to be the Primary
      Path.  This definition is taken from [RFC2960] and adapted to the
      MOBIKE context.

   Preferred Address:

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

   Peer Address Set:

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

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

3.  Scenarios

   In this section we discuss three typical usage scenarios for the
   MOBIKE protocol.

3.1

3.1.  Mobility Scenario

   Figure 1 shows a break-before-make mobility scenario where a mobile
   node changes its point of network attachment.  Prior to the change,
   the mobile node had established an IPsec connection with a security
   gateway which offered, for example, access to a corporate network.
   The IKEv2 exchange that facilitated the set up of the IPsec SA(s)
   took place over the path labeled as 'old path'.  The involved packets
   carried the MN's "old" IP address and were forwarded by the "old"
   access router (OAR) to the security gateway (GW).

   When the MN changes its point of network attachment, it obtains a new
   IP address using statefu stateful address configuration techniques or via the
   stateless address autoconfiguration mechanism.  The goal of MOBIKE,
   in this scenario, is to enable the 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', enables the peers to
   update their state as necessary.

   Note that in a break-before-make scenario the MN obtains the new IP
   address after it can no longer be reached at the old IP address.  In
   a make-before-break scenario, the 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

3.2.  Multihoming Scenario

   Another MOBIKE usage scenario is depicted in Figure 2.  In this
   scenario, the MOBIKE peers are equipped with multiple interfaces (and
   multiple IP addresses).  Peer A has two interface cards with two IP
   addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1
   and IP_B2.  Each peer selects one of its IP addresses as the
   preferred address which is used for subsequent communication.
   Various reasons, (e.g hardware or network link failures), may require
   a peer to switch from one interface to 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

3.3.  Multihomed Laptop Scenario

   The third scenario we consider is about a laptop, which has multiple
   interface cards and therefore several ways to connect to the network.
   It may for example have a fixed Ethernet card, a WLAN interface, a
   GPRS adaptor, a Bluetooth interface or USB hardware.  Not all
   interfaces are connected to the network at all times for a number of
   reasons (e.g., cost, availability of certain link layer technologies,
   user convenience).  The mechanism that determines which interfaces
   are connected to the network at any given point in time is outside
   the scope of the MOBIKE protocol and, as such, this document.
   However, as the laptop changes its point of attachment to the
   network, the set of IP addresses under which the laptop is reachable,
   changes too.

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

4.  Framework

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

   o  inform the other peer about

   Getting mobility and multihoming actually working requires lots of
   different components working together, including coordinating things
   and making consistent decisions in several link layers, the peer address set IP
   layers, different mobility mechanisms in those layers, and IPsec/IKE.
   Most of those aspects are beyond the scope of MOBIKE: The MOBIKE
   focuses on what two peers need to agree in IKEv2 level (like new
   message formats and some aspects of their processing) for
   interoperability.

   The MOBIKE is not trying to be full mobility protocol; there is no
   support for simultaneous movement or rendezvous mechanism, and there
   is no support for route optimization etc.  This current design
   document focuses mainly on the tunnel mode, everything going inside
   the tunnel is unaffected by the changes in the tunnel header IP
   address, and this is the mobility feature provided by the MOBIKE.
   I.e. the applications running through the MOBIKE IPsec tunnel cannot
   even detect the movement, their IP address etc stay constant.

   A MOBIKE protocol should be able to perform the following operations:

   o  inform the other peer about the peer address set

   o  inform the other peer about the preferred address

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

   o  change the preferred address

   o  change the peer address set

   o  Ability to deal with Network Address Translation devices

   The technical details

   Figure 3 shows an example protocol interaction between a pair of these functions are discussed below.
   Although
   MOBIKE will have to interact peers.  MOBIKE interacts with other mechanisms, the
   working group is chartered to leave IPsec engine using the
   PF_KEY API [RFC2367].  Using this aspect outside API, the scope.

   When a MOBIKE peer initiates a protocol exchange it needs to define a
   peer address set based on daemon can create
   entries in the IP addresses available to it. Security Association (SAD) and Security Policy
   Databases (SPD).  The peer IPsec engine may want to make also interact with IKEv2 and
   MOBIKE daemon using this set available to the other peer. API.  The IKEv2
   Initiator does not need to indicate which content of the addresses Security Policy and
   Security Association Databases determines what traffic is protected
   with IPsec in the
   peer address set is its preferred address.  This is because the
   Initiator has to place its preferred address into the source IP
   address field of the IP header with the initial message exchange.
   Additionally, the Initiator expects incoming signaling messages to
   arrive at this address.  The peer address set and the preferred
   address are defined based on interaction with other components within
   a host.  In some cases, the peer address set 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 may change as well.

   A modification of the peer address set or a change of the preferred
   address typically is the 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 between a pair of
   MOBIKE peers.  MOBIKE interacts with the IPsec engine using the
   PF_KEY API [RFC2367].  Using this API, the MOBIKE daemon can create
   entries in the Security Association (SAD) and Security Policy
   Databases (SPD).  The IPsec engine may also interact with IKEv2 and
   MOBIKE daemon using this API.  The content of the Security Policy and
   Security Association Databases determines what traffic is protected
   with IPsec in which fashion.  MOBIKE, on which fashion.  MOBIKE, on the other hand, receives
   information from a number of sources that may run both in kernel-mode
   and in user-mode.  Information relevant for MOBIKE might be stored in
   a database.  The contents of such a database, along with the
   occurrence of events of which the MOBIKE 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
   may also affect the selection process.

   The a peer address set and the preferred address needs to be
   available to the other peer.  In order to address certain failure
   cases, MOBIKE should perform connectivity tests between the peers
   (potentially over a number of different paths).  Although a number of
   address pairs may be available for such tests, the most important is
   the pair (source address, destination address) of the primary path.
   This is because this pair is selected for sending and receiving
   MOBIKE signaling and IPsec traffic.  If a problem along this primary
   path is detected (e.g., due to a router failure) it is necessary to
   switch to a new primary path.  In order to be able to do so quickly,
   it may be helpful to perform connectivity tests of other paths
   periodically.  Such a technique would also help in identifying
   previously disconnected 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 illustrates an example of 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 for
   wireless environments are also 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, both peers must implement

5.1.  Choosing addresses

   One of the MOBIKE
   extension core aspects of IKEv2.  If one or none the MOBIKE protocol is the selection of
   the peers supports MOBIKE,
   then, whenever an IP address changes, for the IPsec packets we send.  Choosing addresses for
   the IKEv2 request is somewhat separate problem: in many cases, they
   will have to be re-run the same (and in
   order to create a new IKE SA some design choice they will always be the
   same).

5.1.1.  Inputs and triggers

   How the respective IPsec SAs.  In
   MOBIKE, a address changes are triggered are largerly beyond the scope
   of MOBIKE.  The triggers can include e.g. changes in the set of
   addresses, various link-layer indications, failing dead peer needs
   detection, and changes in preferences and policies.  Furthermore,
   there may be less reliable sources of information (such as lack of
   IPsec packets and ICMP packets) that do not trigger any changes
   directly, but rather cause DPD to be confident performed sooner than it
   otherwise would have been (and if that its address change messages DPD fails, that may trigger
   changing of addresses).

   These triggers are understood by largerly the other peer.  If these messages same as for, e.g.  Mobile IP, and are not
   understood, it is possible that connectivity between
   beyond the peers scope of MOBIKE.

5.1.2.  Connectivity

   There can be two kind of "failures" in the connectivity; local or
   middle.  Local failure is
   lost.

   One way to ensure that a peer receives feedback on whether or not its
   messages are understood by property of an address (interface), while
   the other peer, failures in the middle is by using IKEv2
   messaging for property of address pair.  MOBIKE and does
   not assume full connectivity, but it does not try to mark some messages as "critical".
   According use
   unidirectional address pairs (multi6 has discussed about how to deal
   with unidirectional paths).  Unidirectional address pairs is
   complicated issue, and supporting it would require abandoning the
   principle that you always send the IKEv2 specification, such messages either have reply to be
   understood by the receiver, or an error message has to be returned to address the sender.

   A second way to ensure receipt
   request came from.  Because of the above-mentioned feedback is by
   using Vendor ID payloads that are exchanged during the initial IKEv2
   exchange.  These payloads would then indicate whether or not a given
   peer supports the MOBIKE protocol.

   A third approach would decided to deal only with
   bidirectional address pairs.  It does consider unidirectional address
   pairs as broken, and not use them, but the Notify payload which connection will not break
   even if unidirectional address pairs are present, provided there is also used for
   NAT detection (via NAT_DETECTION_SOURCE_IP and
   NAT_DETECTION_DESTINATION_IP payloads).

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

   Note
   at least one bidirectional address pair it can use.

   Note, that a MOBIKE peer could also attempt to execute MOBIKE
   opportunistically with is not really concerned about the critical bit set when an actual path used,
   it cannot even detect if some path is unidirectional, if the same
   address change pair has occurred.  The drawback of this approach is, however, some other unidirectional path back.  Ingress
   filters might still cause such path pairs to be unusable, and in that an
   unnecessary
   case MOBIKE message exchange will detect that there is introduced.

   Although Vendor ID payloads and Notifications are technically
   equivalent, Notifications are already used in IKEv2 as no connection between address
   pair.

   In a capability
   negotiation mechanism.  Hence, Notifications sense having both IPv4 and Vendor ID payloads
   are the preferred mechanisms.

5.2  Changing IPv6 address is basically a Preferred Address and Multi-homing Support

   From MOBIKE's point case of view, support for multi-homing is inherently
   provided by
   partial connectivity (putting both IPv4 and IPv6 address in the fact same
   IP header does not work).  The main difference is that it manages a set of peer addresses, rather
   than a single address.  Further, MOBIKE provides mechanisms to change
   a peer's preferred IP address.  Each peer needs to learn the
   preferred address and the peer address set.

5.2.1  Storing a single or multiple addresses

   One design decision is whether an IKE-SA should be associated with a
   single IP address or multiple IP addresses.  One option known
   beforehand, and there is that a
   peer can provide a list of addresses no need to its counterpart which can
   then be used as destination addresses.

   Note discover that MOBIKE IPv4/IPv6
   combination does not support load balancing, i.e., only one IP
   address is set to a preferred address at a time and changing work.

5.1.3.  Discovering connectivity

   To detect connectivity, i.e failures in the
   preferred address typically requires some middle, MOBIKE signaling.

   Another option is needs to only communicate one address
   have some kind of probe which it can send to the other peer end and both peers only use that address when communicating. get a
   reply back to that.  If this
   address cannot be used anymore then an it will see the reply it knows the connection
   works, if it does not see the reply after multiple retransmissions it
   may assume that the address update pair tested is sent broken.

   The connectivity tests do require to take in to account the
   other peer that changes
   congestion problems, because the preferred address.

   Alternatively, if peer A, for example,provides a peer address set
   with multiple IP addresses then peer B can recover from a connection failure might be because
   of congestion, and the preferred address without further communication with peer A. That
   is, if it detects that the primary path does MOBIKE should not work anymore make it can
   either switch worse by sending
   lots of probe packets.

5.1.4.  Decision making

   One of the core decisions to a new preferred address locally (i.e., changing the
   source IP address of outgoing MOBIKE messages) or protocol is to try an IP
   address from A's peer address set (i.e., changing who makes the destination
   address).  If peer B only received a single IP address from peer A
   for A then peer B can only change its own preferred address.  Peer B
   would have to wait for an address update from peer A with a new IP
   address in order
   decisions to fix situations, i.e. symmetry in decision making vs.
   asymmetry in decisions.  Symmetric decision making may cause the problem.

   The main advantage of storing only a single IP address for the remote
   peer
   different peers to make different decisions, thus causing asymmetric
   upstream/downstream traffic.  In mobility case it is desirable that it makes retransmission handling easier.  Moreover, it
   simplifies
   the recovery procedure.  The mobile peer whose IP can move both upstream and downstream traffic to some
   particular interface, and this requires asymmetric decision making.

   Working with stateful packet filters and NATs is easier if same
   address changed
   must start the recovery process pair is used in both upstream and send downstream directions.
   Also in common cases only the new IP address peer behind NAT can actually do actions
   to recover from the
   other peer.  However, connectivity failures along problems, as it might be that the path are
   other peer is not
   well addressed with advertising a single IP address.

   The single IP address able to initiate any connections to the peer behind
   NAT.

5.1.5.  Suggested approach does not work if both peers change
   their IP addresses at

   Because of those issues listed above, the same time, for example if both hosts move
   simultaneously, even though multiple MOBIKE protocol decided to
   select method where the initiator will decide which addresses are available
   used.  This has the benefits that it makes one peer to decide, thus
   we cannot end up in the
   two peers.  The IKEv2 implementation might asymmetric decisions, and it also require window size
   to be larger than 1 because works best
   with NATs, as the MOBIKE initiator is the most common peer needs to be able to send behind NAT,
   and thus is the IP address change notifications before it switches to another
   address.  Depending on the occurrence only peer which can recover in those cases.

5.2.  NAT Traversal

5.2.1.  Background and constraints

   Another core aspect of return routability checks,
   retransmissions policies the MOBIKE was the co-operation and similar message exchanges a window size
   larger than 1 might be required to deal working
   with more than one pending
   response at the same time.  Furthermore, NATs.  In IKEv2 the single tunnel header IP address
   approach does addresses are not really benefit much from indirect indications as sent
   inside the peer receiving these indications might not be able IKEv2 payloads, and thus there is no need 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 another IP
   address, since it does not know any). do unilateral
   self-address fixing (UNSAF).  The problems with tunnel header IP address lists lie mostly in their complexity.
   Notification and recovery processes addresses are more complicated.  Both ends
   can recover
   taken from the outer IP address changes.  However, both peers should
   not attempt to recover at header of the same time or nearly IKE packets, thus they are
   already processed by the same time as
   this could cause them to lose connectivity. NAT.

   The MOBIKE protocol is
   required NAT detection payloads are used to prevent this.

   The previous discussion is independent of detect if 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 header were modified by a single address only.  A NAT does not change addresses
   carried inside between the peers, and that enables
   UDP encapsulation of ESP packets if needed.  MOBIKE message but it can is not to change IP address (and
   transport layer addresses)
   how IKEv2 NAT-T works, in particular, any kind of UNSAF or explicit
   interaction with NATs (e.g. midcom or nsis natfw) are beyond the IP header
   scope.  The MOBIKE will need to define how MOBIKE and Transport Protocol
   header (if NAT traversal NAT-T are used
   together.

   The NAT-T support should also be optional, i.e. if the IKEv2
   implementation does not implement NAT-T, since it is enabled not required in
   some particular environment, implementing MOBIKE should not require
   adding support for NAT-T as part well.

   The property of configuration or
   dynamically through the being behind NAT discovery mechanism.  Furthermore, a
   MOBIKE message carrying is actually property of the peer address set could
   pair, thus one peer can have multiple IP-addresses and some of those
   might be idempotent
   (i.e., always resending the full address list) or the protocol may
   allow add/delete operations to behind NAT and some might not be specified.  [I-D.dupont-ikev2-
   addrmgmt], for example, offers an approach behind NAT.

5.2.2.  Fundamental restrictions

   There are some cases which defines add/delete
   operations.  The same cannot be made work with the restrictions
   provided by the MOBIKE charter.  One of those cases is true for the dynamic case where
   the party "outside" a symmetric NAT changes its address reconfiguration
   extension for SCTP [I-D.ietf-tsvwg-addip-sctp].

5.2.2  Indirect or Direct Indication

   An indication to change something
   not known by 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.  This can, for example, be accomplished
      by having MOBIKE sending an authenticated (and old address update
      notification with has stopped
   working).  It cannot send a different preferred address.

   Indirect indication:

      An indirect indication packet containing the new addresses to change
   the preferred address can be
      obtained by observing peer, because the environment.  An indirect indication
      might, for example, be NAT does not contain the receipt of an ICMP message or
      information about a link failure.  This information should be seen
      as a hint and should necessary state.
   Furthermore, since the party behind the NAT does not know the new IP
   address, it cannot cause a change of the remote peer's
      preferred address.  Depending on NAT state to be created.

   This case could be solved using some rendezvous mechanism outside
   IKEv2, but that is beyond the local policy, MOBIKE may
      decide scope of MOBIKE.

5.2.3.  Moving to perform a dead-peer detection exchange for behind NAT and back

   MOBIKE provides mechanism where peer not initially behind the preferred NAT,
   can move to behind NAT, when new address pair (or another is selected.  MOBIKE
   does not need to detect when someone attach NAT to the currently
   working address pair from pair, i.e. the NAT detection is only done when MOBIKE
   changes the peer address set).
      When a peer detects that pair used.

   Similarly the other end started MOBIKE provides mechanism to use a different
      source IP move from the address than before, it might want pair
   having NAT to authorize the new
      preferred address (if pair not already authorized).  Authorization aims
      to ensure that a particular peer is allowed to having NAT.

   As we only use the indicated
      address.  Claiming to be at an arbitrary one address without
      performing a return-routability test pair at time, effectively MOBIKE peer is
   either behind NAT or without verifying that the
      IP not behind NAT, but each address is listed within a certificate opens change can
   change the door for
      various denial of service attacks.  Hence a peer may also start a
      connectivity test situation.  Because of this particular address.

   If more information and because initiator always
   chooses the addresses it is available enough to the send keepalive packets only to
   that one address pair.

5.2.4.  Responder behind NAT

   MOBIKE daemon then a more
   intelligent decision regarding the selection of a new primary path can be made.

5.2.3  Connectivity Tests using IKEv2 Dead-Peer Detection

   This section discusses the suitability of work in cases where the IKEv2 dead-peer
   detection (DPD) mechanism for connectivity tests between address
   pairs.  The basic IKEv2 DPD mechanism responder is not modified by MOBIKE behind static NAT,
   but
   it in that case the initiator needs to be investigated whether it know all possible addresses
   where the responder can be used for MOBIKE
   purposes as well.

   The IKEv2 DPD mechanism involves sending an empty informational
   exchange packet move to, i.e. responder cannot move to a given address of the remote peer.  On receipt,
   the remote peer responds with an acknowledgement.  If no
   acknowledgement is received after a certain timeout period (and after
   couple of retransmissions), the remote peer
   address which is considered to be not
   reachable at the address in question.  On known by the other hand, receipt of
   IPsec protected acknowledgement is a guarantee that initiator.

   If the other peer responder is
   reachable at the address in question.

   When reusing dead-peer detection in MOBIKE for connectivity tests behind NAPT then it
   seems might need to be reasonable communicate
   with the NAT to try other IP addresses (if they create mapping so initiator can connect to it.  Those
   external hole punching mechanisms 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 beyond the original dead-peer
   detection message (i.e. they are simply retransmissions scope of MOBIKE.

   In case the dead-
   peer detection packet using different destination IP address).  If
   different message-id responder is used behind NAPT then it violates constraints placed also finding the port
   numbers used by the IKEv2 specification on responder, is outside the DPD message with regard to scope of MOBIKE.

5.2.5.  NAT Prevention

   One new feature created by the
   mandatory ACK for each message-id, causing MOBIKE, is the IKEv2 SA NAT prevention, i.e. if
   we detect NAT between the peers, we do not allow that address pair to
   be
   deleted.

   If MOBIKE strictly follows the guidelines of the dead-peer detection
   mechanism in IKEv2 then an IKE-SA should used.  This can be marked as dead and
   deleted if used to protect IP-addresses in cases where it
   is known by the connectivity test for all available address pairs
   fails.  Note configuration that this there 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) no NAT between the IP address nodes
   (for example IPv6, 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. fixed site-to-site VPN).  This
   comparison with SCTP aims gives extra
   protection against 3rd party bombing attacks (attacker cannot divert
   the traffic to point at another IETF protocol some 3rd party).  This feature means that aims
   to address we
   authenticate the multi-homing problem (although with a different scope
   and a different layer).

   Note that IKEv2 implementations may have a window size of 1, IP-address and
   therefore be unable to initiate a dead-peer detection exchange while
   another exchange is pending. detect if they were changed.  As a result, all other exchanges are
   subject to an identical retransmission policy as used for the dead-
   peer detection.  To use a different policy for different message
   types seems this
   is done on purpose to be reasonable.

   The dead-peer detection mechanism for break the other IP address pairs can
   also be executed simultaneously connectivity if NAT is detect, and
   decided by the window size larger than 1,
   meaning configuration, there is no need to do UNSAF
   processing.

5.2.6.  Suggested approach

   The working group decided that after MOBIKE uses NAT-T mechanisms from the initial timeout period of
   IKEv2 protocol as much as possible, but decided to change the preferred dynamic
   address expires, DPD update for IKEv2 packets are sent simultaneously to all other
   address pairs.  It is necessary MUST NOT (it would break path
   testing using IKEv2 packets).  Working group also decided to differentiate acknowledgement
   messages in order only
   send keepalives to determine which address pair is operational.
   The source IP the current address pair.

5.3.  Scope of SA changes

   Most sections of the acknowledgement can be used for this
   purpose.

   The protocol should also be nice to the network, meaning, that when
   some core link goes down, document discuss design considerations for
   updating and a large number of MOBIKE clients notice
   this, they should not start sending a large number of messages while
   trying to recover from the problem.  This may be particularly
   unfortunate because packets may be dropped because of congestion maintaining addresses in the 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 database entries 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
   relate to provide a mobility solution that allows
   simultaneous movements.  Instead, an IKE-SA.  However, changing the MOBIKE working group focuses on
   selected scenarios as described in Section 3.  Some of preferred address also
   affects the scenarios
   assume that one peer has a fixed set entries of the IPsec SA database.  The outer tunnel
   header addresses (from which some
   subset might (source and destination IP addresses) need to be in use).  Thus it cannot move
   modified according to an address that is
   unknown the primary path to allow the other peer.  Situations in which both peers move
   simultaneously are outside IPsec protected
   data traffic to travel along the scope of same path as the MOBIKE WG.  MOBIKE has
   not been chartered to deal with packets (if
   we only consider the rendezvous problem, or with IP header information).  If the
   introduction of new entities in MOBIKE messages
   and the network.

   Note that if only IPsec protected data traffic travel along a single address different path
   then NAT handling is stored in severely complicated.

   The basic question is then how the peer IPsec SAs are changed to use the
   new address set
   (instead of an pair (the same address list) we might end up in the case where it
   seems that both peers changed their addresses at the same time (e.g.,
   if both nodes change their addresses at pair as the same time).  This MOBIKE signaling
   traffic).  One option is
   something that when the MOBIKE protocol must deal with.

   Three cases can be differentiated:

   o  Two mobile nodes obtain a IKE SA address is changed then
   automatically all IPsec SAs associated with it are moved along with
   it to new address at pair.  Another option is to have a separate
   exchange to move the same time, and IPsec SAs separately.

   If IPsec SAs should be updated separately then
      being unable to tell each other where they are (in a break-before-
      make scenario).  This problem is called more efficient
   format than the rendezvous problem,
      and notification payload 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 additional infrastructure nodes.

   o  Simultaneous changes needed to addresses such that at least preserve bandwidth.
   A notification payload can only store one SPI per payload.  A
   separate payload could have list of the IPsec SA SPIs and new addresses preferred
   address.  If there is known to the other peer before 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 change
      occurred.

   o  No simultaneous changes at all.

5.4  NAT Traversal

   IKEv2 supports legacy NAT traversal.  This feature is known as NAT-T IKE SA moves, then we only
   need to keep track which allows IKEv2 IKE SA was used to work even if a NAT along the path between the
   Initiator and the Responder modifies create the source IPsec SA, and possibly
   fetch the
   destination IP address.  With NAPT even the transport protocol
   identifiers are modified (which then addresses from IKE SA, i.e. no need to store IP
   addresses per IPsec SA.  Note that IKEv2 [I-D.ietf-ipsec-ikev2]
   already requires UDP encapsulation for
   exchanged implementations to keep track which IPsec protected data traffic).  Therefore, SAs are
   created using which IKE SA.

   If we do allow each IPsec SA address set to be updated separately,
   then we can support scenarios, where the MOBIKE
   daemon needs machine has fast and/or
   cheap connections and slow and/or expensive connections, and it wants
   to obtain allow moving some of the SAs to required IP address informationfrom the IP
   header (if a NAT was detected that modified slower and/or more expensive
   connection, and prevent the IP header) rather
   than move, for example, of the news video
   stream from the protected payload.  This problem 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 not new
   used for important traffic, and then we create another IKE SA which
   have only the fast and/or cheap connection, which is an
   issues then used for
   that kind of every mobility bulk traffic.

   MOBIKE protocol where the most important
   information exchanged is decided to move all IPsec SAs implicitly when the IP IKE
   SA address .

   One pair changes.  If more granular handling of the goals in the MOBIKE protocol IPsec SA
   is to securely exchange required, then multiple IKE SAs can be created one
   or more addresses for each set of the peer
   IPsec SAs needed.

5.4.  Zero address set and to securely set the
   primary address.  If no other protocol is used to securely retrieve functionality

   One of the IP address and port information allocated by features which is potentially useful is for the NAT then peer to
   announce that it is will now disconnect for some time, i.e. it will not possible
   be reachable at all.  For instance, a laptop might go to tackle all attacks against MOBIKE.  Section 6
   discusses suspend
   mode.  In this aspect in more detail.  Various approaches to solve case the problem have been presented:

   o  Securely retrieving IP 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 port information allocated by could then temporarily disable all SAs and
   therefore stop sending traffic.  If any of the NAT using a protocol different from MOBIKE. SAs gets any packets
   they are simply dropped.  This approach is
      outside the scope could also include some kind of ACK
   spoofing to keep the MOBIKE working group since other working
      groups, such as MIDCOM TCP/IP sessions alive (or simply set the TCP/IP
   keepalives and NSIS, already deal with this problem.
      The MOBIKE protocol can benefit from timeouts large enough not to cause problems), or it
   could simply be left to the interaction with these
      protocols but applications, e.g. allow TCP/IP sessions
   to notice the interaction with these protocols it outside link is broken.

   The local policy could then indicate how long the
      scope peer should allow
   remote peers to remain disconnected.

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

   o  Design a protocol in such a way that NAT boxes are able  There is no need to inspect
      (or even participate) in the protocol exchange. transmit IPsec data traffic.  IPsec protected
      data can be dropped which saves bandwidth.  This approach was
      taken with the Host Identity Protocol but does not provide
      a functional benefit, i.e., nothing breaks if this feature is not an option for
      IKEv2 and
      provided.

   o  MOBIKE since most IKEv2 signaling messages are encrypted with also ignored.  The IKE-SA must not
      be deleted and the
      established IKE SA.  This prevents suspend functionality (realized with the NAT from learning required
      information from zero
      address set) may require the protocol exchange in IKE-SA to be tagged with a similar fashion as lifetime
      value since the IKE-SA should not be kept in
      HIP.

   o  Disable NAT-T by indicating alive for an
      undefined period of time.  Note that IKEv2 does not require that
      the desire never IKE-SA has a lifetime associated with it.  In order to use information
      from prevent
      the (unauthenticated) header.  While this approach prevents
      some security problems it effectively disallows IKE-SA from being deleted the protocol dead-peer detection mechanism
      needs to
      work in environments with NATs.

   There is no way be suspended as well.

   Due to distinguish the whether there is a NAT device
   along the path fact that modifies the header information in packets or an
   adversary mounting an attack.  If this extension could be complicated and there
   was no clear need for it, a NAT is detected during the
   creation first version of an IKE 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 protocol will
   not provide this feature.

5.5.  Return routability test

   Changing the initial IKEv2 exchange or also during
   subsequent message exchanges.  If MOBIKE preferred address and subsequently using it for
   communication 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 is desirable
   to also support a scenario where a MOBIKE peer moves from a subnet
   that is not behind a NAT to a network 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. (reference?  Explanation?)

   Whether or not MOBIKE should support NAT traversal is one of the most
   important design decisions.

5.5  Changing addresses or changing the paths

   A design decision is whether it is enough for the MOBIKE protocol to
   detect dead addresses, or it also needs to detect dead paths.  Dead
   address detection refers to the ability to establish whether or not a
   given IP address pair is operational.  Dead path detection refers to
   the ability to establish whether or not all possible (local/remote)
   address pairs are operational (or at least find one such pair).

   While performing just one address change is simpler, the existence of
   locally operational addresses 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.

5.6  Return Routability Tests

   Changing the preferred address and subsequently using it for
   communication is associated 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 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 taking an authorization decision a malicious peer can
   redirect traffic towards a third party or a blackhole.

   A MOBIKE peer should not 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
   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 the
   remote peer then some of these addresses 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 perform a return routability test only when an
   address update needs to be sent from some 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 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 notification the authenticated peer
   may have provided an authenticated IP address.  Thus it is would be
   possible to simply trust the MOBIKE peer to provide a proper IP
   address.  There is no way an adversary can successfully launch an
   attack by injecting faked addresses since it does not know the IKE SA
   and the corresponding keying material.A material.  A protection against an
   internal attacker, i.e. the authenticated peer forwarding its traffic
   to the new 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 know the identity of the peer in that
   case.  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

   There is also a policy issue when to schedule a return routability
   test.  Before moving traffic?  After moving traffic?

   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 a different type of exchange is required and thereby avoiding
   modifications to the IKEv2 specification.

   There are potential attacks detection.  There are potential attacks if a return
   routability check does not include some kind of nonce.  The valid end
   point could send an address update notification for 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 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 a peer to move
   the traffic to a location where the original recipient cannot be
   reached.

   The IKEv2 NAT-T mechanism does not perform 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 an unmodified IP address reaches the other peer.  Mobility
   environments make this attack more difficult for an adversary since
   it requires the adversary to be located somewhere 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 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 mechanism it should protect against these attacks.

   There may be return routability information available from the other
   parts of the system too (as shown in Figure 3), but the checks done
   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 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, integrity and replay protected.

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

   The 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 payload,
   then the adversary cannot forward packets.  Thus 3rd party 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 a guarantee that there is a node at
   the IP address which replied to the request.  There is no indication
   as to whether or not the reply is fresh, and whether or not the
   request may have been transmitted from a different source address.

5.7

5.5.1.  Employing MOBIKE results in other protocols

   If MOBIKE has learned about new locations or verified the validity of
   a remote address through a return routability 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 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 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 potentially be useful for SCTP to learn about the
   new addresses at the same time as MOBIKE.  Similarly, various IP
   layer mechanisms may make use of the fact that a return routability
   test of a specific type has been performed.  However, care should be
   exercised in all these situations . situations.

   [I-D.crocker-celp] discusses the use of common locator information
   pools in a IPv6 multi-homing context; it assumed that both transport
   and IP layer solutions are be used in order to support multi-homing,
   and that it would be beneficial for different protocols to coordinate
   their results in some way, for instance by sharing throughput
   information of address pairs.  This may apply to MOBIKE as well,
   assuming it co-exists with non-IPsec protocols that are faced with
   the same 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 in the database entries that
   relate

5.5.2.  Suggested approach

   MOBIKE protocol selected to an IKE-SA.  However, changing use IKEv2 INFORMATIONAL exchanges as a
   return routability tests, but added random cookie there to prevent
   redirections done by authenticated attacker.  Return routability
   tests are done by default before moving the preferred address traffic.  However these
   tests are optional.  Nodes MAY also
   affects the entries of perform these tests upon their
   own initiative at other times.

   It is worth noting that the IPsec SA database. return routability test in MOBIKE is not
   he same as return routability test in MIP6: The outer tunnel
   header addresses (source and destination IP addresses) need to be
   modified according MIP6 WG decided that
   it is not necessary to do return routability tests between the primary path to allow mobile
   node and the home agent at all.

5.6.  IPsec protected
   data traffic to travel along the same path as the Tunnel or Transport Mode

   Current MOBIKE packets (if
   we design is focused only consider on the IP header information).  If VPN type usage and
   tunnel mode.  Transport mode behavior would also be useful, but will
   be discussed in future documents.

6.  Protocol detail issues

6.1.  Indicating support for mobike

   In order for MOBIKE to function, both peers must implement the MOBIKE messages
   extension of IKEv2.  If one or none of the peers supports MOBIKE,
   then, whenever an IP address changes, IKEv2 will have to be re-run in
   order to create a new IKE SA and the respective IPsec protected data traffic travel along SAs.  In
   MOBIKE, a different path
   then NAT handling is severely complicated.

   The basic question is then how the IPsec SAs are changed peer needs to use the
   new address pair (the same be confident that its address pair as the MOBIKE signaling
   traffic -- change messages
   are understood by the primary path).  One option other peer.  If these messages are not
   understood, it is possible that when connectivity between the IKE SA
   address peers is changed then automatically all IPsec SAs associated with
   it are moved along with it
   lost.

   One way to new address pair.  Another option ensure that a peer receives feedback on whether or not its
   messages are understood by the other peer, is by using IKEv2
   messaging for MOBIKE and to
   have a separate exchange mark some messages as "critical".
   According to move the IPsec SAs separately.

   If IPsec SAs should IKEv2 specification, such messages either have to be updated separately then a more efficient
   format than
   understood by the notification payload is needed receiver, or an error message has to preserve bandwidth.
   A notification payload can only store one SPI per payload. be returned to
   the sender.

   A
   separate payload which would have list second way to ensure receipt of IPsec SA SPIs and new
   preferred address.  If there the above-mentioned feedback is a large number of IPsec SAs, those by
   using Vendor ID payloads can be quite large unless ranges of SPI values that are
   supported.  If we automatically move all IPsec SAs when exchanged during the IKE SA
   moves, initial IKEv2
   exchange.  These payloads would then we only need to keep track which IKE SA was used to
   create the IPsec SA, indicate whether or not a given
   peer supports the MOBIKE protocol.

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

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

   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 SA address set a MOBIKE peer could also attempt to be updated separately,
   then we can support scenarios, where execute MOBIKE
   opportunistically with the machine critical bit set when an address change
   has fast and/or
   cheap connections and slow and/or expensive connections, and it wants
   to allow moving some occurred.  The drawback of this approach is, however, that an
   unnecessary message exchange is introduced.

   Although Vendor ID payloads and Notifications are technically
   equivalent, Notifications are already used in IKEv2 as a capability
   negotiation mechanism.  Hence, notification payloads are used in the SAs
   MOBIKE to indicate support of it.

   Also as the slower and/or more expensive
   connection, and prevent the move, for example, information of the news video
   stream from support of the WLAN to MOBIKE is not needed
   during the GPRS link.

   On IKE_SA_INIT exchange, the other hand, even if we tie indication of the IKE SA update to support is
   done inside the IPsec SA
   update, then we can create separate IKE SAs IKE_AUTH exchange.  The reason for this scenario, e.g.,
   we create one IKE SA which have both links is to need to
   keep the IKE_SA_INIT messages as endpoints, and it small as possible, so they do not
   get fragmented.  The idea is
   used for important traffic, that responder can do stateless
   processing of the first IKE_SA_INIT packet, and then we create another IKE SA which
   have only request cookie from
   the fast and/or cheap connection, which other end if it is then used for
   that kind under attack.  To mandate responder to be able
   to reassemble initial IKE_SA_INIT packets would not allow fully
   stateless processing of bulk traffic.

5.9  Zero Address Set

   One the initial IKE_SA_INIT packets.

6.2.  Path Testing and Window size

   As the IKEv2 has the window of outgoing messages, and the features which is potentially useful sender is for the peer
   not allowed to
   announce violate that window (meaning, that if the window is
   full, then he cannot send packets), it will now disconnect for do cause some time, i.e. it will not
   be reachable at all.  For instance, a laptop might go complications to suspend
   mode.  In this case
   the it could send address notification with zero
   new addresses, which means that it will not have any valid addresses
   anymore. path testing.  The responder of another complication created by IKEv2 is that kind of notification would then
   acknowledge that, and could then temporarily disable all SAs and
   therefore stop sending traffic.  If any of
   once the SAs gets any packets
   they are simply dropped.  This could also include some kind of ACK
   spoofing message is first time sent to keep the TCP/IP sessions alive (or simply set the TCP/IP
   keepalives and timeouts large enough not to cause problems), or other end, it
   could simply cannot be left
   modified in its future retransmissions.  This makes it impossible to
   know what packet actually reached first to the applications, e.g. allow TCP/IP sessions other end.  We cannot
   use IP headers to notice find out which packet reached the link is broken.

   The local policy could then indicate how long other end first,
   as if responder gets retransmissions of the peer should allow
   remote peers to remain disconnected.

   From a technical point packet it has already
   replied (and those replies might have been lost due unidirectional
   address pair), it will retransmit the previous reply using the new
   address pair of the request.  Because of view this feature addresses two aspects:

   o  There is no need to transmit IPsec data traffic.  IPsec protected
      data needs to it might be dropped which saves bandwidth.  This does not
      provide a functional benefit, i.e., nothing breaks possible
   that the responder has already used the IP-address information from
   the header of the packet, and the reply packet ending up to the
   initiator has different address pair.

   Another complication comes from the NAT-T.  The current IKEv2
   document says that if this feature NAT-T is enabled the node not provided.

   o  MOBIKE signaling messages are also ignored.  The IKE-SA must not
      be deleted behind NAT SHOULD
   detect if the IP-address changes in the incoming authenticated
   packets, and update the suspend functionality (realized remote peers addresses accordingly.  This
   works fine with the zero NAT-T, but it causes some complications in the
   MOBIKE, as it needs an ability to probe the another address set) may require pairs,
   without breaking the IKE-SA old one.

   One approach to fix those would be tagged with a lifetime
      value since to add completely new protocol
   that is outside the IKE-SA should not be kept in alive for an
      undefined period IKE SA message id limitations (window code),
   outside identical retransmission requirements, and outside the
   dynamic address updating of time.  Note the NAT-T.

   Another approach is to make the protocol so that IKEv2 it does not violate
   window restrictions and does not require that changing the IKE-SA has a lifetime associated with it.  In order packet is sent,
   and change the dynamic address updating of NAT-T to prevent MUST NOT in case
   MOBIKE is used.  To not to violate window restrictions, it means that
   the IKE-SA from being deleted addresses of the dead-peer detection mechanism currently ongoing exchange needs to be suspended as well.

   Due changed,
   to test different paths.  To not to require changing the fact that this extension would be complicated, a packet after
   it is first
   version of sent, requires that the MOBIKE protocol will needs to restart from
   the beginning in case packet was retransmitted to different addresses
   (so sender does not provide this feature.

5.10  IPsec Tunnel or Transport Mode

   Current know which packet was the one that responder got
   first, i.e. which IP-addresses it used).

   MOBIKE design is focused only on protocol decided to use normal IKEv2 exchanges for the VPN type usage path
   testing, and
   tunnel mode.  Transport mode behaviour would also be useful, but will
   be discussed in future documents.

5.11 decided to change the dynamic address updating of NAT-T
   to MUST NOT.

6.3.  Message Representation presentation

   The 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 incorporate the functionality already.

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

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

   There are two formats that place IP address 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.. 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 IKEv2
   payloads that are longer than a certain threshold, but if the sender
   sends them in the most preferred first, the receiver can only use the
   first 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.  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 decided to use IKEv2 NOTIFY payloads, and put only one data
   item per notify, i.e. there will be one NOTIFY payload for each item
   to be sent.

6.4.  Updating address list

   Because of the initiator decides, the initiator needs to know all the
   addresses used by the responder.  The responder needs also that list
   in case it happens move to the address unknown by the initiator, and
   needs to send address update notify to the initiator, and it might
   need to try different addresses for the initiator.

   MOBIKE could send the full peer address list once one every time any 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

   MOBIKE decided to communicate its peer address set use protocol format, where both ends can send full
   list of their addresses to the other peer.

6. end, and that list overwrites
   the previous list.  To support NAT-T the IP-addresses of the received
   packet is added to the list (and they are not present in the list).

7.  Security Considerations

   As all the messages are already authenticated by the IKEv2 there is
   no problem that any attackers would modify the 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, and
   that do not cause any direct actions.

   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.

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

7.

8.  IANA Considerations

   This document does not introduce any IANA considerations.

8.

9.  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, 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 corresponding countermeasures.

   o  Some text is 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
   http://www.vpnc.org/ietf-mobike/issues.html.

10.  References

10.1

10.1.  Normative references

   [I-D.ietf-ipsec-ikev2]
              Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              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-06 (work
              in progress), April 2005.

10.2

10.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), 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", 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", draft-ietf-mip6-ro-sec-03
              (work in progress), May 2005.

   [I-D.ietf-hip-mm]
              Nikander, P., "End-Host Mobility and Multi-Homing Multihoming with the
              Host Identity Protocol", draft-ietf-hip-mm-01 draft-ietf-hip-mm-02 (work in
              progress), February July 2005.

   [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.

   [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-12 (work in progress),
              June 2005.

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

   [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.

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

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

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

   [RFC2367]  McDonald, D., Metz, 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., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [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.

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.