[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-mobike-protocol

Network Working Group                                          P. Eronen
Internet-Draft                                                     Nokia
Expires: August 22, 2005                               February 21, 2005


             Mobility Protocol Options for IKEv2 (MOPO-IKE)
                    draft-eronen-mobike-mopo-02.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 22, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a mobility and multihoming extension to the
   IKEv2 protocol.  The main purpose of this extension is to update the
   (outer) addresses associated with IKE and IPsec Security
   Associations.  The extension also includes features that assist in
   selecting which addresses to use, and verify return routability
   during and after updates.  It is also able to work together with NAT
   Traversal in some scenarios.




Eronen                  Expires August 22, 2005                 [Page 1]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


1.  Introduction

1.1  Motivation

1.1.1  Scenario 1: Mobile client

   The basic MOBIKE scenario is a mobile device such as a laptop that
   may have several different network interfaces, and wishes to keep a
   connection to a VPN gateway working while moving.  For instance, a
   user could start from fixed Ethernet in the office, and then
   disconnect the laptop and move to office wireless LAN.  When leaving
   the office the laptop could start using GPRS, and switch to a
   different wireless LAN when the user arrives home.

   MOBIKE provides a way to notify the VPN gateway of the user's current
   IP address without requiring a new IKE SA (which may require user
   interaction for authentication).  Since the IP address used inside
   the tunnel (assigned by the VPN gateway using Configuration Payloads)
   does not change, transport layer connections are not broken.

   Mobility detection, policy issues such as which interface should be
   used, and implementation issues -- such as a possible interface (and
   division of work) between a "mobility and multihoming control module"
   and "IKE module" inside a host -- are beyond the scope of MOBIKE.

1.1.2  Scenario 2: Mobile client with multihomed gateway

   The second scenario has again a mobile laptop, but this time the VPN
   gateway has several network interfaces.

   MOBIKE provides a mechanism for the gateway to notify the client of
   its addresses (obviously, the client needs to know at least one
   address to contact the VPN gateway in the first place) and changes in
   their availability.

   MOBIKE also allows the client to determine which of the gateway's
   addresses can be used when the client changes its own address.  This
   is required since it cannot be assumed that all of the gateway's
   interfaces are reachable from all networks the client may connect to.
   The client may also obtain this information in some other way
   external to MOBIKE, and policy issues about which address should be
   actually used are beyond the scope of MOBIKE.

1.1.3  Scenario 3: Two multihomed gateways

   The third scenario has two VPN gateways connecting, for instance, two
   different sites of a company.  Both gateways have several network
   connections (possible from different ISPs) to provide better



Eronen                  Expires August 22, 2005                 [Page 2]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


   availability in case of network failures.

   Here MOBIKE provides a way to inform the other end of alternative
   addresses, and switch to some other connection if the currently used
   path fails.  The failures may be detected by either using IKE dead
   peer detection messages, or some external mechanism beyond the scope
   of MOBIKE.

1.2  Summary of MOPO-IKE

   Assumptions:

   o  Both the initiator and the responder can have multiple IPv4 and/or
      IPv6 addresses.  It is not assumed that all the paths work; in
      other words, only some of the initiator's addresses may work with
      a particular responder address, and vice versa.

   o  It is assumed that the initiator knows at least one of the
      responder's IP addresses beforehand, and can reach that address
      from one of its own addresses when the IKE_SA is created.  It is
      not required that this path continues to work during the whole
      lifetime of the IKE_SA.

   o  Some of the paths between the initiator and the responder may
      contain NATs or stateful packet filters.  The protocol assumes
      that the initiator can send packets to the responder at any time
      (or in other words, it is the one "behind" the stateful device),
      but the reverse is not necessarily true.

   o  Network paths may stop working unexpectedly (causing a need to
      change to some other path in "break-before-make" fashion), but in
      some cases, traffic may be moved to a new path while the old path
      is still working ("make-before-break").

   Based on these assumptions, the design goals of MOPO-IKE were to (1)
   be reasonably simple to implement, especially for nodes whose
   addresses do not change, (2) be compatible with NAT Traversal, but
   (3) still be able handle cases where both peers have multiple
   addresses.

   The protocol be summarized as follows:

   o  If the responder has other addresses than the one used for initial
      contact, it can inform the initiator of these when the IKE_SA is
      created.

   o  The initiator selects which path is used for IPsec SAs, and
      informs the responder about it.  The same path (pair of addresses)



Eronen                  Expires August 22, 2005                 [Page 3]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


      is used in both initiator-to-responder and responder-to-initiator
      directions.  Making the decision on the initiator side is
      consistent with how normal IKEv2 works, and using this path also
      for the responder-to-initiator direction makes sense especially
      with mobile clients where the client is in a better position to
      decide which network interface should be used for "downlink"
      traffic.

   o  When a path used for IPsec SAs is changed, NAT Traversal can be
      enabled or disabled as needed.

   o  If the responder's set of addresses changes, it can inform the
      initiator about this.  To allow this feature to work even when
      there is partial connectivity, the initiator can also inform the
      responder of other than currently used addresses.  This feature
      does not fully work with all types of NATs and stateful packet
      filters; all other features do.

   o  To support smoother make-before-break, and quicker recovery in
      case of break-before-make, the initiator can determine whether a
      path works or not before deciding to move the traffic.

   o  Both the initiator and the responder can optionally verify that
      the other party can actually receive packets at the claimed
      address.  This "return routability check" can be done immediately
      after updating the IPsec SAs, or continuously during the
      connection.

   o  Both the initiator and the responder can have a policy that
      prevents the use of paths that contain NATs, IPv4/IPv6 translation
      agents, or other nodes that modify the addresses in the IP header.
      This feature is mainly intended for site-to-site VPN cases, where
      the administrators may know beforehand that NATs are not present,
      and thus any modification to the packet can be considered to be an
      "attack".


1.3  Security association viewpoint

   The main purpose of this extension is to modify state associated with
   IKE_SA and IPsec SAs that is normally initialized when the SA is
   created, and not changed afterwards.

   In particular, this extension considers the following state
   associated with IKE_SA and outbound IPsec SAs (conceptually speaking;
   an implementation could store this information in some other way as
   well):




Eronen                  Expires August 22, 2005                 [Page 4]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


   o  IKE_SA

      *  local_address (source address for IKE requests)

      *  local_port (source port for IKE requests, either 500 or 4500)

      *  peer_address (destination address for IKE requests)

      *  peer_port (destination port for IKE requests)

   o  outbound IPsec SAs

      *  local_address (tunnel header source address)

      *  peer_address (tunnel header destination address)

      *  peer_port (destination port if UDP encapsulation is used)

      *  udp_encapsulation flag

      *  send_keepalives flag

      *  automatically_update_peer_address flag

   Note that both IKE_SA and outbound IPsec SAs are considered to have a
   single pair of (source,destination) addresses at a time.  These are
   the addresses used for IKE requests (including retransmissions of
   previous requests) and outbound ESP/AH packets.

   In addition, the IKE_SA contains additional state specific to this
   extension.  This state is used to to store information about
   addresses that are not currently active (see Section 2.3 for
   details).

1.4  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KEYWORDS].

   IPsec Security Association (SA)

      An ESP or AH Security Association.

   Path

      A particular combination of source IP address and destination IP
      address (and possibly ports?).



Eronen                  Expires August 22, 2005                 [Page 5]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


2.  Protocol exchanges

2.1  Signaling support for this specification

   Implementations that support this specification MUST include a
   MOPO_SUPPORTED notification in the IKE_SA_INIT request and response
   messages.

      Initiator                   Responder
     -----------                 -----------
      HDR, SAi1, KEi, Ni,
           N(MOPO_SUPPORTED),
           [N(NAT_DETECTION_*_IP)]  -->


                             <--  HDR, SAr1, KEr, Nr, [CERTREQ],
                                       N(MOPO_SUPPORTED),
                                       [N(NAT_DETECTION_*_IP)]

   The MOPO_SUPPORTED notification payload is described in Section 3.

2.2  Additional addresses

   Both the initiator and responder MAY include one or more
   ADDITIONAL_ADDRESS notification payloads in the IKE_AUTH exchange (in
   case of multiple IKE_AUTH exchanges, in the message containing the SA
   payload).

      Initiator                   Responder
     -----------                 -----------
      HDR, SK { IDi, [CERT], [IDr], AUTH,
                SAi2, TSi, TSr,
                [N(ADDITIONAL_ADDRESS)*],
                [CP(CFG_REQUEST)] }  -->

                             <--  HDR, SK { IDr, [CERT], AUTH,
                                            SAr2, TSi, TSr,
                                            [N(ADDITIONAL_ADDRESS)*],
                                            [CP(CFG_REPLY)] }

   The recipient stores this information in the "additional_addresses"
   list, but no other action is taken at this time.









Eronen                  Expires August 22, 2005                 [Page 6]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


2.3  Changing path of IPsec SAs

   This extension is based on the idea that the initiator of the IKE_SA
   decides what addresses are used in the IPsec SAs.  That is, the
   responder never updates any IPsec SAs without receiving an explicit
   CHANGE_PATH request from the initiator.  (As described below, the
   responder can, however, update the IKE_SA in some circumstances.)

   The description in this section assumes that the initiator has
   already decided what the new addresses should be.  How this decision
   is made is beyond the scope of this specification.  When this
   decision has been made, the initiator

   o  Updates the IKE_SA and IPsec SAs with the new addresses, and sets
      the "pending_update" flag in the IKE_SA.

   o  If NAT Traversal is not enabled, the responder supports NAT
      Traversal (as indicated by NAT_DETECTION payloads in the
      IKE_SA_INIT exchange), and the initiator either suspects or knows
      that a NAT is likely to be present, enables NAT Traversal.

   o  When the window size allows, sends an INFORMATIONAL request
      containing the CHANGE_PATH notification payload (which does not
      contain any data), and clears the "pending_update" flag.

      Initiator                   Responder
     -----------                 -----------
      HDR, SK {N(CHANGE_PATH),
               N(COOKIE2),
               [N(NAT_DETECTION_*),]
               [N(NAT_PREVENTION)]} -->

   o  If a new address change occurs while waiting for the response,
      starts again from the first step (and ignores responses to this
      CHANGE_PATH request).

   When processing an INFORMATIONAL request containing the CHANGE_PATH
   notification, the responder

   o  Compares the Message ID with the latest_update_received counter in
      the IKE_SA.  If latest_update_received is greater than the
      received Message ID, the reply is sent as usual, but no other
      action is taken; otherwise, updates the latest_update_received
      counter.

   o  If the NAT_PREVENTION payload is present, processes it as
      described in Section 2.7.




Eronen                  Expires August 22, 2005                 [Page 7]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


   o  Checks that the (source IP address, destination IP address) pair
      in the IP header is acceptable according to local policy.  If it
      is not, replies with "HDR, SK {COOKIE2, N(UNACCEPTABLE_PATH)}".

   o  Updates the IP addresses in the IKE_SA and IPsec SAs with the
      values from the IP header.

   o  If NAT Traversal is supported and NAT detection payloads were
      included, enables or disables NAT Traversal.

   o  Replies with an INFORMATION response:


      Initiator                   Responder
     -----------                 -----------
                             <--  HDR, SK { N(COOKIE2),
                                            [N(NAT_DETECTION_*)] }

   When the initiator receives the reply, it

   o  If the response contains the NAT_PREVENTED payload, processes it
      as described in Section 2.7.

   o  If the response contains an UNACCEPTABLE_PATH notification
      payload, TBD.

   o  If NAT Traversal is supported and NAT detection payloads were
      included, enables or disables NAT Traversal.


2.4  Updating additional addresses

   As described in Section 2.2, both the initiator and responder can
   send a list of additional addresses (in addition to the one used for
   IKE_SA_INIT/IKE_AUTH exchange) to the initiator in the IKE_AUTH
   exchange.  If this list of addresses changes, a new list can be sent
   in any INFORMATIONAL exchange request message.

   When the responder (of the original IKE_SA) receives an INFORMATIONAL
   request containing ADDITIONAL_ADDRESS payloads, it simply stores the
   information, but no other action is taken.

      Initiator                   Responder
     -----------                 -----------
      HDR, SK { N(ADDITIONAL_ADDRESS)+,
                N(COOKIE2) }  -->

                             <--  HDR, SK { N(COOKIE2) }



Eronen                  Expires August 22, 2005                 [Page 8]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


   When the initiator receives an INFORMATIONAL request containing
   ADDITIONAL_ADDRESS, it stores the information and also determines
   whether the currently used path needs to be changed; if it does, the
   initiator proceeds as described in the previous section.

      Initiator                   Responder
     -----------                 -----------
                             <--  HDR, SK { N(ADDITIONAL_ADDRESS)+,
                                            N(COOKIE2) }

      HDR, SK { N(COOKIE2) }  -->

   If the implementation supports window sizes greater than one, it also
   has to keep track of the Message ID of the latest update it has
   received, to avoid the situation where new information is overwritten
   by older.

   There is one additional complication: when the responder wants to
   send a new additional address list, the currently used path may no
   longer work.  In this case, the responder uses the additional address
   list received from the initiator, the list of its own addresses, and,
   if necessary, the path testing feature (see Section 2.5) to determine
   a path that works, updates the addresses in the IKE_SA (but not IPsec
   SAs), and then sends the INFORMATIONAL request.  This is the only
   time the responder uses the additional address list received from the
   initiator.

   Note that both peers can have their own policies about what addresses
   or paths are acceptable to use.  A minimal "mobile client" could have
   a policy that says that only the responder's address specified in
   local configuration is acceptable.  This kind of client does not have
   to send or process ADDITIONAL_ADDRESS notification payloads.
   Similarly, a simple "VPN gateway" that has only a single address, and
   is not going to change it, does not need to send or understand
   ADDITIONAL_ADDRESS notification payloads.

2.5  Path testing

   IKEv2 Dead Peer Detection allows the peers to detect if the currently
   used path has stopped working.  However, if either of the peers has
   several addresses, DPD alone does not indicate which of the other
   paths might work.

   The path testing feature allows parties to find out what action is
   required when no responses are received; that is, to find a path
   (combination of addresses) that still works.  It also removes the
   need configure information about (lack of) routing relationships in
   the case where not all possible combinations of addresses work.



Eronen                  Expires August 22, 2005                 [Page 9]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


   MOPO-IKE introduces a new IKEv2 exchange type, PATH_TEST, for testing
   connectivity.  This exchange is not part of any IKE_SA, so it is not
   cryptographically protected.  It also does not result in the
   responder keeping any state.

      Initiator                   Responder
     -----------                 -----------
      HDR(0,0), [NAT_DETECTION_*_IP]  -->

                             <--  HDR(0,0), [NAT_DETECTION_*_IP]

   The reason for introducing a new exchange type, instead of using
   INFORMATIONAL exchanges, is to simplify implementations by allowing
   MOPO-IKE to work with window size 1.

   Performing path testing over several different paths is not required
   if the node has other information that enables it to select which
   path should be used.  In this case, the PATH_TEST exchange can be
   skipped.  Implementations MAY do path testing even if the currently
   used path is working to e.g.  detect when a better but previously
   unavailable path becomes available, or to speed up recovery in fault
   situations.

   Implementations that perform path testing MUST take steps to avoid
   causing unnecessary congestion.  TBD: add some more details here.

2.6  Return routability check

   Both the initiator and the responder can optionally verify that the
   other party can actually receive packets at the claimed address.
   This "return routability check" can be done immediately after
   updating the IPsec SAs, or continuously during the connection.  Any
   INFORMATIONAL exchange can be used for return routability purposes
   (with one exception, described below): when a valid response is
   received, we know the other party can receive packets at the claimed
   address.

   To ensure that the peer cannot generate the correct INFORMATIONAL
   response without seeing the request, a new payload is added to all
   INFORMATIONAL messages.  The sender of an INFORMATIONAL request MUST
   include a COOKIE2 notification payload, and the recipient of an
   INFORMATIONAL request MUST copy the payload as-is to the response.
   When processing the response, the original sender MUST verify that
   the value is the same one as sent.  If the values do not match, the
   IKE_SA MUST be closed.

   There is one additional issue that must be taken into account.  If
   the destination address in the IKE_SA has been updated after the



Eronen                  Expires August 22, 2005                [Page 10]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


   INFORMATIONAL request was sent, then it is possible that the request
   has been sent to several different addresses.  In this case,
   receiving the INFORMATIONAL response does not tell which address is
   the working one; thus, a new INFORMATIONAL request needs to be sent.

2.7  NAT prevention

   IKEv2/IPsec implementations that do not support NAT Traversal can, in
   fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6
   translation agents in tunnel mode.  Some people feel that this is a
   problem, since in some sense any modification of the IP addresses
   could be considered to be an attack.

   The "NAT prevention" feature allows both the initiator and responder
   to have a policy that prevents the use of paths that contain NATs,
   IPv4/IPv6 translation agents, or other nodes that modify the
   addresses in the IP header.  This feature is mainly intended for
   site-to-site VPN cases, where the administrators may know beforehand
   that NATs are not present, and thus any modification to the packet
   can be considered to be an "attack".

   This specification addresses the issue as follows.  When an IPsec SA
   is created, the tunnel header IP addresses (and port if doing UDP
   encapsulation) are taken from the IKE_SA, not the message IP header.
   The NAT_PREVENTION payload is used to guarantee that NATs have not
   modified the address used in IKE_SA.  However, all response messages
   are still sent to the address and port the corresponding request came
   from.

   The initiator MAY include a NAT_PREVENTION payload in an IKE_SA_INIT
   request.  The responder MUST compare the NAT_PREVENTION payload with
   the values from the IP header.  If they do not match, the responder
   replies with "HDR(A,0), N(NAT_PREVENTED)" and does not create any
   state.

   If the values do match, the responder initializes (local_address,
   local_port, peer_address, peer_port) in the to-be-created IKE_SA with
   values from the IP header.  The same applies if neither
   NAT_PREVENTION nor NAT_DETECTION_*_IP payloads were included, or if
   the responder does not support NAT Traversal.

   If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but
   no NAT_PREVENTION payload, the situation is different since the
   initiator may at this point change from port 500 to 4500.  In this
   case, the responder initializes (local_address, local_port,
   peer_address, peer_port) from the first IKE_AUTH request.  It may
   also decide to perform a return routability check soon after the
   IKE_AUTH exchanges have been completed.



Eronen                  Expires August 22, 2005                [Page 11]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


   IKEv2 requires that if an IPsec endpoint discovers a NAT between it
   and its correspondent, it MUST send all subsequent traffic to and
   from port 4500.  To simplify things, implementations that support
   both this specification and NAT Traversal MUST change to port 4500 if
   the correspondent also supports both, even if no NAT was detected
   between them.

   NAT_PREVENTION payloads can also be included when changing the path
   of IPsec SAs (see Section 2.3).  TBD: add better description.










































Eronen                  Expires August 22, 2005                [Page 12]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


3.  Payload formats

3.1  MOPO_SUPPORTED notification payload

   The MOPO_SUPPORTED notification payload is included in the
   IKE_SA_INIT messages to indicate that the implementation supports
   this specification.

   The Notify Message Type for MOPO_SUPPORTED is TBD-BY-IANA
   (16396..40959).  The Protocol ID field is set to one (1), and SPI
   Size is set to zero.  There is no data associated with this Notify
   type.

3.2  ADDITIONAL_ADDRESS notification payload

   Both initiator and responder can include ADDITIONAL_ADDRESS payloads
   in the IKE_AUTH exchange and INFORMATIONAL exchange request messages;
   see Section 2.2 and Section 2.4 for more detailed description.

   The Notify Message Type for ADDITIONAL_ADDRESS is TBD-BY-IANA
   (16396..40959).  The Protocol ID field is set to one (1), and SPI
   Size is set to zero.  The data associated with this Notify type is
   either an IPv4 address or an IPv6 address (the type is determined by
   payload length).

3.3  CHANGE_PATH notification payload

   This payload is included in INFORMATIONAL exchange requests sent by
   the initiator of the IKE_SA to update addresses of the IKE_SA and
   IPsec SAs (see Section 2.3).

   The Notify Message Type for CHANGE_PATH is TBD-BY-IANA
   (16396..40959).  The Protocol ID field is set to one (1), and SPI
   Size is set to zero.  There is no data associated with this Notify
   type.

3.4  UNACCEPTABLE_PATH notification payload

   The responder can include this notification payload in an
   INFORMATIONAL exchange response to indicate that the address change
   in the corresponding request message (which contained a CHANGE_PATH
   notification payload) was not carried out.

   The Notify Message Type for UNACCEPTABLE_PATH is TBD-BY-IANA
   (40..8191).  The Protocol ID field is set to one (1), and SPI Size is
   set to zero.  There is no data associated with this Notify type.





Eronen                  Expires August 22, 2005                [Page 13]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


3.5  COOKIE2 notification payload

   This payload is included in all INFORMATIONAL exchange messages for
   return routability check purposes (see Section 2.6).

   The data associated with this notification MUST be between 8 and 64
   octets in length (inclusive), and MUST be chosen in a way that is
   unpredictable to the recipient.  The Notify Message Type for this
   message is TBD-BY-IANA (16396..40959).  The Protocol ID field is set
   to one (1), and SPI Size is set to zero.

3.6  NAT_PREVENTION notification payload

   See Section 2.7 for a description of this payload.

   The data associated with this notification is the SHA-1 hash
   [FIPS180-2] of the following data: the IP address and port from which
   the packet was sent, and the IP address and port to which the packet
   was sent.  The Notify Message Type for this message is TBD-BY-IANA
   (16396..40959).  The Protocol ID field is set to one (1), and SPI
   Size is set to zero.

3.7  NAT_PREVENTED notification payload

   See Section 2.7 for a description of this payload.

   The Notify Message Type for NAT_PREVENTED is TBD-BY-IANA (40..8191).
   The Protocol ID field is set to one (1), and SPI Size is set to zero.
   There is no data associated with this Notify type.






















Eronen                  Expires August 22, 2005                [Page 14]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


4.  Security considerations

   The main goal of this specification has been not to reduce any
   security offered by normal IKEv2.

   (TO BE WRITTEN: more text is needed here.)

   The return routability check is not inherently incompatible with
   NATs; as explained in Section 2.7 IKEv2/IPsec can in fact work across
   some kind of NATs even without NAT Traversal support.  In this
   specification, "NAT prevention", or integrity protection for the
   addresses in the IP header, is a separate feature.

   When NAT Traversal is supported, the peer's address may be updated
   automatically to allow changes in NAT mappings.  The "continued
   return routability" feature, implemented by the COOKIE2 payload,
   allows verification of the new address after the change.  This limits
   the duration of any "third party bombing" attack by off-path
   (relative to the victim) attackers.

5.  IANA considerations

   This document does not create any new namespaces to be maintained by
   IANA, but it requires new values in namespaces that have been defined
   in the IKEv2 base specification [IKEv2].

   This document defines one new IKEv2 exchange, "PATH_TEST", whose
   value is to be allocated from the "IKEv2 Exchange Types" namespace.
   This exchange is described in Section 2.5.

   This document also defines several new IKEv2 notification payloads
   whose values are to be allocated from the "IKEv2 Notification Payload
   Types" namespace.  These notification payloads are described in
   Section 3.

6.  Acknowledgements

   Everyone in MOBIKE WG, especially Jari Arkko, Francis Dupont, Paul
   Hoffman, Tero Kivinen, and Hannes Tschofenig.  This document also
   borrows many ideas and even some text from [AddrMgmt], [SMOBIKE],
   [Kivinen], and [Design].










Eronen                  Expires August 22, 2005                [Page 15]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


7.  References

7.1  Normative references

   [FIPS180-2]
              National Institute of Standards and Technology,
              "Specifications for the Secure Hash Standard",  Federal
              Information Processing Standard (FIPS) Publication 180-2,
              August 2002.

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

   [KEYWORDS]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [UDPEncap]
              Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
              3948, January 2005.

7.2  Informative references

   [AddrMgmt]
              Dupont, F., "Address Management for IKE version 2",
              draft-dupont-ikev2-addrmgmt-06 (work in progress), June
              2004.

   [Design]   Kivinen, T. and H. Tschofenig, "Design of the MOBIKE
              protocol", draft-ietf-mobike-design-01 (work in progress),
              June 2004.

   [Kivinen]  Kivinen, T., "MOBIKE protocol",
              draft-kivinen-mobike-protocol-00 (work in progress),
              February 2004.

   [SMOBIKE]  Eronen, P. and H. Tschofenig, "Simple Mobility and
              Multihoming Extensions for IKEv2 (SMOBIKE)",
              draft-eronen-mobike-simple-00 (work in progress), March
              2004.

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




Eronen                  Expires August 22, 2005                [Page 16]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


Author's Address

   Pasi Eronen
   Nokia Research Center
   P.O. Box 407
   FIN-00045 Nokia Group
   Finland

   EMail: pasi.eronen@nokia.com










































Eronen                  Expires August 22, 2005                [Page 17]

Internet-Draft    Mobility Protocol Options for IKEv2      February 2005


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.




Eronen                  Expires August 22, 2005                [Page 18]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/