doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc4621.txt b/doc/rfc/rfc4621.txt
new file mode 100644
index 0000000..f9b507b
--- /dev/null
+++ b/doc/rfc/rfc4621.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group                                         T. Kivinen
+Request for Comments: 4621                                 Safenet, Inc.
+Category: Informational                                    H. Tschofenig
+                                                                 Siemens
+                                                             August 2006
+
+
+     Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension
+   of 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kivinen & Tschofenig         Informational                      [Page 1]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................4
+   3. Scenarios .......................................................6
+      3.1. Mobility Scenario ..........................................6
+      3.2. Multihoming Scenario .......................................7
+      3.3. Multihomed Laptop Scenario .................................8
+   4. Scope of MOBIKE .................................................8
+   5. Design Considerations ..........................................10
+      5.1. Choosing Addresses ........................................10
+           5.1.1. Inputs and Triggers ................................11
+           5.1.2. Connectivity .......................................11
+           5.1.3. Discovering Connectivity ...........................12
+           5.1.4. Decision Making ....................................12
+           5.1.5. Suggested Approach .................................12
+      5.2. NAT Traversal (NAT-T) .....................................12
+           5.2.1. Background and Constraints .........................12
+           5.2.2. Fundamental Restrictions ...........................13
+           5.2.3. Moving behind a NAT and Back .......................13
+           5.2.4. Responder behind a NAT .............................14
+           5.2.5. NAT Prevention .....................................15
+           5.2.6. Suggested Approach .................................15
+      5.3. Scope of SA Changes .......................................15
+      5.4. Zero Address Set Functionality ............................16
+      5.5. Return Routability Check ..................................17
+           5.5.1. Employing MOBIKE Results in Other Protocols ........19
+           5.5.2. Return Routability Failures ........................20
+           5.5.3. Suggested Approach .................................21
+      5.6. IPsec Tunnel or Transport Mode ............................22
+   6. Protocol Details ...............................................22
+      6.1. Indicating Support for MOBIKE .............................22
+      6.2. Path Testing and Window size ..............................23
+      6.3. Message Presentation ......................................24
+      6.4. Updating Address Set ......................................25
+   7. Security Considerations ........................................26
+   8. Acknowledgements ...............................................26
+   9. References .....................................................27
+      9.1. Normative references ......................................27
+      9.2. Informative References ....................................27
+
+
+
+
+
+
+
+
+
+
+
+Kivinen & Tschofenig         Informational                      [Page 2]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+1.  Introduction
+
+   The purpose of IKEv2 is to mutually authenticate two hosts, to
+   establish one or more IPsec Security Associations (SAs) between them,
+   and subsequently to 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 host places this
+   single pair in the outer IP headers.  Existing IPsec documents make
+   no provision to change this pair after an IKE SA is created (except
+   for dynamic address update of Network Address Translation Traversal
+   (NAT-T)).
+
+   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 is a relatively expensive
+   operation, and it can be problematic when such changes are frequent.
+   Moreover, manual user interaction (for example, when using human-
+   operated token cards (SecurID)) might be required as part of the
+   IKEv2 authentication procedure.  Therefore, an automatic mechanism is
+   needed that updates the IP addresses associated with the IKE SA and
+   the IPsec SAs.  The MOBIKE protocol provides such a mechanism.
+
+   The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306].  As
+   IKEv2 is built on the IPsec architecture [RFC4301], all protocols
+   developed within the MOBIKE working group must be compatible with
+   both IKEv2 and the architecture described in RFC 4301.  This document
+   does not discuss mobility and multi-homing support for IKEv1
+   [RFC2409] or the obsoleted IPsec architecture described in RFC 2401
+   [RFC2401].
+
+   This document is structured as follows: After some important terms
+   are introduced in Section 2, a number of relevant usage scenarios are
+   discussed in Section 3.  Section 4 describes the scope of the MOBIKE
+   protocol.  Section 5 discusses design considerations affecting the
+   MOBIKE protocol.  Section 6 investigates details regarding the MOBIKE
+   protocol.  Finally, this document concludes in Section 7 with
+   security considerations.
+
+
+
+Kivinen & Tschofenig         Informational                      [Page 3]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+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, defined in [RFC4555].
+
+   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 [RFC4429].
+
+      *  If the address is an IPv6 address, it is a global unicast or
+         unique site-local address, as defined in [RFC4193].  That is,
+         it is not an IPv6 link-local address.
+
+      *  The address and interface is acceptable for sending and
+         receiving traffic according to a local policy.
+
+      This definition is taken from [WIP-Ark06] and adapted for the
+      MOBIKE context.
+
+   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 [WIP-Ark06].
+
+   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
+
+
+
+Kivinen & Tschofenig         Informational                      [Page 4]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+      endpoints.  This differentiation might be necessary to address
+      certain Network Address Translation types or specific firewalls.
+      This definition is taken from [WIP-Ark06] 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, due to load
+      balancing.  This definition is taken from [RFC2960] and adapted to
+      the MOBIKE context.
+
+   Current path
+
+      The sequence of routers traversed by an IP packet that carries the
+      default source and destination addresses is said to be the Current
+      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 [WIP-Nik06] 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.
+
+
+
+
+
+
+
+Kivinen & Tschofenig         Informational                      [Page 5]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   Bidirectional address pair
+
+      The address pair, where traffic can be sent to both directions,
+      simply by reversing the IP addresses.  Note that the path of the
+      packets going to each direction might be different.
+
+   Unidirectional address pair
+
+      The address pair, where traffic can only be sent in one direction,
+      and reversing the IP addresses and sending reply back does not
+      work.
+
+   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.  Mobility Scenario
+
+   Figure 1 shows a break-before-make mobility scenario where a mobile
+   node (MN) changes its point of network attachment.  Prior to the
+   change, the mobile node had established an IPsec connection with a
+   security gateway that offered, for example, access to a corporate
+   network.  The IKEv2 exchange that facilitated the setup 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 stateful or stateless address configuration.  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 of the above scenarios.
+
+
+
+
+
+
+
+
+Kivinen & Tschofenig         Informational                      [Page 6]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+                          (Initial IKEv2 Exchange)
+                    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
+       Old IP   +--+        +---+                    v
+       address  |MN|------> |OAR| -------------V     v
+                +--+        +---+ Old path     V     v
+                 .                          +----+   v>>>>> +--+
+                 .move                      | R  | -------> |GW|
+                 .                          |    |    >>>>> |  |
+                 v                          +----+   ^      +--+
+                +--+        +---+ New path     ^     ^
+       New IP   |MN|------> |NAR|--------------^     ^
+       address  +--+        +---+                    ^
+                    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
+                          (MOBIKE Address Update)
+
+              ---> = Path taken by data packets
+              >>>> = Signaling traffic (IKEv2 and MOBIKE)
+              ...> = End host movement
+
+                        Figure 1: Mobility Scenario
+
+3.2.  Multihoming Scenario
+
+   Another 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
+
+
+
+Kivinen & Tschofenig         Informational                      [Page 7]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   Note that MOBIKE does not aim to support load balancing between
+   multiple IP addresses.  That is, each peer uses only one of the
+   available address pairs at a given point in time.
+
+3.3.  Multihomed Laptop Scenario
+
+   The third scenario we consider is about a laptop that 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
+   General Packet Radio Service (GPRS) adaptor, a Bluetooth interface,
+   or USB hardware.  Not all interfaces are used for communication all
+   the time for a number of reasons (e.g., cost, network availability,
+   user convenience).  The policies that determine 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.
+
+   In all of these scenarios, 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.  Scope of MOBIKE
+
+   Getting mobility and multihoming actually working requires many
+   different components to work together, including coordinating
+   decisions between different layers, different mobility mechanisms,
+   and IPsec/IKEv2.  Most of those aspects are beyond the scope of
+   MOBIKE: MOBIKE focuses only on what two peers need in order to agree
+   at the IKEv2 level (like new message formats and some aspects of
+   their processing) required for interoperability.
+
+   The MOBIKE protocol is not trying to be a full mobility protocol;
+   there is no support for simultaneous movement or rendezvous
+   mechanism, and there is no support for route optimization, etc.  The
+   design document focuses on 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.  That is,
+   applications running inside the MOBIKE-controlled IPsec tunnel might
+   not detect the movement since their IP addresses remain constant.
+
+
+
+
+
+
+
+
+Kivinen & Tschofenig         Informational                      [Page 8]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   The MOBIKE protocol should be able to perform the following
+   operations (not all of which are done explicitly by the current
+   protocol):
+
+   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 detect an outage
+      situation
+
+   o  Change the preferred address
+
+   o  Change the peer address set
+
+   o  Ability to deal with Network Address Translation devices
+
+   Figure 3 shows an example protocol interaction between a pair of
+   MOBIKE peers.  MOBIKE interacts with the packet processing module of
+   the IPsec implementation using an internal API (such as those based
+   on PF_KEY [RFC2367]).  Using this API, the MOBIKE module can create
+   entries in the Security Association (SAD) and Security Policy
+   Databases (SPD).  The packet processing module of the IPsec
+   implementation may also interact with IKEv2 and MOBIKE module 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 the other hand, receives information
+   from a number of sources that may run both in kernel-mode and in
+   user-mode.  These sources form the basis on which MOBIKE makes
+   decisions regarding the set of available addresses, the peer address
+   set, and the preferred address.  Policies may also affect the
+   selection process.
+
+   The peer address set and the preferred address needs to be made
+   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 current path.
+   This is because this pair is selected for sending and receiving
+   MOBIKE signaling and IPsec traffic.  If a problem along this current
+   path is detected (e.g., due to a router failure), it is necessary to
+   switch to a new current 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 identify previously
+   disconnected paths that become operational again.
+
+
+
+
+
+Kivinen & Tschofenig         Informational                      [Page 9]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+     +---------------------+            +----------------+
+     |    User-space       |            |                |
+     |   Protocols and     |            |   MOBIKE and   |
+     | Functions Relevant  |<---------->|  IKEv2 Module  |
+     | MOBIKE (e.g., DHCP, |            |                |
+     |     policies)       |            +----------------+
+     +---------------------+                    ^
+                ^                               |
+                |                               |        User space
+     ++++++++++API++++++++++++++++++++++++++++PF_KEY+++++++++++++++
+                |                               |      Kernel space
+                |                               v
+                |                       +----------------+
+                v                       |                |
+     +---------------------+            |  IPsec engine  |
+     |   Kernel-space      |<---------->| (and databases)|
+     |     Protocols       |            |                |
+     |    Relevant for     |            +----------------+
+     |  MOBIKE (e.g., ND,  |                    ^
+     |     DNA, L2)        |<---------------+   |
+     +---------------------+                v   v
+            ||                          +----------------+
+            \/                          |                |
+          Inter-  =====================>| IP forwarding, |
+          faces   <=====================|input and output|
+                                        |                |
+                                        +----------------+
+
+         ===> = 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.  It serves illustrative purposes only.
+
+5.  Design Considerations
+
+   This section discusses aspects affecting the design of the MOBIKE
+   protocol.
+
+5.1.  Choosing Addresses
+
+   One of the core aspects of the MOBIKE protocol is the selection of
+   the address for the IPsec packets we send.  Choosing addresses for
+   the IKEv2 request is a somewhat separate problem.  In many cases,
+   they will be the same (and in some design choice they will always be
+   the same and could be forced to be the same by design).
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 10]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+5.1.1.  Inputs and Triggers
+
+   How address changes are triggered is largely beyond the scope of
+   MOBIKE.  The triggers can include changes in the set of addresses,
+   various link-layer indications, failing dead peer detection, and
+   changes in preferences and policies.  Furthermore, there may be less
+   reliable sources of information (such as lack of IPsec packets and
+   incoming ICMP packets) that do not trigger any changes directly, but
+   rather cause Dead Peer Detection (DPD) to be scheduled earlier and,
+   if it fails, it might cause a change of the preferred address.
+
+   These triggers are largely the same as for other mobility protocols
+   such as Mobile IP, and they are beyond the scope of MOBIKE.
+
+5.1.2.  Connectivity
+
+   There can be two kinds of connectivity "failures": local failures and
+   path failures.  Local failures are problems locally at a MOBIKE peer
+   (e.g., an interface error).  Path failures are a property of an
+   address pair and failures of nodes and links along this path.  MOBIKE
+   does not support unidirectional address pairs.  Supporting them would
+   require abandoning the principle of sending an IKEv2 reply to the
+   address from which the request came.  MOBIKE decided to deal only
+   with bidirectional address pairs.  It does consider unidirectional
+   address pairs as broken and does not use them, but the connection
+   between peers will not break even if unidirectional address pairs are
+   present, provided there is at least one bidirectional address pair
+   MOBIKE can use.
+
+   Note that MOBIKE is not concerned about the actual path used; it
+   cannot even detect if some path is unidirectionally operational if
+   the same address pair has some other unidirectional path back.
+   Ingress filters might still cause such path pairs to be unusable, and
+   in that case MOBIKE will detect that there is no operational address
+   pair.
+
+   In a sense having both an IPv4 and an IPv6 address is basically a
+   case of partial connectivity (putting both an IPv4 and an IPv6
+   address in the same IP header does not work).  The main difference is
+   that it is known beforehand; there is no need to discover that an
+   IPv4/IPv6 combination does not work.
+
+
+
+
+
+
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 11]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+5.1.3.  Discovering Connectivity
+
+   To detect connectivity, the MOBIKE protocol needs to have a mechanism
+   to test connectivity.  If a MOBIKE peer receives a reply, it can be
+   sure about the existence of a working (bidirectional) address pair.
+   If a MOBIKE peer does not see a reply after multiple retransmissions,
+   it may assume that the tested address pair is broken.
+
+   The connectivity tests require congestion problems to be taken into
+   account because the connection failure might be caused by congestion.
+   The MOBIKE protocol should not make the congestion problem worse by
+   sending many DPD packets.
+
+5.1.4.  Decision Making
+
+   One of the main questions in designing the MOBIKE protocol was who
+   makes the decisions how to fix a situation when failure is detected,
+   e.g., symmetry vs. asymmetry in decision making.  Symmetric decision
+   making (i.e., both peers can make decisions) may cause the different
+   peers to make different decisions, thus causing asymmetric upstream/
+   downstream traffic.  In the mobility case, it is desirable that the
+   mobile peer can move both upstream and downstream traffic to some
+   particular interface, and this requires asymmetric decision making
+   (i.e. only one peer makes decisions).
+
+   Working with stateful packet filters and NATs is easier if the same
+   address pair is used in both upstream and downstream directions.
+   Also, in common cases, only the peer behind NAT can actually perform
+   actions to recover from the connectivity problems, as the other peer
+   might not be able to initiate any connections to the peer behind NAT.
+
+5.1.5.  Suggested Approach
+
+   The working group decided to select a method whereby the initiator
+   will decide which addresses are used.  As a consequence, the outcome
+   is always the same for both parties.  It also works best with NATs,
+   as the initiator is most likely the node that is located behind a
+   NAT.
+
+5.2.  NAT Traversal (NAT-T)
+
+5.2.1.  Background and Constraints
+
+   Another core aspect of MOBIKE is the treatment of different NATs and
+   Network Address Port Translations (NAPTs).  In IKEv2 the tunnel
+   header IP addresses are not sent inside the IKEv2 payloads, and thus
+   there is no need to do unilateral self-address fixing (UNSAF
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 12]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   [RFC3424]).  The tunnel header IP addresses are taken from the outer
+   IP header of the IKE packets; thus, they are already processed by the
+   NAT.
+
+   The NAT detection payloads are used to determine whether the
+   addresses in the IP header were modified by a NAT along the path.
+   Detecting a NAT typically requires UDP encapsulation of IPsec ESP
+   packets to be enabled, if desired.  MOBIKE is not to change how IKEv2
+   NAT-T works in particular, any kind of UNSAF or explicit interaction
+   with NATs (e.g., MIDCOM [RFC3303] or NSIS NATFW NSLP [WIP-Sti06]) is
+   beyond the scope of the MOBIKE protocol.  The MOBIKE protocol will
+   need to define how MOBIKE and NAT-T are used together.
+
+   The NAT-T support should also be optional.  If the IKEv2
+   implementation does not implement NAT-T, as it is not required in
+   some particular environment, implementing MOBIKE should not require
+   adding support for NAT-T either.
+
+   The property of being behind NAT is actually a property of the
+   address pair and thereby of the path taken by a packet.  Thus, one
+   peer can have multiple IP addresses, and some of those might be
+   behind NAT and some might not.
+
+5.2.2.  Fundamental Restrictions
+
+   There are some cases that cannot be carried out within MOBIKE.  One
+   of those cases is when the party "outside" a symmetric NAT changes
+   its address to something not known by the other peer (and the old
+   address has stopped working).  It cannot send a packet containing the
+   new addresses to the peer because the NAT does not contain the
+   necessary state.  Furthermore, since the party behind the NAT does
+   not know the new IP address, it cannot cause the NAT state to be
+   created.
+
+   This case could be solved using some rendezvous mechanism outside
+   IKEv2, but that is beyond the scope of MOBIKE.
+
+5.2.3.  Moving behind a NAT and Back
+
+   The MOBIKE protocol should provide a mechanism whereby a peer that is
+   initially not behind a NAT can move behind NAT when a new preferred
+   address is selected.  The same effect might be accomplished with the
+   change of the address pair if more than one path is available (e.g.,
+   in the case of a multi-homed host).  An impact for the MOBIKE
+   protocol is only caused when the currently selected address pair
+   causes MOBIKE packets to traverse a NAT.
+
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 13]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   Similarly, the MOBIKE protocol provides a mechanism to detect when a
+   NATed path is changed to a non-NATed path with the change of the
+   address pair.
+
+   As we only use one address pair at time, effectively the MOBIKE peer
+   is either behind NAT or not behind NAT, but each address change can
+   change this situation.  Because of this, and because the initiator
+   always chooses the addresses, it is enough to send keepalive packets
+   only to that one address pair.
+
+   Enabling NAT-T involves a few different things.  One is to enable the
+   UDP encapsulation of ESP packets.  Another is to change the IKE SA
+   ports from port 500 to port 4500.  We do not want to do unnecessary
+   UDP encapsulation unless there is really a NAT between peers, i.e.,
+   UDP encapsulation should only be enabled when we actually detect NAT.
+   On the other hand, as all implementations supporting NAT-T must be
+   able to respond to port 4500 all the time, it is simpler from the
+   protocol point of view to change the port numbers from 500 to 4500
+   immediately upon detecting that the other end supports NAT-T.  This
+   way it is not necessary to change ports after we later detected NAT,
+   which would have caused complications to the protocol.
+
+   If we changed the port only after we detected NAT, then the responder
+   would not be able to use the IKE and IPsec SAs immediately after
+   their address is changed to be behind NAT.  Instead, it would need to
+   wait for the next packet from the initiator to see what IP and port
+   numbers are used after the initiator changed its port from 500 to
+   4500.  The responder would also not be able to send anything to the
+   initiator before the initiator sent something to the responder.  If
+   we do the port number changing immediately after the IKE_SA_INIT and
+   before IKE_AUTH phase, then we get the rid of this problem.
+
+5.2.4.  Responder behind a NAT
+
+   MOBIKE can work in cases where the responder is behind a static NAT,
+   but the initiator would need to know all the possible addresses to
+   which the responder can move.  That is, the responder cannot move to
+   an address which is not known by the initiator, in case initiator
+   also moves behind NAT.
+
+   If the responder is behind a NAPT, then it might need to communicate
+   with the NAT to create a mapping so the initiator can connect to it.
+   Those external firewall pinhole opening mechanisms are beyond the
+   scope of MOBIKE.
+
+   In case the responder is behind NAPT, then finding the port numbers
+   used by the responder is outside the scope of MOBIKE.
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 14]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+5.2.5.  NAT Prevention
+
+   One new feature created by MOBIKE is NAT prevention.  If we detect
+   NAT between the peers, we do not allow that address pair to be used.
+   This can be used to protect IP addresses in cases where the
+   configuration knows that there is no NAT between the nodes (for
+   example IPv6, or fixed site-to-site VPN).  This avoids any
+   possibility of on-path attackers modifying addresses in headers.
+   This feature means that we authenticate the IP address and detect if
+   they were changed.  As this is done on purpose to break the
+   connectivity if NAT is detected, and decided by the configuration,
+   there is no need to do UNSAF processing.
+
+5.2.6.  Suggested Approach
+
+   The working group decided that MOBIKE uses NAT-T mechanisms from the
+   IKEv2 protocol as much as possible, but decided to change the dynamic
+   address update (see [RFC4306], Section 2.23, second to last
+   paragraph) for IKEv2 packets to "MUST NOT" (it would break path
+   testing using IKEv2 packets; see Section 6.2).  The working group
+   also decided only to send keepalives to the current address pair.
+
+5.3.  Scope of SA Changes
+
+   Most sections of this document discuss design considerations for
+   updating and maintaining addresses in the database entries that
+   relate to an IKE SA.  However, changing the preferred address also
+   affects the entries of the IPsec SA database.  The outer tunnel
+   header addresses (source and destination IP addresses) need to be
+   modified according to the current path to allow the IPsec protected
+   data traffic to travel along the same path as the MOBIKE packets.  If
+   the MOBIKE messages and the IPsec protected data traffic travel along
+   a different path, then NAT handling is severely complicated.
+
+   The basic question is then how the IPsec SAs are changed to use the
+   new address pair (the same address pair as the MOBIKE signaling
+   traffic).  One option is that when the IKE SA address is changed, all
+   IPsec SAs associated with it are automatically moved along with it to
+   a new address pair.  Another option is to have a separate exchange to
+   move the IPsec SAs separately.
+
+   If IPsec SAs should be updated separately, then a more efficient
+   format than the Notify payload is needed to preserve bandwidth.  A
+   Notify payload can only store one Security Parameter Index (SPI) per
+   payload.  A separate payload could have a list of IPsec SA SPIs and
+   the new preferred address.  If there is a large number of IPsec SAs,
+   those payloads can be quite large unless list of ranges of SPI values
+   are supported.  If we automatically move all IPsec SAs when the IKE
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 15]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   SA moves, then we only need to keep track of which IKE SA was used to
+   create the IPsec SA, and fetch the IP addresses from the IKE SA,
+   i.e., there is no need to store IP addresses per IPsec SA.  Note that
+   IKEv2 [RFC4306] already requires the implementations to keep track of
+   which IPsec SAs are created using which IKE SA.
+
+   If we do allow the address set of each IPsec SA to be updated
+   separately, then we can support scenarios where the machine has fast
+   and/or cheap connections and slow and/or expensive connections and
+   wants to allow moving some of the SAs to the slower and/or more
+   expensive connection, and prevent the move, for example, of the news
+   video stream from the WLAN to the GPRS link.
+
+   On the other hand, even if we tie the IKE SA update to the IPsec SA
+   update, we can create separate IKE SAs for this scenario.  For
+   example, we create one IKE SA that has both links as endpoints, and
+   it is used for important traffic; then we create another IKE SA which
+   has only the fast and/or cheap connection, which is used for that
+   kind of bulk traffic.
+
+   The working group decided to move all IPsec SAs implicitly when the
+   IKE SA address pair changes.  If more granular handling of the IPsec
+   SA is required, then multiple IKE SAs can be created one for each set
+   of IPsec SAs needed.
+
+5.4.  Zero Address Set Functionality
+
+   One of the features that is potentially useful is for the peer to
+   announce that it will now disconnect for some time, i.e., it will not
+   be reachable at all.  For instance, a laptop might go to suspend
+   mode.  In this case, it could send address notification with zero new
+   addresses, which would mean that it will not have any valid addresses
+   anymore.  The responder would then acknowledge that notification and
+   could then temporarily disable all SAs and therefore stop sending
+   traffic.  If any of the SAs get any packets, they are simply dropped.
+   This could also include some kind of ACK spoofing to keep the TCP/IP
+   sessions alive (or simply setting the TCP/IP keepalives and timeouts
+   large enough not to cause problems), or it could simply be left to
+   the applications, e.g., allow TCP/IP sessions to notice if the link
+   is broken.
+
+   The local policy could then indicate how long the peer should allow
+   remote peers to remain disconnected.
+
+   From a technical point of view, this would provide following two
+   features:
+
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 16]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   o  There is no need to transmit IPsec data traffic.  IPsec-protected
+      data can 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.  The IKE SA must not
+      be deleted, and the suspend functionality (realized with the zero
+      address set) may require the IKE SA to be tagged with a lifetime
+      value since the IKE SA should not be kept alive for an undefined
+      period of time.  Note that IKEv2 does not require that the IKE SA
+      has a lifetime associated with it.  In order to prevent the IKE SA
+      from being deleted, the dead-peer detection mechanism needs to be
+      suspended as well.
+
+   Due to its complexity and no clear requirement for it, it was decided
+   that MOBIKE does not support this feature.
+
+5.5.  Return Routability Check
+
+   Changing the preferred address and subsequently using it for
+   communication is associated with an authorization decision: Is a peer
+   allowed to use this address?  Does this peer own this address?  Two
+   mechanisms have been proposed in the past to allow a peer to
+   determine the answer to these questions:
+
+   o  The addresses a peer is using are part of a certificate.
+      [RFC3554] introduced 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 appearing 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 to provide a certain degree of
+      confidence to the remote peer that the 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 black hole.
+
+   A MOBIKE peer should not use an IP address provided by another MOBIKE
+   peer as a current address without computing the authorization
+   decision.  If the addresses are part of the certificate, then it is
+   not necessary to execute the return routability check.  The return
+   routability check is a form of authorization check, although it
+   provides weaker guarantees than the inclusion of the IP address as a
+   part of a certificate.  If multiple addresses are communicated to the
+   remote peer, then some of these addresses may be already verified.
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 17]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   Finally, it would be possible not to execute return routability
+   checks at all.  In case of indirect change notifications (i.e.,
+   something we notice from the network, not from the peer directly), 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
+   (i.e., notification from the other end directly) the authenticated
+   peer may have provided an authenticated IP address (i.e., inside IKE
+   encrypted and authenticated payload; see Section 5.2.5).  Thus, it is
+   would be possible simply to trust the MOBIKE peer to provide a proper
+   IP address.  In this case, a protection against an internal attacker
+   (i.e., the authenticated peer forwarding its traffic to the new
+   address) would not provided.  On the other hand, we know the identity
+   of the peer in that case.  There might be problems when extensions
+   are added to IKEv2 that do not require authentication of end points
+   (e.g., opportunistic security using anonymous Diffie-Hellman).
+
+   There is also a policy issue of when to schedule a return routability
+   check.  Before moving traffic?  After moving traffic?
+
+   The basic format of the return routability check could be similar to
+   dead-peer detection, but potential attacks are possible if a return
+   routability check does not include some kind of a nonce.  In these
+   attacks, 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 check does not contain any nonce or other random
+   information not known to the other peer, then the other peer 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 which response packets are to be sent.
+   An adversary can change those IP addresses and can cause the response
+   packets to be sent to a 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 the attack requires the adversary to be located
+   somewhere on the individual paths ({CoA1, ..., CoAn} towards the
+   destination IP address), to have a shared path, or, if the adversary
+   is located near the MOBIKE client, 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 a third
+
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 18]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   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.  This is the basic form of
+      return routability check.
+
+   o  There is an answer from the tested address, and that answer was
+      authenticated and integrity- and replay-protected.
+
+   o  There was an authenticated and 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 third-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, third-party
+   bombings are prevented (see Section 5.2.5).
+
+   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 third-
+   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 that replied to the request.  There is no indication
+   as to whether or not the reply is fresh or whether or not the request
+   may have been transmitted from a different source address.
+
+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?
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 19]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   When the basic MOBIKE VPN scenario is considered, 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 dynamic address
+   reconfiguration [WIP-Ste06] 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 check of a specific type
+   has been performed.  However, care should be exercised in all these
+   situations.
+
+   [WIP-Cro04] discusses the use of common locator information pools in
+   a IPv6 multi-homing context; it assumes that both transport and IP-
+   layer solutions are 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
+   coexists with non-IPsec protocols that are faced with the same or
+   similar multi-homing choices.
+
+   Nevertheless, all of this is outside the scope of the current MOBIKE
+   base protocol design and may be addressed in future work.
+
+5.5.2.  Return Routability Failures
+
+   If the return routability check fails, we need to tear down the IKE
+   SA if we are using IKEv2 INFORMATIONAL exchanges to send return
+   routability checks.  On the other hand, return routability checks can
+   only fail permanently if there was an attack by the other end; thus,
+   tearing down the IKE SA is a suitable action in that case.
+
+   There are some cases, where the return routability check temporarily
+   fails, that need to be considered here.  In the first case, there is
+   no attacker, but the selected address pair stops working immediately
+   after the address update, before the return routability check.
+
+   What happens is that the initiator performs the normal address
+   update; it succeeds, and then the responder starts a return
+   routability check.  If the address pair has broken down before that,
+   the responder will never get back the reply to the return routability
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 20]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   check.  The responder might still be using the old IP address pair,
+   which could still work.
+
+   The initiator might be still seeing traffic from the responder, but
+   using the old address pair.  The initiator should detect that this
+   traffic is not using the latest address pair, and after a while it
+   should start dead peer detection on the current address pair.  If
+   that fails, then it should find a new working address pair and update
+   addresses to that.  The responder should notice that the address pair
+   was updated after the return routability check was started and change
+   the ongoing return routability check to use the new address pair.
+   The result of that return routability check needs to be discarded as
+   it cannot be trusted; the packets were retransmitted to a different
+   IP address.  So normally the responder starts a new return
+   routability check afterward with the new address pair.
+
+   The second case is where there is an attacker along the path
+   modifying the IP addresses.  The peers will detect this as NAT and
+   will enable NAT-T recovery of changes in the NAT mappings.  If the
+   attacker is along the path long enough for the return routability
+   check to succeed, then the normal recovery of changes in the NAT
+   mappings will take care of the problem.  If the attacker disappears
+   before return routability check is finished, but after the update, we
+   have a case similar to the last.  The only difference is that now the
+   dead peer detection started by the initiator will succeed because the
+   responder will reply to the addresses in the headers, not the current
+   address pair.  The initiator will then detect that the NAT mappings
+   are changed, and it will fix the situation by doing an address
+   update.
+
+   The important thing for both of these cases is that the initiator
+   needs to see that the responder is both alive and synchronized with
+   initiator address pair updates.  That is, it is not enough that the
+   responder is sending traffic to an initiator; it must also be using
+   the correct IP addresses before the initiator can believe it is alive
+   and synchronized.  From the implementation point of view, this means
+   that the initiator must not consider packets having wrong IP
+   addresses as packets that prove the other end is alive, i.e., they do
+   not reset the dead peer detection timers.
+
+5.5.3.  Suggested Approach
+
+   The working group selected to use IKEv2 INFORMATIONAL exchanges as a
+   return routability check, but included a random cookie to prevent
+   redirection by an authenticated attacker.  Return routability checks
+   are performed by default before moving the traffic.  However, these
+   tests are optional.  Nodes may also perform these tests upon their
+   own initiative at other times.
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 21]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   It is worth noting that the return routability check in MOBIKE is
+   different from Mobile IPv6 [RFC3775], which does not perform return
+   routability operations between the mobile node and its home agent at
+   all.
+
+5.6.  IPsec Tunnel or Transport Mode
+
+   The current MOBIKE design is focused only on the VPN type usage and
+   tunnel mode.  Transport mode behavior would also be useful and might
+   be discussed in future documents.
+
+6.  Protocol Details
+
+6.1.  Indicating Support for MOBIKE
+
+   In order for MOBIKE to function, both peers must implement the MOBIKE
+   extension of IKEv2.  If one of the peers does not support 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 SAs.  In
+   MOBIKE, a peer needs to be confident that its address change messages
+   are understood by the other peer.  If these messages are not
+   understood, it is possible that connectivity between the peers is
+   lost.
+
+   One way to ensure that a peer receives feedback on whether its
+   messages are understood by the other peer is to use IKEv2 messaging
+   for MOBIKE and to mark some messages as "critical".  According to the
+   IKEv2 specification, either such messages have to be understood by
+   the receiver, or an error message has to be returned to the sender.
+
+   A second way to ensure receipt of the above-mentioned feedback is 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 use the Notify payload to indicate support of
+   MOBIKE extension.  Such Notify payloads are also used for indicating
+   NAT traversal support (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 that a MOBIKE peer could also attempt to execute MOBIKE
+   opportunistically with the critical bit set when an address change
+   has occurred.  The drawback of this approach is, however, that an
+   unnecessary message exchange is introduced.
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 22]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   Although Vendor ID payloads and Notify payloads are technically
+   equivalent, Notify payloads are already used in IKEv2 as a capability
+   negotiation mechanism.  Hence, Notify payloads are used in MOBIKE to
+   indicate support of MOBIKE protocol.
+
+   Also, as the information of the support of MOBIKE is not needed
+   during the IKE_SA_INIT exchange, the indication of the support is
+   done inside the IKE_AUTH exchange.  The reason for this is the need
+   to keep the IKE_SA_INIT messages as small as possible so that they do
+   not get fragmented.  IKEv2 allows that the responder can do stateless
+   processing of the first IKE_SA_INIT packet and request a cookie from
+   the other end if it is under attack.  To mandate the responder to be
+   able to reassemble initial IKE_SA_INIT packets would not allow fully
+   stateless processing of the initial IKE_SA_INIT packets.
+
+6.2.  Path Testing and Window size
+
+   As IKEv2 has a window of outgoing messages, and the sender is not
+   allowed to violate that window (meaning that if the window is full,
+   then the sender cannot send packets), it can cause some complications
+   to path testing.  Another complication created by IKEv2 is that once
+   the message is created and sent to the other end, it cannot be
+   modified in its future retransmissions.  This makes it impossible to
+   know what packet actually reached the other end first.  We cannot use
+   IP headers to find out which packet reached the other end first
+   because if the responder gets retransmissions of the packet it has
+   already processed and replied to (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
+   this, it might be possible that the responder has already used the IP
+   address information from the header of the previous packet, and the
+   reply packet ending up at the initiator has a different address pair.
+
+   Another complication comes from NAT-T.  The current IKEv2 document
+   says that if NAT-T is enabled, the node not behind NAT SHOULD detect
+   if the IP address changes in the incoming authenticated packets and
+   update the remote peers' addresses accordingly.  This works fine with
+   NAT-T, but it causes some complications in MOBIKE, as MOBIKE needs
+   the ability to probe other address pairs without breaking the old
+   one.
+
+   One approach to fix this would be to add a completely new protocol
+   that is outside the IKE SA message id limitations (window code),
+   outside identical retransmission requirements, and outside the
+   dynamic address updating of NAT-T.
+
+
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 23]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   Another approach is to make the protocol so that it does not violate
+   window restrictions and does not require changing the packet on
+   retransmissions, and change the dynamic address updating of NAT-T to
+   "MUST NOT" for IKE SA packets if MOBIKE is used.  In order not to
+   violate window restrictions, the addresses of the currently ongoing
+   exchange need to be changed to test different paths.  In order not to
+   require that the packet be changed after it is first sent requires
+   that the protocol restart from the beginning in case the packet was
+   retransmitted to different addresses (because the sender does not
+   know which packet the responder got first, i.e., which IP addresses
+   it used).
+
+   The working group decided to use normal IKEv2 exchanges for path
+   testing and decided to change the dynamic address updating of NAT-T
+   to MUST NOT for IKE SA packets; a new protocol outside of IKEv2 was
+   not adopted.
+
+6.3.  Message Presentation
+
+   The IP address change notifications can be sent either via an
+   informational exchange already specified in IKEv2, or via a MOBIKE-
+   specific message exchange.  Using an informational exchange has the
+   main advantage that it is already specified in the IKEv2 protocol and
+   implementations can already incorporate the functionality.
+
+   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 could simply be an ordered list of IP addresses.  If using
+   preference numbers, then two addresses can have the same preference
+   value; an ordered list avoids this situation.
+
+   Load balancing is currently outside the scope of MOBIKE; however,
+   future work might include support for it.  The selected format needs
+   to be flexible enough to include additional information in future
+   versions of the protocol (e.g., to enable load balancing).  This may
+   be realized with an reserved field, which can later be used to store
+   additional information.  As other information may arise that 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 basic formats that place IP address lists into a
+   message.  One includes each IP address as separate payload (where the
+   payload order indicates the preference order, or the payload itself
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 24]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   might include the preference number).  Alternatively, we can put the
+   IP address list as one payload to the exchange, and that one payload
+   will then have an internal format that includes the list of IP
+   addresses.
+
+   Having multiple payloads, each one carrying one IP address, makes the
+   protocol probably easier to parse, as we can already use the normal
+   IKEv2 payload parsing 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.  As each payload already has a length field
+   associated to it, we can detect if there is any extra data after the
+   IP address.  Some implementations might have problems parsing more
+   than a certain number of IKEv2 payloads, but if the sender sends them
+   in the most preferred first, the receiver can only use the first
+   addresses it was willing to parse.
+
+   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.
+
+   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 notification data field, which could include the
+   MOBIKE-specific data.
+
+   Another option would be to have a custom payload type, which would
+   then include the information needed for the MOBIKE protocol.
+
+   The working group decided to use IKEv2 Notify payloads, and put only
+   one data item per notify.  There will be one Notify payload for each
+   item to be sent.
+
+6.4.  Updating Address Set
+
+   Because the initiator decides all address updates, the initiator
+   needs to know all the addresses used by the responder.  The responder
+   also needs that list in case it happens to move to an address not
+   known by the initiator, and it needs to send an address update
+   notification to the initiator.  It might need to try different
+   addresses for the initiator.
+
+   MOBIKE could send the whole peer address list every time any of the
+   IP addresses change (addresses are added or 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
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 25]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   this approach has more problems in the synchronization and packet
+   reordering cases.  That is, 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 a message ID that is incremented for each packet; thus,
+   it is easy to know the sending order).
+
+   The working group decided to use a protocol format where both ends
+   send a full list of their addresses to the other end, and that list
+   overwrites the previous list.  To support NAT-T, the IP addresses of
+   the received packet are considered as one address of the peer, even
+   when they are not present in the list.
+
+7.  Security Considerations
+
+   As all the packets are already authenticated by IKEv2, there is no
+   risk that any attackers would undetectedly 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 they do not cause any direct actions, except when doing NAT
+   traversal.
+
+   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 bombing attack type.  See [RFC4225] and [Aur02] for
+   more information about flooding attacks.
+
+   See the security considerations section of [RFC4555] for more
+   information about security considerations of the actual protocol.
+
+8.  Acknowledgements
+
+   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 make good progress
+   on the document.
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 26]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+9.  References
+
+9.1.  Normative references
+
+   [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
+                Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4306]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+                RFC 4306, December 2005.
+
+9.2.  Informative References
+
+   [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.
+
+   [RFC2367]    McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
+                Management API, Version 2", RFC 2367, July 1998.
+
+   [RFC2401]    Kent, S. and R. Atkinson, "Security Architecture for the
+                Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2409]    Harkins, D. and D. Carrel, "The Internet Key Exchange
+                (IKE)", RFC 2409, November 1998.
+
+   [RFC2461]    Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+                Discovery for IP Version 6 (IPv6)", RFC 2461,
+                December 1998.
+
+   [RFC2462]    Thomson, S. and T. Narten, "IPv6 Stateless Address
+                Autoconfiguration", RFC 2462, December 1998.
+
+   [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.
+
+   [RFC3303]    Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
+                and A. Rayhan, "Middlebox communication architecture and
+                framework", RFC 3303, August 2002.
+
+   [RFC3424]    Daigle, L. and IAB, "IAB Considerations for UNilateral
+                Self-Address Fixing (UNSAF) Across Network Address
+                Translation", RFC 3424, November 2002.
+
+
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 27]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+   [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.
+
+   [RFC3753]    Manner, J. and M. Kojo, "Mobility Related Terminology",
+                RFC 3753, June 2004.
+
+   [RFC3775]    Johnson, D., Perkins, C., and J. Arkko, "Mobility
+                Support in IPv6", RFC 3775, June 2004.
+
+   [RFC4193]    Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+                Addresses", RFC 4193, October 2005.
+
+   [RFC4225]    Nikander, P., Arkko, J., Aura, T., Montenegro, G., and
+                E. Nordmark, "Mobile IP Version 6 Route Optimization
+                Security Design Background", RFC 4225, December 2005.
+
+   [RFC4429]    Moore, N., "Optimistic Duplicate Address Detection (DAD)
+                for IPv6", RFC 4429, April 2006.
+
+   [RFC4555]    Eronen, P., "IKEv2 Mobility and Multihoming Protocol
+                (MOBIKE)", RFC 4555, June 2006.
+
+   [WIP-Ark06]  Arkko, J. and I. Beijnum, "Failure Detection and Locator
+                Pair Exploration Protocol for IPv6 Multihoming", Work in
+                Progress, June 2006.
+
+   [WIP-Cro04]  Crocker, D., "Framework for Common Endpoint Locator
+                Pools", Work in Progress, February 2004.
+
+   [WIP-Nik06]  Nikander, P., "End-Host Mobility and Multihoming with
+                the Host Identity Protocol", Work in Progress,
+                June 2006.
+
+   [WIP-Ste06]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+                Conrad, "Stream Control Transmission Protocol (SCTP)
+                Dynamic Address Reconfiguration", Work in Progress,
+                June 2006.
+
+   [WIP-Sti06]  Stiemerling, M., Tschofenig, H., Aoun, C., and E.
+                Davies, "NAT/Firewall NSIS Signaling Layer Protocol
+                (NSLP)", Work in Progress, June 2006.
+
+
+
+
+
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 28]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+Authors' Addresses
+
+   Tero Kivinen
+   Safenet, Inc.
+   Fredrikinkatu 47
+   HELSINKI  FI-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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 29]
+
+RFC 4621             Design of the MOBIKE Protocol           August 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   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.
+
+   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.
+
+Intellectual Property
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Kivinen & Tschofenig         Informational                     [Page 30]
+