1852 lines
77 KiB
Plaintext
1852 lines
77 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|