GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4555

Network Working Group P. Eronen, Ed. Request for Comments: 4555 Nokia Category: Standards Track June 2006

          IKEv2 Mobility and Multihoming Protocol (MOBIKE)

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 This document describes the MOBIKE protocol, a mobility and
 multihoming extension to Internet Key Exchange (IKEv2).  MOBIKE
 allows the IP addresses associated with IKEv2 and tunnel mode IPsec
 Security Associations to change.  A mobile Virtual Private Network
 (VPN) client could use MOBIKE to keep the connection with the VPN
 gateway active while moving from one address to another.  Similarly,
 a multihomed host could use MOBIKE to move the traffic to a different
 interface if, for instance, the one currently being used stops
 working.

Eronen Standards Track [Page 1] RFC 4555 MOBIKE Protocol June 2006

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2.  Scope and Limitations  . . . . . . . . . . . . . . . . . .  4
   1.3.  Terminology and Notation . . . . . . . . . . . . . . . . .  4
 2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  5
   2.1.  Basic Operation  . . . . . . . . . . . . . . . . . . . . .  5
   2.2.  Example Protocol Exchanges . . . . . . . . . . . . . . . .  6
   2.3.  MOBIKE and Network Address Translation (NAT) . . . . . . .  9
 3.  Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
   3.1.  Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10
   3.2.  Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10
   3.3.  Initial Tunnel Header Addresses  . . . . . . . . . . . . . 11
   3.4.  Additional Addresses . . . . . . . . . . . . . . . . . . . 11
   3.5.  Changing Addresses in IPsec SAs  . . . . . . . . . . . . . 12
   3.6.  Updating Additional Addresses  . . . . . . . . . . . . . . 15
   3.7.  Return Routability Check . . . . . . . . . . . . . . . . . 17
   3.8.  Changes in NAT Mappings  . . . . . . . . . . . . . . . . . 18
   3.9.  NAT Prohibition  . . . . . . . . . . . . . . . . . . . . . 19
   3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
   3.11. Failure Recovery and Timeouts  . . . . . . . . . . . . . . 20
   3.12. Dead Peer Detection  . . . . . . . . . . . . . . . . . . . 20
 4.  Payload Formats  . . . . . . . . . . . . . . . . . . . . . . . 21
   4.1.  Notify Messages - Error Types  . . . . . . . . . . . . . . 21
   4.2.  Notify Messages - Status Types . . . . . . . . . . . . . . 21
 5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   5.1.  Traffic Redirection and Hijacking  . . . . . . . . . . . . 24
   5.2.  IPsec Payload Protection . . . . . . . . . . . . . . . . . 24
   5.3.  Denial-of-Service Attacks against Third Parties  . . . . . 25
   5.4.  Spoofing Network Connectivity Indications  . . . . . . . . 26
   5.5.  Address and Topology Disclosure  . . . . . . . . . . . . . 27
 6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
 7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
 8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
   8.1.  Normative References . . . . . . . . . . . . . . . . . . . 29
   8.2.  Informative References . . . . . . . . . . . . . . . . . . 29
 Appendix A.  Implementation Considerations . . . . . . . . . . . . 31
   A.1.  Links from SPD Cache to Outbound SAD Entries . . . . . . . 31
   A.2.  Creating Outbound SAs  . . . . . . . . . . . . . . . . . . 31

Eronen Standards Track [Page 2] RFC 4555 MOBIKE Protocol June 2006

1. Introduction

1.1. Motivation

 IKEv2 is used for performing mutual authentication, as well as
 establishing and maintaining IPsec Security Associations (SAs).  In
 the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec
 SAs are created implicitly between the IP addresses that are used
 when the IKE_SA is established.  These IP addresses are then used as
 the outer (tunnel header) addresses for tunnel mode IPsec packets
 (transport mode IPsec SAs are beyond the scope of this document).
 Currently, it is not possible to change these addresses after the
 IKE_SA has been created.
 There are scenarios where these IP addresses might change.  One
 example is mobility: a host changes its point of network attachment
 and receives a new IP address.  Another example is a multihoming host
 that would like to change to a different interface if, for instance,
 the currently used interface stops working for some reason.
 Although the problem can be solved by creating new IKE and IPsec SAs
 when the addresses need to be changed, this may not be optimal for
 several reasons.  In some cases, creating a new IKE_SA may require
 user interaction for authentication, such as entering a code from a
 token card.  Creating new SAs often involves expensive calculations
 and possibly a large number of round-trips.  For these reasons, a
 mechanism for updating the IP addresses of existing IKE and IPsec SAs
 is needed.  The MOBIKE protocol described in this document provides
 such a mechanism.
 The main scenario for MOBIKE is enabling a remote access VPN user to
 move from one address to another without re-establishing all security
 associations with the VPN gateway.  For instance, a user could start
 from fixed Ethernet in the office and then disconnect the laptop and
 move to the office's wireless LAN.  When the user leaves the office,
 the laptop could start using General Packet Radio Service (GPRS);
 when the user arrives home, the laptop could switch to the home
 wireless LAN.  MOBIKE updates only the outer (tunnel header)
 addresses of IPsec SAs, and the addresses and other traffic selectors
 used inside the tunnel stay unchanged.  Thus, mobility can be
 (mostly) invisible to applications and their connections using the
 VPN.

Eronen Standards Track [Page 3] RFC 4555 MOBIKE Protocol June 2006

 MOBIKE also supports more complex scenarios where the VPN gateway
 also has several network interfaces: these interfaces could be
 connected to different networks or ISPs, they may be a mix of IPv4
 and IPv6 addresses, and the addresses may change over time.
 Furthermore, both parties could be VPN gateways relaying traffic for
 other parties.

1.2. Scope and Limitations

 This document focuses on the main scenario outlined above and
 supports only tunnel mode IPsec SAs.
 The mobility support in MOBIKE allows both parties to move, but does
 not provide a "rendezvous" mechanism that would allow simultaneous
 movement of both parties or discovery of the addresses when the
 IKE_SA is first established.  Therefore, MOBIKE is best suited for
 situations where the address of at least one endpoint is relatively
 stable and can be discovered using existing mechanisms such as DNS
 (see Section 3.1).
 MOBIKE allows both parties to be multihomed; however, only one pair
 of addresses is used for an SA at a time.  In particular, load
 balancing is beyond the scope of this specification.
 MOBIKE follows the IKEv2 practice where a response message is sent to
 the same address and port from which the request was received.  This
 implies that MOBIKE does not work over address pairs that provide
 only unidirectional connectivity.
 Network Address Translators (NATs) introduce additional limitations
 beyond those listed above.  For details, refer to Section 2.3.
 The base version of the MOBIKE protocol does not cover all potential
 future use scenarios, such as transport mode, application to securing
 SCTP, or optimizations desirable in specific circumstances.  Future
 extensions may be defined later to support additional requirements.
 Please consult the MOBIKE design document [Design] for further
 information and rationale behind these limitations.

1.3. Terminology and Notation

 When messages containing IKEv2 payloads are described, optional
 payloads are shown in brackets (for instance, "[FOO]"), and a plus
 sign indicates that a payload can be repeated one or more times (for
 instance, "FOO+").  To provide context, some diagrams also show what
 existing IKEv2 payloads would typically be included in the exchanges.
 These payloads are shown for illustrative purposes only; see [IKEv2]
 for an authoritative description.

Eronen Standards Track [Page 4] RFC 4555 MOBIKE Protocol June 2006

 When this document describes updating the source/destination
 addresses of an IPsec SA, it means updating IPsec-related state so
 that outgoing Encapsulating Security Payload (ESP)/Authentication
 Header (AH) packets use those addresses in the tunnel header.
 Depending on how the nominal divisions between Security Association
 Database (SAD), Security Policy Database (SPD), and Peer
 Authorization Database (PAD) described in [IPsecArch] are actually
 implemented, an implementation can have several different places that
 have to be updated.
 In this document, the term "initiator" means the party who originally
 initiated the first IKE_SA (in a series of possibly several rekeyed
 IKE_SAs); "responder" is the other peer.  During the lifetime of the
 IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA
 exchanges; in this case, the terms "exchange initiator" and "exchange
 responder" are used.  The term "original initiator" (which in [IKEv2]
 refers to the party who started the latest IKE_SA rekeying) is not
 used in this document.
 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].

2. Protocol Overview

2.1. Basic Operation

 MOBIKE allows both parties to have several addresses, and there are
 up to N*M pairs of IP addresses that could potentially be used.  The
 decision of which of these pairs to use has to take into account
 several factors.  First, the parties may have preferences about which
 interface should be used due to, for instance, performance and cost
 reasons.  Second, the decision is constrained by the fact that some
 of the pairs may not work at all due to incompatible IP versions,
 outages in the network, problems at the local link at either end, and
 so on.
 MOBIKE solves this problem by taking a simple approach: the party
 that initiated the IKE_SA (the "client" in a remote access VPN
 scenario) is responsible for deciding which address pair is used for
 the IPsec SAs and for collecting the information it needs to make
 this decision (such as determining which address pairs work or do not
 work).  The other party (the "gateway" in a remote access VPN
 scenario) simply tells the initiator what addresses it has, but does
 not update the IPsec SAs until it receives a message from the
 initiator to do so.  This approach applies to the addresses in the
 IPsec SAs; in the IKE_SA case, the exchange initiator can decide
 which addresses are used.

Eronen Standards Track [Page 5] RFC 4555 MOBIKE Protocol June 2006

 Making the decision at the initiator is consistent with how normal
 IKEv2 works: the initiator decides which addresses it uses when
 contacting the responder.  It also makes sense, especially when the
 initiator is a mobile node: it is in a better position to decide
 which of its network interfaces should be used for both upstream and
 downstream traffic.
 The details of exactly how the initiator makes the decision, what
 information is used in making it, how the information is collected,
 how preferences affect the decision, and when a decision needs to be
 changed are largely beyond the scope of MOBIKE.  This does not mean
 that these details are unimportant: on the contrary, they are likely
 to be crucial in any real system.  However, MOBIKE is concerned with
 these details only to the extent that they are visible in IKEv2/IPsec
 messages exchanged between the peers (and thus need to be
 standardized to ensure interoperability).
 Many of these issues are not specific to MOBIKE, but are common with
 the use of existing hosts in dynamic environments or with mobility
 protocols such as Mobile IP [MIP4] [MIP6].  A number of mechanisms
 already exist or are being developed to deal with these issues.  For
 instance, link-layer and IP-layer mechanisms can be used to track the
 status of connectivity within the local link [RFC2461]; movement
 detection is being specified for both IPv4 and IPv6 in [DNA4],
 [DNA6], and so on.
 Naturally, updating the addresses of IPsec SAs has to take into
 account several security considerations.  MOBIKE includes two
 features designed to address these considerations.  First, a "return
 routability" check can be used to verify the addresses provided by
 the peer.  This makes it more difficult to flood third parties with
 large amounts of traffic.  Second, a "NAT prohibition" feature
 ensures that IP addresses have not been modified by NATs, IPv4/IPv6
 translation agents, or other similar devices.  This feature is
 enabled only when NAT Traversal is not used.

2.2. Example Protocol Exchanges

 A simple MOBIKE exchange in a mobile scenario is illustrated below.
 The notation is based on [IKEv2], Section 1.2.  In addition, the
 source/destination IP addresses and ports are shown for each packet:
 here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by
 the initiator and the responder.

Eronen Standards Track [Page 6] RFC 4555 MOBIKE Protocol June 2006

    Initiator                  Responder
   -----------                -----------
 1) (IP_I1:500 -> IP_R1:500)
    HDR, SAi1, KEi, Ni,
         N(NAT_DETECTION_SOURCE_IP),
         N(NAT_DETECTION_DESTINATION_IP)  -->
                          <--  (IP_R1:500 -> IP_I1:500)
                               HDR, SAr1, KEr, Nr,
                                    N(NAT_DETECTION_SOURCE_IP),
                                    N(NAT_DETECTION_DESTINATION_IP)
 2) (IP_I1:4500 -> IP_R1:4500)
    HDR, SK { IDi, CERT, AUTH,
              CP(CFG_REQUEST),
              SAi2, TSi, TSr,
              N(MOBIKE_SUPPORTED) }  -->
                          <--  (IP_R1:4500 -> IP_I1:4500)
                               HDR, SK { IDr, CERT, AUTH,
                                         CP(CFG_REPLY),
                                         SAr2, TSi, TSr,
                                         N(MOBIKE_SUPPORTED) }
 (Initiator gets information from lower layers that its attachment
 point and address have changed.)
 3) (IP_I2:4500 -> IP_R1:4500)
    HDR, SK { N(UPDATE_SA_ADDRESSES),
              N(NAT_DETECTION_SOURCE_IP),
              N(NAT_DETECTION_DESTINATION_IP) }  -->
                          <-- (IP_R1:4500 -> IP_I2:4500)
                              HDR, SK { N(NAT_DETECTION_SOURCE_IP),
                                   N(NAT_DETECTION_DESTINATION_IP) }
 (Responder verifies that the initiator has given it a correct IP
 address.)
 4)                       <-- (IP_R1:4500 -> IP_I2:4500)
                              HDR, SK { N(COOKIE2) }
    (IP_I2:4500 -> IP_R1:4500)
    HDR, SK { N(COOKIE2) }  -->
 Step 1 is the normal IKE_INIT exchange.  In step 2, the peers inform
 each other that they support MOBIKE.  In step 3, the initiator
 notices a change in its own address, and informs the responder about

Eronen Standards Track [Page 7] RFC 4555 MOBIKE Protocol June 2006

 this by sending an INFORMATIONAL request containing the
 UPDATE_SA_ADDRESSES notification.  The request is sent using the new
 IP address.  At this point, it also starts to use the new address as
 a source address in its own outgoing ESP traffic.  Upon receiving the
 UPDATE_SA_ADDRESSES notification, the responder records the new
 address and, if it is required by policy, performs a return
 routability check of the address.  When this check (step 4)
 completes, the responder starts to use the new address as the
 destination for its outgoing ESP traffic.
 Another protocol run in a multihoming scenario is illustrated below.
 In this scenario, the initiator has one address but the responder has
 two.
    Initiator                  Responder
   -----------                -----------
 1) (IP_I1:500 -> IP_R1:500)
    HDR, SAi1, KEi, Ni,
         N(NAT_DETECTION_SOURCE_IP),
         N(NAT_DETECTION_DESTINATION_IP)  -->
                          <--  (IP_R1:500 -> IP_I1:500)
                               HDR, SAr1, KEr, Nr,
                                    N(NAT_DETECTION_SOURCE_IP),
                                    N(NAT_DETECTION_DESTINATION_IP)
 2) (IP_I1:4500 -> IP_R1:4500)
    HDR, SK { IDi, CERT, AUTH,
              CP(CFG_REQUEST),
              SAi2, TSi, TSr,
              N(MOBIKE_SUPPORTED) }  -->
                          <--  (IP_R1:4500 -> IP_I1:4500)
                               HDR, SK { IDr, CERT, AUTH,
                                         CP(CFG_REPLY),
                                         SAr2, TSi, TSr,
                                         N(MOBIKE_SUPPORTED),
                                         N(ADDITIONAL_IP4_ADDRESS) }
 (The initiator suspects a problem in the currently used address pair
 and probes its liveness.)

Eronen Standards Track [Page 8] RFC 4555 MOBIKE Protocol June 2006

 3) (IP_I1:4500 -> IP_R1:4500)
    HDR, SK { N(NAT_DETECTION_SOURCE_IP),
              N(NAT_DETECTION_DESTINATION_IP) }  -->
    (IP_I1:4500 -> IP_R1:4500)
    HDR, SK { N(NAT_DETECTION_SOURCE_IP),
              N(NAT_DETECTION_DESTINATION_IP) }  -->
    ...
 (Eventually, the initiator gives up on the current address pair and
 tests the other available address pair.)
 4) (IP_I1:4500 -> IP_R2:4500)
    HDR, SK { N(NAT_DETECTION_SOURCE_IP),
              N(NAT_DETECTION_DESTINATION_IP) }
                          <--  (IP_R2:4500 -> IP_I1:4500)
                               HDR, SK { N(NAT_DETECTION_SOURCE_IP),
                                    N(NAT_DETECTION_DESTINATION_IP) }
 (This worked, and the initiator requests the peer to switch to new
 addresses.)
 5) (IP_I1:4500 -> IP_R2:4500)
    HDR, SK { N(UPDATE_SA_ADDRESSES),
              N(NAT_DETECTION_SOURCE_IP),
              N(NAT_DETECTION_DESTINATION_IP),
              N(COOKIE2) }  -->
                          <--  (IP_R2:4500 -> IP_I1:4500)
                               HDR, SK { N(NAT_DETECTION_SOURCE_IP),
                                    N(NAT_DETECTION_DESTINATION_IP),
                                    N(COOKIE2) }

2.3. MOBIKE and Network Address Translation (NAT)

 In some MOBIKE scenarios, the network may contain NATs or stateful
 packet filters (for brevity, the rest of this document simply
 describes NATs).  The NAT Traversal feature specified in [IKEv2]
 allows IKEv2 to work through NATs in many cases, and MOBIKE can
 leverage this functionality: when the addresses used for IPsec SAs
 are changed, MOBIKE can enable or disable IKEv2 NAT Traversal, as
 needed.
 Nevertheless, there are some limitations because NATs usually
 introduce an asymmetry into the network: only packets coming from the
 "inside" cause state to be created.  This asymmetry leads to

Eronen Standards Track [Page 9] RFC 4555 MOBIKE Protocol June 2006

 restrictions on what MOBIKE can do.  To give a concrete example,
 consider a situation where both peers have only a single address, and
 the initiator is behind a NAT.  If the responder's address now
 changes, it needs to send a packet to the initiator using its new
 address.  However, if the NAT is, for instance, of the common
 "restricted cone" type (see [STUN] for one description of different
 NAT types), this is not possible.  The NAT will drop packets sent
 from the new address (unless the initiator has previously sent a
 packet to that address -- which it cannot do until it knows the
 address).
 For simplicity, MOBIKE does not attempt to handle all possible NAT-
 related scenarios.  Instead, MOBIKE assumes that if NATs are present,
 the initiator is the party "behind" the NAT, and the case where the
 responder's addresses change is not fully supported (meaning that no
 special effort is made to support this functionality).  Responders
 may also be unaware of NATs or specific types of NATs they are
 behind.  However, when a change has occurred that will cause a loss
 of connectivity, MOBIKE responders will still attempt to inform the
 initiator of the change.  Depending on, for instance, the exact type
 of NAT, it may or may not succeed.  However, analyzing the exact
 circumstances when this will or will not work is not done in this
 document.

3. Protocol Exchanges

3.1. Initial IKE Exchange

 The initiator is responsible for finding a working pair of addresses
 so that the initial IKE exchange can be carried out.  Any information
 from MOBIKE extensions will only be available later, when the
 exchange has progressed far enough.  Exactly how the addresses used
 for the initial exchange are discovered is beyond the scope of this
 specification; typical sources of information include local
 configuration and DNS.
 If either or both of the peers have multiple addresses, some
 combinations may not work.  Thus, the initiator SHOULD try various
 source and destination address combinations when retransmitting the
 IKE_SA_INIT request.

3.2. Signaling Support for MOBIKE

 Implementations that wish to use MOBIKE for a particular IKE_SA MUST
 include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in
 case of multiple IKE_AUTH exchanges, in the message containing the SA
 payload).

Eronen Standards Track [Page 10] RFC 4555 MOBIKE Protocol June 2006

 The format of the MOBIKE_SUPPORTED notification is described in
 Section 4.

3.3. Initial Tunnel Header Addresses

 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
 IP header of the IKEv2 message requesting the IPsec SA.  The
 addresses in the IKE_SA are initialized from the IP header of the
 first IKE_AUTH request.
 The addresses are taken from the IKE_AUTH request because IKEv2
 requires changing from port 500 to 4500 if a NAT is discovered.  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 (this way,
 there is no need to change the ports later if a NAT is detected on
 some other path).

3.4. Additional Addresses

 Both the initiator and responder MAY include one or more
 ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in
 the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the
 message containing the SA payload).  Here "ADDITIONAL_*_ADDRESS"
 means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS
 notification.
    Initiator                  Responder
   -----------                -----------
    HDR, SK { IDi, [CERT], [IDr], AUTH,
              [CP(CFG_REQUEST)]
              SAi2, TSi, TSr,
              N(MOBIKE_SUPPORTED),
              [N(ADDITIONAL_*_ADDRESS)+] }  -->
                          <--  HDR, SK { IDr, [CERT], AUTH,
                                         [CP(CFG_REPLY)],
                                         SAr2, TSi, TSr,
                                         N(MOBIKE_SUPPORTED)
                                         [N(ADDITIONAL_*_ADDRESS)+] }
 The recipient stores this information, but no other action is taken
 at this time.
 Although both the initiator and responder maintain a set of peer
 addresses (logically associated with the IKE_SA), it is important to
 note that they use this information for slightly different purposes.

Eronen Standards Track [Page 11] RFC 4555 MOBIKE Protocol June 2006

 The initiator uses the set of responder addresses as an input to its
 address selection policy; it may, at some later point, decide to move
 the IPsec traffic to one of these addresses using the procedure
 described in Section 3.5.  The responder normally does not use the
 set of initiator addresses for anything: the addresses are used only
 when the responder's own addresses change (see Section 3.6).
 The set of addresses available to the peers can change during the
 lifetime of the IKE_SA.  The procedure for updating this information
 is described in Section 3.6.
 Note that if some of the initiator's interfaces are behind a NAT
 (from the responder's point of view), the addresses received by the
 responder will be incorrect.  This means the procedure for changing
 responder addresses described in Section 3.6 does not fully work when
 the initiator is behind a NAT.  For the same reason, the peers also
 SHOULD NOT use this information for any other purpose than what is
 explicitly described either in this document or a future
 specification updating it.

3.5. Changing Addresses in IPsec SAs

 In MOBIKE, the initiator decides what addresses are used in the IPsec
 SAs.  That is, the responder does not normally update any IPsec SAs
 without receiving an explicit UPDATE_SA_ADDRESSES request from the
 initiator.  (As described below, the responder can, however, update
 the IKE_SA in some circumstances.)
 The reasons why the initiator wishes to change the addresses are
 largely beyond the scope of MOBIKE.  Typically, triggers include
 information received from lower layers, such as changes in IP
 addresses or link-down indications.  Some of this information can be
 unreliable: for instance, ICMP messages could be spoofed by an
 attacker.  Unreliable information SHOULD be treated only as a hint
 that there might be a problem, and the initiator SHOULD trigger Dead
 Peer Detection (that is, send an INFORMATIONAL request) to determine
 if the current path is still usable.
 Changing addresses can also be triggered by events within IKEv2.  At
 least the following events can cause the initiator to re-evaluate its
 local address selection policy, possibly leading to changing the
 addresses.
 o  An IKEv2 request has been re-transmitted several times, but no
    valid reply has been received.  This suggests the current path is
    no longer working.

Eronen Standards Track [Page 12] RFC 4555 MOBIKE Protocol June 2006

 o  An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS,
    ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
    received.  This means the peer's addresses may have changed.  This
    is particularly important if the announced set of addresses no
    longer contains the currently used address.
 o  An UNACCEPTABLE_ADDRESSES notification is received as a response
    to address update request (described below).
 o  The initiator receives a NAT_DETECTION_DESTINATION_IP notification
    that does not match the previous UPDATE_SA_ADDRESSES response (see
    Section 3.8 for a more detailed description).
 The description in the rest of this section assumes that the
 initiator has already decided what the new addresses should be.  When
 this decision has been made, the initiator:
 o  Updates the IKE_SA with the new addresses, and sets the
    "pending_update" flag in the IKE_SA.
 o  Updates the IPsec SAs associated with this IKE_SA with the new
    addresses (unless the initiator's policy requires a return
    routability check before updating the IPsec SAs, and the check has
    not been done for this responder address yet).
 o  If the IPsec SAs were updated in the previous step: If NAT
    Traversal is not enabled, and 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 (that is, enables
    UDP encapsulation of outgoing ESP packets and sending of NAT-
    Keepalive packets).
 o  If there are outstanding IKEv2 requests (requests for which the
    initiator has not yet received a reply), continues retransmitting
    them using the addresses in the IKE_SA (the new addresses).
 o  When the window size allows, sends an INFORMATIONAL request
    containing the UPDATE_SA_ADDRESSES notification (which does not
    contain any data), and clears the "pending_update" flag.  The
    request will be as follows:

Eronen Standards Track [Page 13] RFC 4555 MOBIKE Protocol June 2006

    Initiator                  Responder
   -----------                -----------
    HDR, SK { N(UPDATE_SA_ADDRESSES),
              [N(NAT_DETECTION_SOURCE_IP),
               N(NAT_DETECTION_DESTINATION_IP)],
              [N(NO_NATS_ALLOWED)],
              [N(COOKIE2)] } -->
 o  If a new address change occurs while waiting for the response,
    starts again from the first step (and ignores responses to this
    UPDATE_SA_ADDRESSES request).
 When processing an INFORMATIONAL request containing the
 UPDATE_SA_ADDRESSES notification, the responder:
 o  Determines whether it has already received a newer
    UPDATE_SA_ADDRESSES request than this one (if the responder uses a
    window size greater than one, it is possible that requests are
    received out of order).  If it has, a normal response message
    (described below) is sent, but no other action is taken.
 o  If the NO_NATS_ALLOWED notification is present, processes it as
    described in Section 3.9.
 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 a message containing the
    UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2).
 o  Updates the IP addresses in the IKE_SA with the values from the IP
    header.  (Using the address from the IP header is consistent with
    normal IKEv2, and allows IKEv2 to work with NATs without needing
    unilateral self-address fixing [UNSAF].)
 o  Replies with an INFORMATIONAL response:
    Initiator                  Responder
   -----------                -----------
                          <--  HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
                                    N(NAT_DETECTION_DESTINATION_IP)],
                                    [N(COOKIE2)] }
 o  If necessary, initiates a return routability check for the new
    initiator address (see Section 3.7) and waits until the check is
    completed.
 o  Updates the IPsec SAs associated with this IKE_SA with the new
    addresses.

Eronen Standards Track [Page 14] RFC 4555 MOBIKE Protocol June 2006

 o  If NAT Traversal is supported and NAT detection payloads were
    included, enables or disables NAT Traversal.
 When the initiator receives the reply:
 o  If an address change has occurred after the request was first
    sent, no MOBIKE processing is done for the reply message because a
    new UPDATE_SA_ADDRESSES is going to be sent (or has already been
    sent, if window size greater than one is in use).
 o  If the response contains the UNEXPECTED_NAT_DETECTED notification,
    the initiator processes the response as described in Section 3.9.
 o  If the response contains an UNACCEPTABLE_ADDRESSES notification,
    the initiator MAY select another addresses and retry the exchange,
    keep on using the previously used addresses, or disconnect.
 o  It updates the IPsec SAs associated with this IKE_SA with the new
    addresses (unless this was already done earlier before sending the
    request; this is the case when no return routability check was
    required).
 o  If NAT Traversal is supported and NAT detection payloads were
    included, the initiator enables or disables NAT Traversal.
 There is one exception to the rule that the responder never updates
 any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request.  If
 the source address that the responder is currently using becomes
 unavailable (i.e., sending packets using that source address is no
 longer possible), the responder is allowed to update the IPsec SAs to
 use some other address (in addition to initiating the procedure
 described in the next section).

3.6. Updating Additional Addresses

 As described in Section 3.4, both the initiator and responder can
 send a list of additional addresses in the IKE_AUTH exchange.  This
 information can be updated by sending an INFORMATIONAL exchange
 request message that contains either one or more
 ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the
 NO_ADDITIONAL_ADDRESSES notification.
 If the exchange initiator has only a single IP address, it is placed
 in the IP header, and the message contains the
 NO_ADDITIONAL_ADDRESSES notification.  If the exchange initiator has
 several addresses, one of them is placed in the IP header, and the
 rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications.

Eronen Standards Track [Page 15] RFC 4555 MOBIKE Protocol June 2006

 The new list of addresses replaces the old information (in other
 words, there are no separate add/delete operations; instead, the
 complete list is sent every time these notifications are used).
 The message exchange will look as follows:
    Initiator                  Responder
   -----------                -----------
    HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
              [N(NO_ADDITIONAL_ADDRESSES)],
              [N(NO_NATS_ALLOWED)],
              [N(COOKIE2)] }  -->
                          <--  HDR, SK { [N(COOKIE2)] }
 When a request containing an ADDITIONAL_IP4_ADDRESS,
 ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
 received, the exchange responder:
 o  Determines whether it has already received a newer request to
    update the addresses (if a window size greater than one is used,
    it is possible that the requests are received out of order).  If
    it has, a response message is sent, but the address set is not
    updated.
 o  If the NO_NATS_ALLOWED notification is present, processes it as
    described in Section 3.9.
 o  Updates the set of peer addresses based on the IP header and the
    ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, and
    NO_ADDITIONAL_ADDRESSES notifications.
 o  Sends a response.
 The initiator MAY include these notifications in the same request as
 UPDATE_SA_ADDRESSES.
 If the request to update the addresses is retransmitted using several
 different source addresses, a new INFORMATIONAL request MUST be sent.
 There is one additional complication: when the responder wants to
 update the address set, the currently used addresses may no longer
 work.  In this case, the responder uses the additional address list
 received from the initiator, and the list of its own addresses, to
 determine which addresses to use for sending the INFORMATIONAL
 request.  This is the only time the responder uses the additional
 address list received from the initiator.

Eronen Standards Track [Page 16] RFC 4555 MOBIKE Protocol June 2006

 Note that both peers can have their own policies about what addresses
 are acceptable to use, and certain types of policies may simplify
 implementation.  For instance, if the responder has a single fixed
 address, it does not need to process the ADDITIONAL_IP4_ADDRESS and
 ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring
 unrecognized status notifications, as already required in [IKEv2]).
 Furthermore, if the initiator has a policy saying that only the
 responder address specified in local configuration is acceptable, it
 does not have to send its own additional addresses to the responder
 (since the responder does not need them except when changing its own
 address).

3.7. Return Routability Check

 Both parties can optionally verify that the other party can actually
 receive packets at the claimed address.  By default, this "return
 routability check" SHOULD be performed.  In environments where the
 peer is expected to be well-behaved (many corporate VPNs, for
 instance), or the address can be verified by some other means (e.g.,
 a certificate issued by an authority trusted for this purpose), the
 return routability check MAY be omitted.
 The check can be done before updating the IPsec SAs, immediately
 after updating them, or continuously during the connection.  By
 default, the return routability check SHOULD be done before updating
 the IPsec SAs, but in some environments it MAY be postponed until
 after the IPsec SAs have been updated.
 Any INFORMATIONAL exchange can be used for return routability
 purposes, with one exception (described later in this section): 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
 INFORMATIONAL messages.  The sender of an INFORMATIONAL request MAY
 include a COOKIE2 notification, and if included, the recipient of an
 INFORMATIONAL request MUST copy the notification 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.  (See also Section 4.2.5 for the
 format of the COOKIE2 notification.)

Eronen Standards Track [Page 17] RFC 4555 MOBIKE Protocol June 2006

 The exception mentioned earlier is as follows: If the same
 INFORMATIONAL request has been sent to several different addresses
 (i.e., the destination address in the IKE_SA has been updated after
 the request was first sent), receiving the INFORMATIONAL response
 does not tell which address is the working one.  In this case, a new
 INFORMATIONAL request needs to be sent to check return routability.

3.8. Changes in NAT Mappings

 IKEv2 performs Dead Peer Detection (DPD) if there has recently been
 only outgoing traffic on all of the SAs associated with the IKE_SA.
 In MOBIKE, these messages can also be used to detect if NAT mappings
 have changed (for example, if the keepalive interval is too long, or
 the NAT box is rebooted).  More specifically, if both peers support
 both this specification and NAT Traversal, the
 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
 notifications MAY be included in any INFORMATIONAL request; if the
 request includes them, the responder MUST also include them in the
 response (but no other action is taken, unless otherwise specified).
 When the initiator is behind a NAT (as detected earlier using the
 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
 notifications), it SHOULD include these notifications in DPD messages
 and compare the received NAT_DETECTION_DESTINATION_IP notifications
 with the value from the previous UPDATE_SA_ADDRESSES response (or the
 IKE_SA_INIT response).  If the values do not match, the IP address
 and/or port seen by the responder has changed, and the initiator
 SHOULD send UPDATE_SA_ADDRESSES as described in Section 3.5.  If the
 initiator suspects that the NAT mapping has changed, it MAY also skip
 the detection step and send UPDATE_SA_ADDRESSES immediately.  This
 saves one roundtrip if the NAT mapping has indeed changed.
 Note that this approach to detecting NAT mapping changes may cause an
 extra address update when the IKE_SA is rekeyed.  This is because the
 NAT_DETECTION_DESTINATION_IP hash also includes the IKE Security
 Parameter Indexes (SPIs), which change when performing rekeying.
 This unnecessary update is harmless, however.
 When MOBIKE is in use, the dynamic updates (specified in [IKEv2],
 Section 2.23), where the peer address and port are updated from the
 last valid authenticated packet, work in a slightly different
 fashion.  The host not behind a NAT MUST NOT use these dynamic
 updates for IKEv2 packets, but MAY use them for ESP packets.  This
 ensures that an INFORMATIONAL exchange that does not contain
 UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be
 used for, e.g., testing whether a particular path works.

Eronen Standards Track [Page 18] RFC 4555 MOBIKE Protocol June 2006

3.9. NAT Prohibition

 Basic IKEv2/IPsec without NAT Traversal support may work across some
 types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in
 tunnel mode.  This is because the IKEv2 integrity checksum does not
 cover the addresses in the IP header.  This may be considered a
 problem in some circumstances, because in some sense any modification
 of the IP addresses can be considered an attack.
 This specification addresses the issue by protecting the IP addresses
 when NAT Traversal has not been explicitly enabled.  This means that
 MOBIKE without NAT Traversal support will not work if the paths
 contain NATs, IPv4/IPv6 translation agents, or other nodes that
 modify the addresses in the IP header.  This feature is mainly
 intended for IPv6 and 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 an attack.
 More specifically, when NAT Traversal is not enabled, all messages
 that can update the addresses associated with the IKE_SA and/or IPsec
 SAs (the first IKE_AUTH request and all INFORMATIONAL requests that
 contain any of the following notifications: UPDATE_SA_ADDRESSES,
 ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS,
 NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED
 notification.  The exchange responder MUST verify that the contents
 of the NO_NATS_ALLOWED notification match the addresses in the IP
 header.  If they do not match, a response containing an
 UNEXPECTED_NAT_DETECTED notification is sent.  The response message
 is sent to the address and port that the corresponding request came
 from, not to the address contained in the NO_NATS_ALLOWED
 notification.
 If the exchange initiator receives an UNEXPECTED_NAT_DETECTED
 notification in response to its INFORMATIONAL request, it SHOULD
 retry the operation several times using new INFORMATIONAL requests.
 Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the
 IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several
 times, starting from a new IKE_SA_INIT request.  This ensures that an
 attacker who is able to modify only a single packet does not
 unnecessarily cause a path to remain unused.  The exact number of
 retries is not specified in this document because it does not affect
 interoperability.  However, because the IKE message will also be
 rejected if the attacker modifies the integrity checksum field, a
 reasonable number here would be the number of retries that is being
 used for normal retransmissions.

Eronen Standards Track [Page 19] RFC 4555 MOBIKE Protocol June 2006

 If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange
 responder MUST NOT use the contents of the NO_NATS_ALLOWED
 notification for any other purpose than possibly logging the
 information for troubleshooting purposes.

3.10. 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, Dead Peer Detection alone does not tell which of
 the other paths might work.
 If required by its address selection policy, the initiator can use
 normal IKEv2 INFORMATIONAL request/response messages to test whether
 a certain path works.  Implementations MAY do path testing even if
 the path currently being used is working to, for example, detect when
 a better (but previously unavailable) path becomes available.

3.11. Failure Recovery and Timeouts

 In MOBIKE, the initiator is responsible for detecting and recovering
 from most failures.
 To give the initiator enough time to detect the error, the responder
 SHOULD use relatively long timeout intervals when, for instance,
 retransmitting IKEv2 requests or deciding whether to initiate Dead
 Peer Detection.  While no specific timeout lengths are required, it
 is suggested that responders continue retransmitting IKEv2 requests
 for at least five minutes before giving up.

3.12. Dead Peer Detection

 MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but
 as addresses may change, it is not sufficient to just verify that the
 peer is alive, but also that it is synchronized with the address
 updates and has not, for instance, ignored an address update due to
 failure to complete return routability test.  This means that when
 there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the
 addresses used in those packets and determine that they correspond to
 those that should be employed.  If they do not, such packets SHOULD
 NOT be used as evidence that the peer is able to communicate with
 this node and or that the peer has received all address updates.

Eronen Standards Track [Page 20] RFC 4555 MOBIKE Protocol June 2006

4. Payload Formats

 This specification defines several new IKEv2 Notify payload types.
 See [IKEv2], Section 3.10, for a general description of the Notify
 payload.

4.1. Notify Messages - Error Types

4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload

 The responder can include this notification in an INFORMATIONAL
 exchange response to indicate that the address change in the
 corresponding request message (which contained an UPDATE_SA_ADDRESSES
 notification) was not carried out.
 The Notify Message Type for UNACCEPTABLE_ADDRESSES is 40.  The
 Protocol ID and SPI Size fields are set to zero.  There is no data
 associated with this Notify type.

4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload

 See Section 3.9 for a description of this notification.
 The Notify Message Type for UNEXPECTED_NAT_DETECTED is 41.  The
 Protocol ID and SPI Size fields are set to zero.  There is no data
 associated with this Notify type.

4.2. Notify Messages - Status Types

4.2.1. MOBIKE_SUPPORTED Notify Payload

 The MOBIKE_SUPPORTED notification is included in the IKE_AUTH
 exchange to indicate that the implementation supports this
 specification.
 The Notify Message Type for MOBIKE_SUPPORTED is 16396.  The Protocol
 ID and SPI Size fields are set to zero.  The notification data field
 MUST be left empty (zero-length) when sending, and its contents (if
 any) MUST be ignored when this notification is received.  This allows
 the field to be used by future versions of this protocol.

4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify

      Payloads
 Both parties can include ADDITIONAL_IP4_ADDRESS and/or
 ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and
 INFORMATIONAL exchange request messages; see Section 3.4 and
 Section 3.6 for more detailed description.

Eronen Standards Track [Page 21] RFC 4555 MOBIKE Protocol June 2006

 The Notify Message Types for ADDITIONAL_IP4_ADDRESS and
 ADDITIONAL_IP6_ADDRESS are 16397 and 16398, respectively.  The
 Protocol ID and SPI Size fields are set to zero.  The data associated
 with these Notify types is either a four-octet IPv4 address or a
 16-octet IPv6 address.

4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload

 The NO_ADDITIONAL_ADDRESSES notification can be included in an
 INFORMATIONAL exchange request message to indicate that the exchange
 initiator does not have addresses beyond the one used in the exchange
 (see Section 3.6 for more detailed description).
 The Notify Message Type for NO_ADDITIONAL_ADDRESSES is 16399.  The
 Protocol ID and SPI Size fields are set to zero.  There is no data
 associated with this Notify type.

4.2.4. UPDATE_SA_ADDRESSES Notify Payload

 This notification is included in INFORMATIONAL exchange requests sent
 by the initiator to update addresses of the IKE_SA and IPsec SAs (see
 Section 3.5).
 The Notify Message Type for UPDATE_SA_ADDRESSES is 16400.  The
 Protocol ID and SPI Size fields are set to zero.  There is no data
 associated with this Notify type.

4.2.5. COOKIE2 Notify Payload

 This notification MAY be included in any INFORMATIONAL request for
 return routability check purposes (see Section 3.7).  If the
 INFORMATIONAL request includes COOKIE2, the exchange responder MUST
 copy the notification to the response message.
 The data associated with this notification MUST be between 8 and 64
 octets in length (inclusive), and MUST be chosen by the exchange
 initiator in a way that is unpredictable to the exchange responder.
 The Notify Message Type for this message is 16401.  The Protocol ID
 and SPI Size fields are set to zero.

4.2.6. NO_NATS_ALLOWED Notify Payload

 See Section 3.9 for a description of this notification.
 The Notify Message Type for this message is 16402.  The notification
 data contains the IP addresses and ports from/to which the packet was
 sent.  For IPv4, the notification data is 12 octets long and is
 defined as follows:

Eronen Standards Track [Page 22] RFC 4555 MOBIKE Protocol June 2006

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                      Source IPv4 address                      !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                   Destination IPv4 address                    !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !          Source port          !       Destination port        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 For IPv6, the notification data is 36 octets long and is defined as
 follows:
                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                                                               !
    !                      Source IPv6 address                      !
    !                                                               !
    !                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                                                               !
    !                   Destination IPv6 address                    !
    !                                                               !
    !                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !          Source port          !       Destination port        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The Protocol ID and SPI Size fields are set to zero.

Eronen Standards Track [Page 23] RFC 4555 MOBIKE Protocol June 2006

5. Security Considerations

 The main goals of this specification are to maintain the security
 offered by usual IKEv2 procedures and to counter mobility-related
 threats in an appropriate manner.  This section describes new
 security considerations introduced by MOBIKE.  See [IKEv2] for
 security considerations for IKEv2 in general.

5.1. Traffic Redirection and Hijacking

 MOBIKE payloads relating to updating addresses are encrypted,
 integrity protected, and replay protected using the IKE_SA.  This
 assures that no one except the participants can, for instance, give a
 control message to change the addresses.
 However, as with normal IKEv2, the actual IP addresses in the IP
 header are not covered by the integrity protection.  This means that
 a NAT between the parties (or an attacker acting as a NAT) can modify
 the addresses and cause incorrect tunnel header (outer) IP addresses
 to be used for IPsec SAs.  The scope of this attack is limited mainly
 to denial of service because all traffic is protected using IPsec.
 This attack can only be launched by on-path attackers that are
 capable of modifying IKEv2 messages carrying NAT detection payloads
 (such as Dead Peer Detection messages).  By modifying the IP header
 of these packets, the attackers can lead the peers to believe a new
 NAT or a changed NAT binding exists between them.  The attack can
 continue as long as the attacker is on the path, modifying the IKEv2
 messages.  If this is no longer the case, IKEv2 and MOBIKE mechanisms
 designed to detect NAT mapping changes will eventually recognize that
 the intended traffic is not getting through, and will update the
 addresses appropriately.
 MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
 detect modification, by outsiders, of the addresses in the IP header.
 When this notification is used, communication through NATs and other
 address translators is impossible, so it is sent only when not doing
 NAT Traversal.  This feature is mainly intended for IPv6 and site-to-
 site VPN cases, where the administrators may know beforehand that
 NATs are not present.

5.2. IPsec Payload Protection

 The use of IPsec protection on payload traffic protects the
 participants against disclosure of the contents of the traffic,
 should the traffic end up in an incorrect destination or be subject
 to eavesdropping.

Eronen Standards Track [Page 24] RFC 4555 MOBIKE Protocol June 2006

 However, security associations originally created for the protection
 of a specific flow between specific addresses may be updated by
 MOBIKE later on.  This has to be taken into account if the (outer) IP
 address of the peer was used when deciding what kind of IPsec SAs the
 peer is allowed to create.
 For instance, the level of required protection might depend on the
 current location of the VPN client, or access might be allowed only
 from certain IP addresses.
 It is recommended that security policies, for peers that are allowed
 to use MOBIKE, are configured in a manner that takes into account
 that a single security association can be used at different times
 through paths of varying security properties.
 This is especially critical for traffic selector authorization.  The
 (logical) Peer Authorization Database (PAD) contains the information
 used by IKEv2 when determining what kind of IPsec SAs a peer is
 allowed to create.  This process is described in [IPsecArch], Section
 4.4.3.  When a peer requests the creation of an IPsec SA with some
 traffic selectors, the PAD must contain "Child SA Authorization Data"
 linking the identity authenticated by IKEv2 and the addresses
 permitted for traffic selectors.  See also [Clarifications] for a
 more extensive discussion.
 It is important to note that simply sending IKEv2 packets using some
 particular address does not automatically imply a permission to
 create IPsec SAs with that address in the traffic selectors.
 However, some implementations are known to use policies where simply
 being reachable at some address X implies a temporary permission to
 create IPsec SAs for address X.  Here "being reachable" usually means
 the ability to send (or spoof) IP packets with source address X and
 receive (or eavesdrop) packets sent to X.
 Using this kind of policies or extensions with MOBIKE may need
 special care to enforce the temporary nature of the permission.  For
 example, when the peer moves to some other address Y (and is no
 longer reachable at X), it might be necessary to close IPsec SAs with
 traffic selectors matching X.  However, these interactions are beyond
 the scope of this document.

5.3. Denial-of-Service Attacks against Third Parties

 Traffic redirection may be performed not just to gain access to the
 traffic or to deny service to the peers, but also to cause a denial-
 of-service attack on a third party.  For instance, a high-speed TCP
 session or a multimedia stream may be redirected towards a victim
 host, causing its communications capabilities to suffer.

Eronen Standards Track [Page 25] RFC 4555 MOBIKE Protocol June 2006

 The attackers in this threat can be either outsiders or even one of
 the IKEv2 peers.  In usual VPN usage scenarios, attacks by the peers
 can be easily dealt with if the authentication performed in the
 initial IKEv2 negotiation can be traced to persons who can be held
 responsible for the attack.  This may not be the case in all
 scenarios, particularly with opportunistic approaches to security.
 If the attack is launched by an outsider, the traffic flow would
 normally stop soon due to the lack of responses (such as transport
 layer acknowledgements).  However, if the original recipient of the
 flow is malicious, it could maintain the traffic flow for an extended
 period of time, since it often would be able to send the required
 acknowledgements (see [Aura02] for more discussion).
 It should also be noted, as shown in [Bombing], that without ingress
 filtering in the attacker's network, such attacks are already
 possible simply by sending spoofed packets from the attacker to the
 victim directly.  Furthermore, if the attacker's network has ingress
 filtering, this attack is largely prevented for MOBIKE as well.
 Consequently, it makes little sense to protect against attacks of
 similar nature in MOBIKE.  However, it still makes sense to limit the
 amplification capabilities provided to attackers, so that they cannot
 use stream redirection to send a large number of packets to the
 victim by sending just a few packets themselves.
 This specification includes return routability tests to limit the
 duration of any "third party bombing" attacks by off-path (relative
 to the victim) attackers.  The tests are authenticated messages that
 the peer has to respond to, and can be performed before the address
 change takes effect, immediately afterwards, or even periodically
 during the session.  The tests contain unpredictable data, and only
 someone who has the keys associated with the IKE SA and has seen the
 request packet can properly respond to the test.
 The duration of the attack can also be limited if the victim reports
 the unwanted traffic to the originating IPsec tunnel endpoint using
 ICMP error messages or INVALID_SPI notifications.  As described in
 [IKEv2], Section 2.21, this SHOULD trigger a liveness test, which
 also doubles as a return routability check if the COOKIE2
 notification is included.

5.4. Spoofing Network Connectivity Indications

 Attackers may spoof various indications from lower layers and the
 network in an effort to confuse the peers about which addresses are
 or are not working.  For example, attackers may spoof link-layer
 error messages in an effort to cause the parties to move their
 traffic elsewhere or even to disconnect.  Attackers may also spoof

Eronen Standards Track [Page 26] RFC 4555 MOBIKE Protocol June 2006

 information related to network attachments, router discovery, and
 address assignments in an effort to make the parties believe they
 have Internet connectivity when, in reality, they do not.
 This may cause use of non-preferred addresses or even denial of
 service.
 MOBIKE does not provide any protection of its own for indications
 from other parts of the protocol stack.  These vulnerabilities can be
 mitigated through the use of techniques specific to the other parts
 of the stack, such as validation of ICMP errors [ICMPAttacks], link
 layer security, or the use of [SEND] to protect IPv6 Router and
 Neighbor Discovery.
 Ultimately, MOBIKE depends on the delivery of IKEv2 messages to
 determine which paths can be used.  If IKEv2 messages sent using a
 particular source and destination addresses reach the recipient and a
 reply is received, MOBIKE will usually consider the path working; if
 no reply is received even after retransmissions, MOBIKE will suspect
 the path is broken.  An attacker who can consistently control the
 delivery or non-delivery of the IKEv2 messages in the network can
 thus influence which addresses actually get used.

5.5. Address and Topology Disclosure

 MOBIKE address updates and the ADDITIONAL_IP4_ADDRESS/
 ADDITIONAL_IP6_ADDRESS notifications reveal information about which
 networks the peers are connected to.
 For example, consider a host A with two network interfaces: a
 cellular connection and a wired Ethernet connection to a company LAN.
 If host A now contacts host B using IKEv2 and sends
 ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications, host B
 receives additional information it might not otherwise know.  If host
 A used the cellular connection for the IKEv2 traffic, host B can also
 see the company LAN address (and perhaps further guess that host A is
 used by an employee of that company).  If host A used the company LAN
 to make the connection, host B can see that host A has a subscription
 from this particular cellular operator.
 These additional addresses can also disclose more accurate location
 information than just a single address.  Suppose that host A uses its
 cellular connection for IKEv2 traffic, but also sends an
 ADDITIONAL_IP4_ADDRESS notification containing an IP address
 corresponding to, say, a wireless LAN at a particular coffee shop
 location.  It is likely that host B can now make a much better guess
 at A's location than would be possible based on the cellular IP
 address alone.

Eronen Standards Track [Page 27] RFC 4555 MOBIKE Protocol June 2006

 Furthermore, as described in Section 3.4, some of the addresses could
 also be private addresses behind a NAT.
 In many environments, disclosing address information is not a problem
 (and indeed it cannot be avoided if the hosts wish to use those
 addresses for IPsec traffic).  For instance, a remote access VPN
 client could consider the corporate VPN gateway sufficiently
 trustworthy for this purpose.  Furthermore, the
 ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are
 sent encrypted, so the addresses are not visible to eavesdroppers
 (unless, of course, they are later used for sending IKEv2/IPsec
 traffic).
 However, if MOBIKE is used in some more opportunistic approach, it
 can be desirable to limit the information that is sent.  Naturally,
 the peers do not have to disclose any addresses they do not want to
 use for IPsec traffic.  Also, as noted in Section 3.6, an initiator
 whose policy is to always use the locally configured responder
 address does not have to send any ADDITIONAL_IP4_ADDRESS/
 ADDITIONAL_IP6_ADDRESS payloads.

6. 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 several new IKEv2 notifications whose values
 have been allocated from the "IKEv2 Notify Message Types" namespace.
    Notify Messages - Error Types     Value
    -----------------------------     -----
    UNACCEPTABLE_ADDRESSES            40
    UNEXPECTED_NAT_DETECTED           41
    Notify Messages - Status Types    Value
    ------------------------------    -----
    MOBIKE_SUPPORTED                  16396
    ADDITIONAL_IP4_ADDRESS            16397
    ADDITIONAL_IP6_ADDRESS            16398
    NO_ADDITIONAL_ADDRESSES           16399
    UPDATE_SA_ADDRESSES               16400
    COOKIE2                           16401
    NO_NATS_ALLOWED                   16402
 These notifications are described in Section 4.

Eronen Standards Track [Page 28] RFC 4555 MOBIKE Protocol June 2006

7. Acknowledgements

 This document is a collaborative effort of the entire MOBIKE WG.  We
 would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo
 Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti,
 Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann,
 Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld,
 Maureen Stillman, Shinta Sugimoto, Hannes Tschofenig, and Sami
 Vaarala.  This document also incorporates ideas and text from earlier
 MOBIKE-like protocol proposals, including [AddrMgmt], [Kivinen],
 [MOPO], and [SMOBIKE], and the MOBIKE design document [Design].

8. References

8.1. Normative References

 [IKEv2]           Kaufman, C., "Internet Key Exchange (IKEv2)
                   Protocol", RFC 4306, December 2005.
 [IPsecArch]       Kent, S. and K. Seo, "Security Architecture for the
                   Internet Protocol", RFC 4301, December 2005.
 [KEYWORDS]        Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", RFC 2119, March 1997.

8.2. Informative References

 [AddrMgmt]        Dupont, F., "Address Management for IKE version 2",
                   Work in Progress, November 2005.
 [Aura02]          Aura, T., Roe, M., and J. Arkko, "Security of
                   Internet Location Management",  Proc. 18th Annual
                   Computer Security Applications Conference (ACSAC),
                   December 2002.
 [Bombing]         Dupont, F., "A note about 3rd party bombing in
                   Mobile IPv6", Work in Progress, December 2005.
 [Clarifications]  Eronen, P. and P. Hoffman, "IKEv2 Clarifications
                   and Implementation Guidelines", Work in Progress,
                   February 2006.
 [DNA4]            Aboba, B., Carlson, J., and S. Cheshire, "Detecting
                   Network Attachment in IPv4 (DNAv4)", RFC 4436,
                   March 2006.

Eronen Standards Track [Page 29] RFC 4555 MOBIKE Protocol June 2006

 [DNA6]            Narayanan, S., Daley, G., and N. Montavont,
                   "Detecting Network Attachment in IPv6 - Best
                   Current Practices for hosts", Work in Progress,
                   October 2005.
 [Design]          Kivinen, T. and H. Tschofenig, "Design of the
                   MOBIKE protocol", Work in Progress, January 2006.
 [ICMPAttacks]     Gont, F., "ICMP attacks against TCP", Work in
                   Progress, October 2005.
 [Kivinen]         Kivinen, T., "MOBIKE protocol", Work in Progress,
                   February 2004.
 [MIP4]            Perkins, C., "IP Mobility Support for IPv4",
                   RFC 3344, August 2002.
 [MIP6]            Johnson, D., Perkins, C., and J. Arkko, "Mobility
                   Support in IPv6", RFC 3775, June 2004.
 [MOPO]            Eronen, P., "Mobility Protocol Options for IKEv2
                   (MOPO-IKE)", Work in Progress, February 2005.
 [RFC2461]         Narten, T., Nordmark, E., and W. Simpson, "Neighbor
                   Discovery for IP Version 6 (IPv6)", RFC 2461,
                   December 1998.
 [SEND]            Arkko, J., Kempf, J., Zill, B., and P. Nikander,
                   "SEcure Neighbor Discovery (SEND)", RFC 3971,
                   March 2005.
 [SMOBIKE]         Eronen, P. and H. Tschofenig, "Simple Mobility and
                   Multihoming Extensions for IKEv2 (SMOBIKE)",
                   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.
 [UNSAF]           Daigle, L., "IAB Considerations for UNilateral
                   Self-Address Fixing (UNSAF) Across Network Address
                   Translation", RFC 3424, November 2002.

Eronen Standards Track [Page 30] RFC 4555 MOBIKE Protocol June 2006

Appendix A. Implementation Considerations

A.1. Links from SPD Cache to Outbound SAD Entries

 [IPsecArch], Section 4.4.2, says that "For outbound processing, each
 SAD entry is pointed to by entries in the SPD-S part of the SPD
 cache".  The document does not specify how exactly this "pointing" is
 done, since this is an implementation detail that does not have to be
 standardized.
 However, it is clear that the links between the SPD cache and the SAD
 have to be done correctly to ensure that outbound packets are sent
 over the right SA.  Some implementations are known to have problems
 in this area.
 In particular, simply storing the (remote tunnel header IP address,
 remote SPI) pair in the SPD cache is not sufficient, since the pair
 does not always uniquely identify a single SAD entry.  For instance,
 two hosts behind the same NAT can accidentally happen to choose the
 same SPI value.  The situation can also occur when a host is assigned
 an IP address previously used by some other host, and the SAs
 associated with the old host have not yet been deleted by Dead Peer
 Detection.  This may lead to packets being sent over the wrong SA or,
 if the key management daemon ensures the pair is unique, denying the
 creation of otherwise valid SAs.
 Storing the remote tunnel header IP address in the SPD cache may also
 complicate the implementation of MOBIKE, since the address can change
 during the lifetime of the SA.  Thus, we recommend implementing the
 links between the SPD cache and the SAD in a way that does not
 require modification when the tunnel header IP address is updated by
 MOBIKE.

A.2. Creating Outbound SAs

 When an outbound packet requires IPsec processing but no suitable SA
 exists, a new SA will be created.  In this case, the host has to
 determine (1) who is the right peer for this SA, (2) whether the host
 already has an IKE_SA with this peer, and (3) if no IKE_SA exists,
 the IP address(es) of the peer for contacting it.
 Neither [IPsecArch] nor MOBIKE specifies how exactly these three
 steps are carried out.  [IPsecArch], Section 4.4.3.4, says:

Eronen Standards Track [Page 31] RFC 4555 MOBIKE Protocol June 2006

    For example, assume that IKE A receives an outbound packet
    destined for IP address X, a host served by a security gateway.
    RFC 2401 [RFC2401] and this document do not specify how A
    determines the address of the IKE peer serving X.  However, any
    peer contacted by A as the presumed representative for X must be
    registered in the PAD in order to allow the IKE exchange to be
    authenticated.  Moreover, when the authenticated peer asserts that
    it represents X in its traffic selector exchange, the PAD will be
    consulted to determine if the peer in question is authorized to
    represent X.
 In step 1, there may be more than one possible peer (e.g., several
 security gateways that are allowed to represent X).  In step 3, the
 host may need to consult a directory such as DNS to determine the
 peer IP address(es).
 When performing these steps, implementations may use information
 contained in the SPD, the PAD, and possibly some other
 implementation-specific databases.  Regardless of how exactly the
 steps are implemented, it is important to remember that IP addresses
 can change, and that an IP address alone does not always uniquely
 identify a single IKE peer (for the same reasons as why the
 combination of the remote IP address and SPI does not uniquely
 identify an outbound IPsec SA; see Appendix A.1).  Thus, in steps 1
 and 2 it may be easier to identify the "right peer" using its
 authenticated identity instead of its current IP address.  However,
 these implementation details are beyond the scope of this
 specification.

Author's Address

 Pasi Eronen (editor)
 Nokia Research Center
 P.O. Box 407
 FIN-00045 Nokia Group
 Finland
 EMail: pasi.eronen@nokia.com

Eronen Standards Track [Page 32] RFC 4555 MOBIKE Protocol June 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).

Eronen Standards Track [Page 33]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4555.txt · Last modified: 2006/06/06 03:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki