draft-ietf-mobike-protocol-01.txt   draft-ietf-mobike-protocol-02.txt 
MOBIKE Working Group P. Eronen, Ed. MOBIKE Working Group P. Eronen, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Expires: January 16, 2006 July 15, 2005 Expires: March 16, 2006 September 12, 2005
IKEv2 Mobility and Multihoming Protocol (MOBIKE) IKEv2 Mobility and Multihoming Protocol (MOBIKE)
draft-ietf-mobike-protocol-01.txt draft-ietf-mobike-protocol-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2006. This Internet-Draft will expire on March 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes the MOBIKE protocol, a mobility and This document describes the MOBIKE protocol, a mobility and
multihoming extension to IKEv2. MOBIKE allows mobile and/or multihoming extension to IKEv2. MOBIKE allows hosts to update the
multihomed hosts to update the (outer) IP addresses associated with (outer) IP addresses associated with IKE and IPsec Security
IKE and IPsec Security Associations (SAs). The main scenario for Associations (SAs). A mobile VPN client could use MOBIKE to keep the
MOBIKE is making it possible for a remote access VPN user to move connection with the VPN gateway active while moving from one address
from one address to another while keeping the connection with the VPN to another. Similarly, a multihomed host could use MOBIKE to move
gateway active. the traffic to a different interface if, for instance, the currently
used one stops working.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 MOBIKE protocol overview . . . . . . . . . . . . . . . . . 4 1.2 MOBIKE Protocol Overview . . . . . . . . . . . . . . . . . 4
1.3 Terminology and notations . . . . . . . . . . . . . . . . 5 1.3 Terminology and Notations . . . . . . . . . . . . . . . . 5
2. MOBIKE protocol exchanges . . . . . . . . . . . . . . . . . . 6 2. MOBIKE Protocol Exchanges . . . . . . . . . . . . . . . . . . 6
2.1 Signaling support for MOBIKE . . . . . . . . . . . . . . . 6 2.1 Signaling Support for MOBIKE . . . . . . . . . . . . . . . 6
2.2 Additional addresses . . . . . . . . . . . . . . . . . . . 6 2.2 Additional Addresses . . . . . . . . . . . . . . . . . . . 6
2.3 Changing addresses in IPsec SAs . . . . . . . . . . . . . 7 2.3 Changing Addresses in IPsec SAs . . . . . . . . . . . . . 7
2.4 Updating additional addresses . . . . . . . . . . . . . . 9 2.4 Updating Additional Addresses . . . . . . . . . . . . . . 10
2.5 Path testing . . . . . . . . . . . . . . . . . . . . . . . 10 2.5 Return Routability Check . . . . . . . . . . . . . . . . . 11
2.6 Return routability check . . . . . . . . . . . . . . . . . 11 2.6 Changes in NAT Mappings . . . . . . . . . . . . . . . . . 12
2.7 NAT prevention . . . . . . . . . . . . . . . . . . . . . . 11 2.7 NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 12
3. Payload formats . . . . . . . . . . . . . . . . . . . . . . . 13 2.8 Failure Recovery and Timeouts . . . . . . . . . . . . . . 14
3.1 MOBIKE_SUPPORTED notification payload . . . . . . . . . . 13 3. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 ADDITIONAL_IP4/6_ADDRESS notification payloads . . . . . . 13 3.1 MOBIKE_SUPPORTED Notification Payload . . . . . . . . . . 15
3.3 UPDATE_SA_ADDRESSES notification payload . . . . . . . . . 13 3.2 ADDITIONAL_IP4/6_ADDRESS Notification Payloads . . . . . . 15
3.4 UNACCEPTABLE_ADDRESSES notification payload . . . . . . . 13 3.3 NO_ADDITIONAL_ADDRESSES Notification Payload . . . . . . . 15
3.5 COOKIE2 notification payload . . . . . . . . . . . . . . . 14 3.4 UPDATE_SA_ADDRESSES Notification Payload . . . . . . . . . 15
3.6 NAT_PREVENTION notification payload . . . . . . . . . . . 14 3.5 UNACCEPTABLE_ADDRESSES Notification Payload . . . . . . . 16
3.7 NAT_PREVENTED notification payload . . . . . . . . . . . . 14 3.6 COOKIE2 Notification Payload . . . . . . . . . . . . . . . 16
4. Security considerations . . . . . . . . . . . . . . . . . . . 15 3.7 NO_NATS_ALLOWED Notification Payload . . . . . . . . . . . 16
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 3.8 UNEXPECTED_NAT_DETECTED Notification Payload . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1 Traffic Redirection and Hijacking . . . . . . . . . . . . 17
7.1 Normative references . . . . . . . . . . . . . . . . . . . 19 4.2 IPsec Payload Protection . . . . . . . . . . . . . . . . . 17
7.2 Informative references . . . . . . . . . . . . . . . . . . 19 4.3 Denial-of-Service Attacks Against Third Parties . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 4.4 Spoofing Network Connectivity Indications . . . . . . . . 19
1. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 22 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1 Normative References . . . . . . . . . . . . . . . . . . . 20
7.2 Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23
1. Introduction 1. Introduction
1.1 Motivation 1.1 Motivation
IKEv2 is used for performing mutual authentication and establishing IKEv2 is used for performing mutual authentication and establishing
and maintaining IPsec security associations (SAs). In the current and maintaining IPsec security associations (SAs). In the current
specifications, the IPsec and IKE SAs are created implicitly between specifications, the IPsec and IKE SAs are created implicitly between
the IP addresses that are used when the IKE_SA is established. These 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 IP addresses are then used as the outer (tunnel header) addresses for
skipping to change at page 4, line 5 skipping to change at page 3, line 52
unchanged. Thus, mobility can be (mostly) invisible to applications unchanged. Thus, mobility can be (mostly) invisible to applications
and their connections using the VPN. and their connections using the VPN.
MOBIKE also supports more complex scenarios where the VPN gateway MOBIKE also supports more complex scenarios where the VPN gateway
also has several network interfaces: these interfaces could be also has several network interfaces: these interfaces could be
connected to different networks or ISPs, they may have may be a mix connected to different networks or ISPs, they may have may be a mix
of IPv4 and IPv6 addresses, and the addresses may change over time. of IPv4 and IPv6 addresses, and the addresses may change over time.
Furthermore, both parties could be VPN gateways relaying traffic for Furthermore, both parties could be VPN gateways relaying traffic for
other parties. other parties.
1.2 MOBIKE protocol overview Note that this document does not claim to solve all the problems IETF
MOBIKE working group has been chartered to work on. It is assumed
that issues such as transport mode (updating traffic selectors),
PFKEY extensions, and tunnel overhead reduction will be handled in
separate documents.
1.2 MOBIKE Protocol Overview
Since MOBIKE allows both parties to have several addresses, this Since MOBIKE allows both parties to have several addresses, this
leads us to an important question: there are up to N*M pairs of IP leads us to an important question: there are up to N*M pairs of IP
addresses that could potentially be used. How to decide which of addresses that could potentially be used. How to decide which of
these pairs should be used? The decision has to take into account these pairs should be used? The decision has to take into account
several factors. First, the parties have may preferences about which several factors. First, the parties have may preferences about which
interface should be used, due to performance and cost reasons, for interface should be used, due to performance and cost reasons, for
instance. Second, the decision is constrained by the fact that some instance. Second, the decision is constrained by the fact that some
of the pairs may not work at all due to incompatible IP versions, of the pairs may not work at all due to incompatible IP versions,
outages somewhere in the network, problems at the local link at outages somewhere in the network, problems at the local link at
skipping to change at page 4, line 48 skipping to change at page 5, line 5
changed, are largely beyond the scope of MOBIKE. This does not mean changed, are largely beyond the scope of MOBIKE. This does not mean
that these details are unimportant: on the contrary, they are likely that these details are unimportant: on the contrary, they are likely
to be crucial in any real system. However, MOBIKE is concerned with 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 these details only to the extent that they are visible in IKEv2/IPsec
messages exchanged between the peers (and thus need to be messages exchanged between the peers (and thus need to be
standardized to ensure interoperability). Issues such as mobility standardized to ensure interoperability). Issues such as mobility
detection and local policies are also not specific to MOBIKE, but detection and local policies are also not specific to MOBIKE, but
apply to existing mobility protocols such as Mobile IPv4 [MIP4] as apply to existing mobility protocols such as Mobile IPv4 [MIP4] as
well. well.
One important aspect of this information gathering that has to be
visible in the messages is determining whether a certain pair of
addresses can be used. IKEv2 Dead Peer Detection (DPD) feature can
provide information that the currently used pair does or does not
work. There are, however, some complications in using it for other
addresses, and thus MOBIKE adds a new IKEv2 message that can be used
to "test" whether some particular pair of addresses works or not,
without yet committing to changing the addresses currently in use.
MOBIKE also has to deal with situations where the network contains MOBIKE also has to deal with situations where the network contains
NATs or stateful packet filters (for brevity, the rest of this NATs or stateful packet filters (for brevity, the rest of this
document talks simply about NATs). When the addresses used for IPsec document talks simply about NATs). When the addresses used for IPsec
SAs are changed, MOBIKE can enable or disable IKEv2 NAT Traversal as SAs are changed, MOBIKE can enable or disable IKEv2 NAT Traversal as
needed. However, if the party "outside" the NAT changes its IP needed. However, if the party "outside" the NAT changes its IP
address, it may no longer be able to send packets to the party address, it may no longer be able to send packets to the party
"behind" the NAT, since the packets may not (depending on the exact "behind" the NAT, since the packets may not (depending on the exact
type of NAT) match the NAT mapping state. Here MOBIKE assumes that type of NAT) match the NAT mapping state. Here MOBIKE assumes that
the initiator is the party "behind" the NAT, and does not fully the initiator is the party "behind" the NAT, and does not fully
support the case where the responder's addresses change when NATs are support the case where the responder's addresses change when NATs are
present. present.
Updating the addresses of IPsec SAs naturally has to take into Updating the addresses of IPsec SAs naturally has to take into
account several security considerations. MOBIKE includes two account several security considerations. MOBIKE includes two
features designed to address these considerations. First, a "return features designed to address these considerations. First, a "return
routability" check can be used to verify the addresses provided by routability" check can be used to verify the addresses provided by
the peer. This makes it more difficult to flood third parties with the peer. This makes it more difficult to flood third parties with
large amounts of traffic. Second, a "NAT prevention" feature ensures large amounts of traffic. Second, a "NAT prohibition" feature
that IP addresses have not been modified by NATs, IPv4/IPv6 ensures that IP addresses have not been modified by NATs, IPv4/IPv6
translation agents, or other similar devices. This feature is mainly translation agents, or other similar devices. This feature is mainly
intended for site-to-site VPNs where the administrators may know intended for site-to-site VPNs where the administrators may know
beforehand that NATs are not present, and thus any modification to beforehand that NATs are not present, and thus any modification to
the packet can be considered to be an attack. the packet can be considered to be an attack.
1.3 Terminology and notations 1.3 Terminology and Notations
When messages containing IKEv2 payloads are shown, optional payloads When messages containing IKEv2 payloads are shown, optional payloads
are shown in brackets (for instance, "[FOO]"), and a plus sign are shown in brackets (for instance, "[FOO]"), and a plus sign
indicates that a payload can be repeated one or more times (for indicates that a payload can be repeated one or more times (for
instance, "FOO+"). instance, "FOO+").
When this document talks about updating the source/destination
addresses of an IPsec SA, it means updating IPsec-related state so
that outgoing ESP/AH packets use those addresses in the tunnel
header. Depending on how the nominal division between Security
Association Database (SAD), Security Policy Database (SPD), and Peer
Authorization Database (PAD) described in [IPsecArch] is 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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
2. MOBIKE protocol exchanges 2. MOBIKE Protocol Exchanges
2.1 Signaling support for MOBIKE 2.1 Signaling Support for MOBIKE
Implementations that wish to use MOBIKE for a particular IKE_SA MUST Implementations that wish to use MOBIKE for a particular IKE_SA MUST
include a MOBIKE_SUPPORTED notification in the IKE_SA_INIT request include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in
and response messages. case of multiple IKE_AUTH exchanges, in the message containing the SA
payload).
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni,
N(MOBIKE_SUPPORTED),
[N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP)] -->
<-- HDR, SAr1, KEr, Nr,
[N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP)]
[CERTREQ],
N(MOBIKE_SUPPORTED)
The MOBIKE_SUPPORTED notification payload is described in Section 3. The MOBIKE_SUPPORTED notification payload is described in Section 3.
2.2 Additional addresses 2.2 Additional Addresses
Both the initiator and responder MAY include one or more Both the initiator and responder MAY include one or more
ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notification ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notification
payloads in the IKE_AUTH exchange (in case of multiple IKE_AUTH payloads in the IKE_AUTH exchange (in case of multiple IKE_AUTH
exchanges, in the message containing the SA payload). exchanges, in the message containing the SA payload).
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SK { IDi, [CERT], [IDr], AUTH, HDR, SK { IDi, [CERT], [IDr], AUTH,
[CP(CFG_REQUEST)] [CP(CFG_REQUEST)]
SAi2, TSi, TSr, SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_*_ADDRESS)+] --> [N(ADDITIONAL_*_ADDRESS)+] -->
<-- HDR, SK { IDr, [CERT], AUTH, <-- HDR, SK { IDr, [CERT], AUTH,
[CP(CFG_REPLY)], [CP(CFG_REPLY)],
SAr2, TSi, TSr, SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED)
[N(ADDITIONAL_*_ADDRESS)+] } [N(ADDITIONAL_*_ADDRESS)+] }
The recipient stores this information, but no other action is taken The recipient stores this information, but no other action is taken
at this time. at this time.
2.3 Changing addresses in IPsec SAs 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.
In MOBIKE, the initiator of the IKE_SA decides what addresses are The initiator uses the set of responder addresses as an input to its
used in the IPsec SAs. That is, the responder never updates any address selection policy; it may at some later point decide to move
IPsec SAs without receiving an explicit UPDATE_SA_ADDRESSES request the IPsec traffic to one of these addresses using the procedure
from the initiator. (As described below, the responder can, however, described in Section 2.3. The responder normally does not use the
update the IKE_SA in some circumstances.) set of initiator addresses for anything: the addresses are used only
when the responder's own addresses change.
The description in this section assumes that the initiator has The set of addresses available to the peers can change during the
already decided what the new addresses should be. How this decision lifetime of the IKE_SA. The procedure for updating this information
is made is beyond the scope of this specification. When this is described in Section 2.4.
decision has been made, the initiator
o Updates the IKE_SA and IPsec SAs with the new addresses, and sets Note that if some of the initiator's interfaces are behind a NAT
the "pending_update" flag in the IKE_SA. (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 2.4 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 purposes than what is
explicitly described in this document.
2.3 Changing Addresses in IPsec SAs
In MOBIKE, the initiator decides what addresses are used in the IPsec
SAs. That is, the responder usually never updates 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. Such information itself MUST NOT be used to conclude than
an update is needed: instead, the initiator SHOULD trigger dead peer
detection.
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.
o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS
payloads is received. This means the peer's addresses may have
changed.
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 payload that
does not match the previous UPDATE_SA_ADDRESSES response (see
Section 2.6 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 and the IPsec SAs associated with this IKE_SA
with the new addresses, and sets the "pending_update" flag in the
IKE_SA.
o If NAT Traversal is not enabled, and the responder supports NAT o If NAT Traversal is not enabled, and the responder supports NAT
Traversal (as indicated by NAT detection payloads in the Traversal (as indicated by NAT detection payloads in the
IKE_SA_INIT exchange), and the initiator either suspects or knows IKE_SA_INIT exchange), and the initiator either suspects or knows
that a NAT is likely to be present, enables NAT Traversal. that a NAT is likely to be present, enables NAT Traversal.
o If there are outstanding IKEv2 requests, continues retransmitting 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). them using the addresses in the IKE_SA (the new addresses).
o When the window size allows, sends an INFORMATIONAL request o When the window size allows, sends an INFORMATIONAL request
containing the UPDATE_SA_ADDRESSES notification payload (which containing the UPDATE_SA_ADDRESSES notification payload (which
does not contain any data), and clears the "pending_update" flag. does not contain any data), and clears the "pending_update" flag.
(See Section 2.6 for description of the COOKIE2 notification.)
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SK { N(UPDATE_SA_ADDRESSES), HDR, SK { N(UPDATE_SA_ADDRESSES),
N(COOKIE2),
[N(NAT_DETECTION_*_IP)], [N(NAT_DETECTION_*_IP)],
[N(NAT_PREVENTION)] } --> [N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
o If a new address change occurs while waiting for the response, o If a new address change occurs while waiting for the response,
starts again from the first step (and ignores responses to this starts again from the first step (and ignores responses to this
UPDATE_SA_ADDRESSES request). UPDATE_SA_ADDRESSES request).
Note that if the responder has NAT Traversal enabled, it can update
the addresses in both the IKE_SA and IPsec SAs as usual (if it
implements the "SHOULD" from [IKEv2] Section 2.23).
When processing an INFORMATIONAL request containing the When processing an INFORMATIONAL request containing the
UPDATE_SA_ADDRESSES notification, the responder UPDATE_SA_ADDRESSES notification, the responder
o Determines whether it has already received a newer o Determines whether it has already received a newer
UPDATE_SA_ADDRESSES request than this one (if the responder uses a UPDATE_SA_ADDRESSES request than this one (if the responder uses a
window size greater than one, it is possible that requests are window size greater than one, it is possible that requests are
received out of order). If it has, a response message is sent, received out of order). If it has, a response message is sent,
but no other action is taken. but no other action is taken.
o If the NAT_PREVENTION payload is present, processes it as o If the NO_NATS_ALLOWED payload is present, processes it as
described in Section 2.7. described in Section 2.7.
o Checks that the (source IP address, destination IP address) pair o Checks that the (source IP address, destination IP address) pair
in the IP header is acceptable according to local policy. If it in the IP header is acceptable according to local policy. If it
is not, replies with "HDR, SK {N(COOKIE2), is not, replies with a message containing the
N(UNACCEPTABLE_ADDRESSES)}". UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2).
o Updates the IP addresses in the IKE_SA with the values from the IP 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 header. (Using the address from the IP header is consistent with
normal IKEv2, and allows IKEv2 to work with NATs without needing normal IKEv2, and allows IKEv2 to work with NATs without needing
unilateral self-address fixing [UNSAF].) unilateral self-address fixing [UNSAF].)
o Replies with an INFORMATIONAL response: o Replies with an INFORMATIONAL response:
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
<-- HDR, SK { N(COOKIE2), <-- HDR, SK { [N(NAT_DETECTION_*_IP)],
[N(NAT_DETECTION_*_IP)] } [N(COOKIE2)], }
o If necessary, initiates a return routability check for the new o If necessary, initiates a return routability check for the new
initiator address (see Section 2.6) and waits for the check to initiator address (see Section 2.5) and waits until the check is
finish.. completed.
o Updates the IPsec SAs with the new addresses. o Updates the IPsec SAs associated with this IKE_SA with the new
addresses.
o If NAT Traversal is supported and NAT detection payloads were o If NAT Traversal is supported and NAT detection payloads were
included, enables or disables NAT Traversal. included, enables or disables NAT Traversal.
When the initiator receives the reply, it When the initiator receives the reply, it
o If the response contains the NAT_PREVENTED payload, processes it o If an address change has occured after the request was first sent,
as described in Section 2.7. no MOBIKE processing is done for the reply message, since 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 payload,
processes it as described in Section 2.7.
o If the response contains an UNACCEPTABLE_ADDRESSES notification o If the response contains an UNACCEPTABLE_ADDRESSES notification
payload, the initiator MAY select another addresses and retry the payload, the initiator MAY select another addresses and retry the
exchange, keep on using the current addresses, or disconnect. exchange, keep on using the current addresses, or disconnect.
o If NAT Traversal is supported and NAT detection payloads were o If NAT Traversal is supported and NAT detection payloads were
included, enables or disables NAT Traversal. included, enables or disables NAT Traversal.
2.4 Updating additional addresses 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 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).
As described in Section 2.2, both the initiator and responder can 2.4 Updating Additional Addresses
send a list of additional addresses (in addition to the one used for
IKE_SA_INIT/IKE_AUTH exchange) to the initiator in the IKE_AUTH
exchange. If this list of addresses changes, a new list can be sent
in any INFORMATIONAL exchange request message.
When the responder (of the original IKE_SA) receives an INFORMATIONAL As described in Section 2.2, both the initiator and responder can
request containing ADDITIONAL_*_ADDRESS payloads, it simply stores send a list of additional addresses in the IKE_AUTH exchange. This
the information, but no other action is taken. information can be updated by sending an INFORMATIONAL exchange
request message that contains either one or more ADDITIONAL_IP4/
6_ADDRESS payloads or the NO_ADDITIONAL_ADDRESSES payload.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SK { N(ADDITIONAL_*_ADDRESS)+, HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
N(COOKIE2) } --> [N(NO_ADDITIONAL_ADDRESSES)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
<-- HDR, SK { N(COOKIE2) } <-- HDR, SK { [N(COOKIE2)] }
When the initiator receives an INFORMATIONAL request containing When a request containing ADDITIONAL_*_ADDRESS or
ADDITIONAL_*_ADDRESS, it stores the information and also determines NO_ADDITIONAL_ADDRESSES payloads is received, the exchange responder
whether the currently used addresses need to be changed (for
instance, if the currently used address is no longer included in the
list); if it does, the initiator proceeds as described in
Section 2.3.
Initiator Responder o Determines whether it has already received a newer request to
----------- ----------- update the addresses (if a window size greater than one is used,
<-- HDR, SK { N(ADDITIONAL_*_ADDRESS)+, it is possible that the requests are received out of order). If
N(COOKIE2) } it has, a response message is sent, but the address set is not
updated.
HDR, SK { N(COOKIE2) } --> o If the NO_NATS_ALLOWED payload is present, processes it as
described in Section 2.7.
If the implementation supports window sizes greater than one, it also o Updates the set of peer addresses based on the IP header and
has to keep track of the Message ID of the latest update it has ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESS payloads.
received, to avoid the situation where new information is overwritten
by older. o Sends a response.
The initiator MAY include these payloads 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 There is one additional complication: when the responder wants to
send a new additional address list, the currently used addresses may update the address set, the currently used addresses may no longer
no longer work. In this case, the responder uses the additional work. In this case, the responder uses the additional address list
address list received from the initiator, the list of its own received from the initiator and the list of its own addresses to
addresses, and, if necessary, the path testing feature (see determine which addresses to use for sending the INFORMATIONAL
Section 2.5) to determine a path that works, updates the addresses in
the IKE_SA (but not IPsec SAs), and then sends the INFORMATIONAL
request. This is the only time the responder uses the additional request. This is the only time the responder uses the additional
address list received from the initiator. address list received from the initiator.
Note that both peers can have their own policies about what addresses Note that both peers can have their own policies about what addresses
are acceptable to use. A minimal "mobile client" could have a policy are acceptable to use. A minimal "mobile client" could have a policy
that says that only the responder's address specified in local that says that only the responder's address specified in local
configuration is acceptable. This kind of client does not have to configuration is acceptable. This kind of client does not have to
send or process ADDITIONAL_*_ADDRESS notification payloads. send or process ADDITIONAL_*_ADDRESS notification payloads.
Similarly, a simple "VPN gateway" that has only a single address, and Similarly, a simple "VPN gateway" that has only a single address, and
is not going to change it, does not need to send or understand is not going to change it, does not need to send or understand
ADDITIONAL_*_ADDRESS notification payloads. ADDITIONAL_*_ADDRESS notification payloads.
2.5 Path testing 2.5 Return Routability Check
IKEv2 Dead Peer Detection allows the peers to detect if the currently
used path has stopped working. However, if either of the peers has
several addresses, DPD alone does not indicate which of the other
paths might work. The path testing feature allows the parties to
determine whether a particular path (pair of addresses) works,
without yet committing to changing over to these addresses.
MOBIKE introduces a new IKEv2 exchange type, PATH_TEST, for testing
connectivity. This exchange is not part of any IKE_SA, so it is not
cryptographically protected. It also does not result in the
responder keeping any state.
Initiator Responder
----------- -----------
HDR(0,0), N(COOKIE2),
[N(NAT_DETECTION_*_IP)] -->
<-- HDR(0,0), N(COOKIE2),
[N(NAT_DETECTION_*_IP)]
The reason for introducing a new exchange type, instead of using
INFORMATIONAL exchanges, is to simplify implementations by allowing
MOBIKE to work with window size 1.
Performing path testing over several different paths is not required
if the node has other information that enables it to select which
path should be used. Also, responders do not perform path testing
unless they update their list of additional addresses (as described
in Section 2.4). Implementations MAY do path testing even if the
currently used path is working to e.g. detect when a better but
previously unavailable path becomes available, or to speed up
recovery in fault situations.
Implementations that perform path testing MUST take steps to avoid
causing unnecessary congestion. TBD: add some more details here.
2.6 Return routability check
Both the initiator and the responder can optionally verify that the Both parties can optionally verify that the other party can actually
other party can actually receive packets at the claimed address. receive packets at the claimed address. This "return routability
This "return routability check" MAY be done before updating the IPsec check" can be done before updating the IPsec SAs, immediately after
SAs, immediately after updating them, or continuously during the updating them, or continuously during the connection.
connection.
By default, return routability check SHOULD be done before updating By default, return routability check SHOULD be done before updating
the IPsec SAs. In environments where the peer is expected to be the IPsec SAs. In environments where the peer is expected to be
well-behaving (many corporate VPNs, for instance), or the address can well-behaving (many corporate VPNs, for instance), or the address can
be verified by some other means (e.g., the address is included in the be verified by some other means (e.g., the address is included in the
peer's certificate), the return routability check MAY be skipped or peer's certificate), the return routability check MAY be skipped or
postponed until after the IPsec SAs have been updated. postponed until after the IPsec SAs have been updated.
Any INFORMATIONAL exchange can be used for return routability Any INFORMATIONAL exchange can be used for return routability
purposes (with one exception, described below): when a valid response purposes (with one exception, described below): when a valid response
is received, we know the other party can receive packets at the is received, we know the other party can receive packets at the
claimed address. claimed address.
To ensure that the peer cannot generate the correct INFORMATIONAL To ensure that the peer cannot generate the correct INFORMATIONAL
response without seeing the request, a new payload is added to all response without seeing the request, a new payload is added to
INFORMATIONAL messages. The sender of an INFORMATIONAL request MUST INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY
include a COOKIE2 notification payload, and the recipient of an include a COOKIE2 notification payload, and if included, the
INFORMATIONAL request MUST copy the payload as-is to the response. recipient of an INFORMATIONAL request MUST copy the payload as-is to
When processing the response, the original sender MUST verify that the response. When processing the response, the original sender MUST
the value is the same one as sent. If the values do not match, the verify that the value is the same one as sent. If the values do not
IKE_SA MUST be closed. match, the IKE_SA MUST be closed.
There is one additional issue that must be taken into account. If There is one additional issue that must be taken into account. If
the INFORMATIONAL request has been sent to several different the INFORMATIONAL request has been sent to several different
addresses (i.e., the destination address in the IKE_SA has been addresses (i.e., the destination address in the IKE_SA has been
updated after the request was first sent), receiving the updated after the request was first sent), receiving the
INFORMATIONAL response does not tell which address is the working INFORMATIONAL response does not tell which address is the working
one. In this case, a new INFORMATIONAL request needs to be sent to one. In this case, a new INFORMATIONAL request needs to be sent to
check return routability. check return routability.
2.7 NAT prevention 2.6 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 internal is too long, or
the NAT box is rebooted). More specifically, if both peers support
both this specification and NAT Traversal, NAT_DETECTION_*_IP
payloads 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, it SHOULD include these payloads
in DPD messages, and compare the received
NAT_DETECTION_DESTINATION_IP payload 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 2.3.
When MOBIKE is in use, the host not behind a NAT SHOULD NOT use the
dynamic updates specified in [IKEv2] Section 2.23 (where the peer
address and port are updated from the last valid authenticated
packet). This ensures that both peers have a consistent view of when
addresses are to be changed, and prevents conflicts between MOBIKE-
originated updates and NAT-T dynamic updates. It also means 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.
2.7 NAT Prohibition
IKEv2/IPsec implementations that do not support NAT Traversal can, in IKEv2/IPsec implementations that do not support NAT Traversal can, in
fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6 fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6
translation agents in tunnel mode. This may be considered a problem translation agents in tunnel mode. This may be considered a problem
in some circumstances, since in some sense any modification of the IP in some circumstances, since in some sense any modification of the IP
addresses can be considered to be an attack. addresses can be considered to be an attack.
The "NAT prevention" feature allows both the initiator and responder The "NAT prohibition" feature allows the initiator to have a policy
to have a policy that prevents the use of paths that contain NATs, that prevents the use of paths that contain NATs, IPv4/IPv6
IPv4/IPv6 translation agents, or other nodes that modify the translation agents, or other nodes that modify the addresses in the
addresses in the IP header. This feature is mainly intended for IP header. This feature is mainly intended for site-to-site VPN
site-to-site VPN cases, where the administrators may know beforehand cases, where the administrators may know beforehand that NATs are not
that NATs are not present, and thus any modification to the packet present, and thus any modification to the packet can be considered to
can be considered to be an attack. be an attack.
This specification addresses the issue as follows. When an IPsec SA This specification addresses the issue as follows. When an IPsec SA
is created, the tunnel header IP addresses (and port if doing UDP is created, the tunnel header IP addresses (and port if doing UDP
encapsulation) are taken from the IKE_SA, not the message IP header. encapsulation) are taken from the IKE_SA, not the message IP header.
The NAT_PREVENTION payload is used to guarantee that NATs have not The NO_NATS_ALLOWED payload is used to guarantee that NATs have not
modified the address used in IKE_SA. However, all response messages modified the address used in IKE_SA. However, all response messages
are still sent to the address and port the corresponding request came are still sent to the address and port the corresponding request came
from. from.
The initiator MAY include a NAT_PREVENTION payload in an IKE_SA_INIT An initiator who wishes to use this feature includes a
request. The responder then MUST calculate the expected value based NO_NATS_ALLOWED payload in the IKE_SA_INIT request. The responder
on the values from the IP header, and compare this with the value in then MUST calculate the expected value based on the values from the
the NAT_PREVENTION payload. If they do not match, the responder IP header, and compare this with the value in the NO_NATS_ALLOWED
replies with "HDR(A,0), N(NAT_PREVENTED)" and does not create any payload. If they do not match, the responder replies with "HDR(A,0),
state. N(UNEXPECTED_NAT_DETECTED)" and does not create any state.
Initiator Responder
----------- -----------
HDR, [N(COOKIE)],
SAi1, KEi, Ni,
[N(NO_NATS_ALLOWED)] -->
<-- HDR, SAr1, KEr, Nr,
[CERTREQ]
If the values do match, the responder initializes (local_address, If the values do match, the responder initializes (local_address,
local_port, peer_address, peer_port) in the to-be-created IKE_SA with local_port, peer_address, peer_port) in the to-be-created IKE_SA with
values from the IP header. The same applies if neither values from the IP header. The same applies if neither
NAT_PREVENTION nor NAT_DETECTION_*_IP payloads were included, or if NO_NATS_ALLOWED nor NAT_DETECTION_*_IP payloads were included, or if
the responder does not support NAT Traversal. the responder does not support NAT Traversal.
If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but
no NAT_PREVENTION payload, the situation is different since the no NO_NATS_ALLOWED payload, the situation is different since the
initiator may at this point change from port 500 to 4500. In this initiator may at this point change from port 500 to 4500. In this
case, the responder initializes (local_address, local_port, case, the responder initializes (local_address, local_port,
peer_address, peer_port) from the first IKE_AUTH request. peer_address, peer_port) from the first IKE_AUTH request.
IKEv2 requires that if an IPsec endpoint discovers a NAT between it IKEv2 requires that if an IPsec endpoint discovers a NAT between it
and its correspondent, it MUST send all subsequent traffic to and and its correspondent, it MUST send all subsequent traffic to and
from port 4500. To simplify things, implementations that support from port 4500. To simplify things, implementations that support
both this specification and NAT Traversal MUST change to port 4500 if both this specification and NAT Traversal MUST change to port 4500 if
the correspondent also supports both, even if no NAT was detected the correspondent also supports both, even if no NAT was detected
between them. between them (this way, there is no need to change the ports later).
NAT_PREVENTION payloads can also be included when changing the NO_NATS_ALLOWED payloads can also be included when changing the
addresses of IPsec SAs (see Section 2.3). TBD: add better addresses of IPsec SAs (see Section 2.3) and updating the additional
description. addresses (see Section 2.4). An initiator using this "NAT
prohibition" feature includes a NO_NATS_ALLOWED payload in all
address update messages.
3. Payload formats If the initiator receives an UNEXPECTED_NAT_DETECTION notification in
response to its request, it SHOULD retry the operation several times
using new IKE_SA_INIT/INFORMATIONAL requests. This ensures that an
attacker who is able to modify only a single packet does not
unnecessarily cause a path to remain unused.
3.1 MOBIKE_SUPPORTED notification payload 2.8 Failure Recovery and Timeouts
The MOBIKE_SUPPORTED notification payload is included in the In MOBIKE, the initiator is responsible for detecting and recovering
IKE_SA_INIT messages to indicate that the implementation supports from most failures.
this specification.
The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA To give the initiator enough time to detect the error, the responder
(16396..40959). The Protocol ID and SPI Size fields are set to zero. SHOULD use relatively long timeout intervals when, for instance,
There is no data associated with this Notify type. retransmitting IKEv2 requests or deciding whether to initiate dead
peer detection.
3.2 ADDITIONAL_IP4/6_ADDRESS notification payloads 3. Payload Formats
Both initiator and responder can include ADDITIONAL_IP4_ADDRESS 3.1 MOBIKE_SUPPORTED Notification Payload
and/or ADDITIONAL_IP6_ADDRESS payloads in the IKE_AUTH exchange and
The MOBIKE_SUPPORTED notification payload is included in the IKE_AUTH
exchange to indicate that the implementation supports this
specification.
The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-
IANA(16396..40959). The Protocol ID and SPI Size fields are set to
zero. There is no data associated with this Notify type.
3.2 ADDITIONAL_IP4/6_ADDRESS Notification Payloads
Both parties can include ADDITIONAL_IP4_ADDRESS and/or
ADDITIONAL_IP6_ADDRESS payloads in the IKE_AUTH exchange and
INFORMATIONAL exchange request messages; see Section 2.2 and INFORMATIONAL exchange request messages; see Section 2.2 and
Section 2.4 for more detailed description. Section 2.4 for more detailed description.
The Notify Message Types for ADDITIONAL_IP4_ADDRESS and The Notify Message Types for ADDITIONAL_IP4_ADDRESS and
ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA (16396..40959) and TBD-BY-IANA ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA(16396..40959) and TBD-BY-
(16396..40959), respectively. The Protocol ID and SPI Size fields IANA(16396..40959), respectively. The Protocol ID and SPI Size
are set to zero. The data associated with these Notify types is fields are set to zero. The data associated with these Notify types
either a four-octet IPv4 address or a 16-octet IPv6 address. is either a four-octet IPv4 address or a 16-octet IPv6 address.
3.3 UPDATE_SA_ADDRESSES notification payload 3.3 NO_ADDITIONAL_ADDRESSES Notification Payload
The NO_ADDITIONAL_ADDRESSES payload can be included in an
INFORMATIONAL exchange request messages to indicate that the exchange
initiator does not have addresses beyond the one used in the exchange
(see Section 2.4 for more detailed description).
The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-
IANA(16396..40959). The Protocol ID and SPI Size fields are set to
zero. There is no data associated with this Notify type.
3.4 UPDATE_SA_ADDRESSES Notification Payload
This payload is included in INFORMATIONAL exchange requests sent by This payload is included in INFORMATIONAL exchange requests sent by
the initiator of the IKE_SA to update addresses of the IKE_SA and the initiator to update addresses of the IKE_SA and IPsec SAs (see
IPsec SAs (see Section 2.3). Section 2.3).
The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-
(16396..40959). The Protocol ID and SPI Size fields are set to zero. IANA(16396..40959). The Protocol ID and SPI Size fields are set to
There is no data associated with this Notify type. zero. There is no data associated with this Notify type.
3.4 UNACCEPTABLE_ADDRESSES notification payload 3.5 UNACCEPTABLE_ADDRESSES Notification Payload
The responder can include this notification payload in an The responder can include this notification payload in an
INFORMATIONAL exchange response to indicate that the address change INFORMATIONAL exchange response to indicate that the address change
in the corresponding request message (which contained an in the corresponding request message (which contained an
UPDATE_SA_ADDRESSES notification payload) was not carried out. UPDATE_SA_ADDRESSES notification payload) was not carried out.
The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-
(40..8191). The Protocol ID and SPI Size fields are set to zero. IANA(40..8191). The Protocol ID and SPI Size fields are set to zero.
There is no data associated with this Notify type. There is no data associated with this Notify type.
3.5 COOKIE2 notification payload 3.6 COOKIE2 Notification Payload
This payload is included in all INFORMATIONAL exchange messages for This payload MAY be included in any INFORMATIONAL request for return
return routability check purposes (see Section 2.6). It is also used routability check purposes (see Section 2.5). If the INFORMATIONAL
in PATH_TEST messages to match requests and responses (see request includes COOKIE2, the exchange responder MUST copy the
Section 2.5). payload to the response message.
The data associated with this notification MUST be between 8 and 64 The data associated with this notification MUST be between 8 and 64
octets in length (inclusive), and MUST be chosen in a way that is octets in length (inclusive), and MUST be chosen by the exchange
unpredictable to the recipient. The Notify Message Type for this initiator in a way that is unpredictable to the exchange responder.
message is TBD-BY-IANA (16396..40959). The Protocol ID and SPI Size The Notify Message Type for this message is TBD-BY-
fields are set to zero. IANA(16396..40959). The Protocol ID and SPI Size fields are set to
zero.
3.6 NAT_PREVENTION notification payload 3.7 NO_NATS_ALLOWED Notification Payload
See Section 2.7 for a description of this payload. See Section 2.7 for a description of this payload.
The data associated with this notification is the SHA-1 hash The data associated with this notification is the SHA-1 hash
[FIPS180-2] of the following data: IKE SPIs (in the order they appear [FIPS180-2] of the following data: IKE SPIs (in the order they appear
in the header), the IP address and port from which the packet was in the header), the IP address and port from which the packet was
sent, and the IP address and port to which the packet was sent. The sent, and the IP address and port to which the packet was sent. The
Notify Message Type for this message is TBD-BY-IANA (16396..40959). Notify Message Type for this message is TBD-BY-IANA (16396..40959).
The Protocol ID and SPI Size fields are set to zero. The Protocol ID and SPI Size fields are set to zero.
3.7 NAT_PREVENTED notification payload 3.8 UNEXPECTED_NAT_DETECTED Notification Payload
See Section 2.7 for a description of this payload. See Section 2.7 for a description of this payload.
The Notify Message Type for NAT_PREVENTED is TBD-BY-IANA (40..8191). The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-
The Protocol ID and SPI Size fields are set to zero. There is no IANA(40..8191). The Protocol ID and SPI Size fields are set to zero.
data associated with this Notify type. There is no data associated with this Notify type.
4. Security considerations 4. Security Considerations
The main goals of this specification are to not reduce the security The main goals of this specification are to not reduce the security
offered by usual IKEv2 procedures and to counter mobility related offered by usual IKEv2 procedures and to counter mobility related
threats in an appropriate manner. In some specific cases MOBIKE is threats in an appropriate manner. This section describes new
also capable of protecting address changes better than existing NAT security considerations introduced by MOBIKE. See [IKEv2] for
Traversal procedures. security considerations for IKEv2 in general.
The threats arising in scenarios targeted by MOBIKE are:
Traffic redirection and hijacking
Insecure mobility management mechanisms may allow inappropriate
redirection of traffic. This may allow inspection of the
traffic as well as man-in-the-middle and session hijacking
attacks.
The scope of these attacks in the MOBIKE case is limited, as
all traffic is protected using IPsec. However, it should be
observed that security associations originally created for the
protection of a specific flow between specific addresses may be
moved through MOBIKE. The level of required protection may be
different in a new location of a VPN client, for instance.
Third-party denial-of-service through flooding
Traffic redirection may be performed not just to gain access to
the traffic, but also to cause a denial-of-service attack for 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.
The attackers in this threat can be either outsiders or even
one of the participants. In usual VPN usage scenarios attacks
by participants can be easily dealt with. However, this
requires that strong authentication was performed in the
initial IKEv2 negotiation. This may not be the case in all
scenarios, particularly with opportunistic approaches to
security.
Normally such attacks would expire in a short time frame due to
the lack of responses (such as transport layer
acknowledgements) from the victim. However, as described in
[Aura02], malicious participants would typically be able to
spoof such acknowledgements and maintain the traffic flow for
an extended period of time. For instance, if the attacker
opened the TCP stream itself before redirecting it to the
victim, the attacker becomes aware of the sequence number space
used in this particular session.
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. 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 1000 packets to the victim by
sending just a few packets themselves.
Note that a variant of the flooding attack exists in IKEv2 NAT
Traversal functionality [PseudoNAT]. In this variant, the
attacker has to be on the path between the participants,
changing the addresses in the packets that pass by. This
attack is possible because the addresses in the outer headers
are not protected. When the attacker leaves the path, the
correct situation is restored after the exchange of the next
packets between the participants.
Spoofing indications related to network connectivity
Attackers may also 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 ICMP error messages in an effort to cause the parties to
move their traffic elsewhere or even to disconnect. Attackers
may also spoof 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- 4.1 Traffic Redirection and Hijacking
of-service.
Denial-of-service of the participants through MOBIKE MOBIKE payload 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.
Inappropriate MOBIKE protocol mechanisms might make it possible However, just like with normal IKEv2, the actual IP addresses in the
for attackers to disconnect the participants, or to move them IP header are not covered by the integrity protection. This means
to non-operational addresses. 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, since all traffic is protected
using IPsec.
MOBIKE addresses these threats using the following countermeasures: MOBIKE introduces the NO_NATS_ALLOWED payload that can be used to
detect modification of the addresses in the IP header by outsiders
When this payload is used, communication through NATs and other
address translators is impossible. This feature is mainly intended
for site-to-site VPN cases, where the administrators may know
beforehand that valid NATs are not present, and thus any modification
to the packet can be considered to be an attack. However, this
feature SHOULD NOT be enabled by default, since it creates a denial-
of-service vulnerability even when no malicious attackers are
present: a misconfiguration or introduction of a (non-malicious) NAT
can cause the connection to fail.
Payload traffic protection 4.2 IPsec Payload Protection
The use of IPsec protection on payload traffic protects the The use of IPsec protection on payload traffic protects the
participants against disclosure of the contents of the traffic, participants against disclosure of the contents of the traffic,
should the traffic end up in an incorrect destination. It is should the traffic end up in an incorrect destination or be
recommended that security policies be configured in a manner eavesdropped along the way.
that takes into account that a single security association can
be used through different paths at different times.
Protection of MOBIKE payloads However, security associations originally created for the protection
of a specific flow between specific addresses may be moved through
MOBIKE. The level of required protection may be different in a new
location of a VPN client, for instance.
The payloads used in MOBIKE are encrypted, integrity protected, It is recommended that security policies for peers that are allowed
and replay protected. This assures that no one except the to use MOBIKE are configured in a manner that takes into account that
participants can, for instance, give a control message to a single security association can be used through different paths at
change the addresses. different times.
Note, however, that the actual IP address communicated in these 4.3 Denial-of-Service Attacks Against Third Parties
messages is in the outer IP header and not protected, just as
in IKEv2 NAT Traversal. MOBIKE adds the NAT_PREVENTION
payload, however, which can be used to prevent modifications by
outsiders. Where this payload is used, communication through
NATs and other address translators is impossible, however.
This feature is mainly intended for site-to-site VPN cases,
where the administrators may know beforehand that NATs are not
present, and thus any modification to the packet can be
considered to be an attack.
Explicit address change Traffic redirection may be performed not just to gain access to the
traffic (not very interesting since it is encrypted) or deny service
to the peers, but also to cause a denial-of-service attack for 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.
MOBIKE allows only address changes that are explicitly The attackers in this threat can be either outsiders or even one of
requested. This provides additional security beyond to what the participants. In usual VPN usage scenarios, attacks by the
IKEv2 NAT Traversal has, but it should be noted that the participants can be easily dealt with if the authentication performed
benefits of this can only be realized when MOBIKE is used in the initial IKEv2 negotiation can be traced to persons who can be
without intervening NATs and NAT Traversal. held responsible for the attack. This may not be the case in all
scenarios, particularly with opportunistic approaches to security.
When NAT Traversal is supported, the peer's address may be Normally such attacks would expire in a short time frame due to the
updated automatically to allow changes in NAT mappings. The lack of responses (such as transport layer acknowledgements) from the
"continued return routability" feature, implemented by the victim. However, as described in [Aura02], malicious participants
COOKIE2 payload, allows verification of the new address after would typically be able to spoof such acknowledgements and maintain
the change. This limits the duration of any "third party the traffic flow for an extended period of time. For instance, if
bombing" attack by off-path (relative to the victim) attackers. the attacker opened the TCP stream itself before redirecting it to
the victim, the attacker becomes aware of the sequence number space
used in this particular session.
Return routability tests 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 1000 packets to the victim by sending
just a few packets themselves.
This specification requires the use of return routability tests This specification requires the use of return routability tests
(under certain conditions) to ensure that third party flooding (under certain conditions) to limit the duration of any "third party
attacks are prevented. The tests are authenticated messages bombing" attacks by off-path (relative to the victim) attackers. The
that the peer has to respond to in order for the address change tests are authenticated messages that the peer has to respond to, and
to be committed to. The tests contain unpredictable data, and can be performed either before the address change takes effect,
can only be properly responded to by someone who has the keys immediately afterwards, or even periodically during the session. The
associated with the IKEv2 security association and who has seen tests contain unpredictable data, and only someone who has the keys
the request packet for the test. associated with the IKE SA and has seen the request packet can
properly respond to the test.
4.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
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 MOBIKE does not provide any protection of its own for indications
from other parts of the protocol stack. However, MOBIKE is resistant from other parts of the protocol stack. These vulnerabilities can be
to incorrect information from these sources in the sense that it mitigated through the use of techniques specific to the other parts
provides its own security for both the signaling of addressing of the stack, such as properly dealing with ICMP errors
information as well as actual payload data transmission. Denial-of- [ICMPAttacks], link layer security, or the use of [SEND] to protect
service vulnerabilities remain, however. Some aspects of these IPv6 Router and Neighbor Discovery.
vulnerabilities can be mitigated through the use of techniques
specific to the other parts of the stack, such as properly dealing
with ICMP errors [ICMPAttacks], link layer security, or the use of
[SEND] to protect IPv6 Router and Neighbor Discovery.
5. IANA considerations 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. IANA Considerations
This document does not create any new namespaces to be maintained by This document does not create any new namespaces to be maintained by
IANA, but it requires new values in namespaces that have been defined IANA, but it requires new values in namespaces that have been defined
in the IKEv2 base specification [IKEv2]. in the IKEv2 base specification [IKEv2].
This document defines one new IKEv2 exchange, "PATH_TEST", whose This defines several new IKEv2 notification payloads whose values are
value is to be allocated from the "IKEv2 Exchange Types" namespace. to be allocated from the "IKEv2 Notification Payload Types"
This exchange is described in Section 2.5. namespace. These notification payloads are described in Section 3.
This document also defines several new IKEv2 notification payloads
whose values are to be allocated from the "IKEv2 Notification Payload
Types" namespace. These notification payloads are described in
Section 3.
6. Acknowledgements 6. Acknowledgements
This document is a collaborative effort of the entire MOBIKE WG. We This document is a collaborative effort of the entire MOBIKE WG. We
would particularly like to thank Jari Arkko, Francis Dupont, Paul would particularly like to thank Jari Arkko, Francis Dupont, Paul
Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also
incorporates ideas and text from earlier MOBIKE protocol proposals, incorporates ideas and text from earlier MOBIKE protocol proposals,
including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the
MOBIKE design document [Design]. MOBIKE design document [Design].
7. References 7. References
7.1 Normative references 7.1 Normative References
[FIPS180-2] [FIPS180-2]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Specifications for the Secure Hash Standard", Federal "Specifications for the Secure Hash Standard", Federal
Information Processing Standard (FIPS) Publication 180-2, Information Processing Standard (FIPS) Publication 180-2,
August 2002. August 2002.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004. October 2004.
[KEYWORDS] [KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[UDPEncap] [UDPEncap]
Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
7.2 Informative references 7.2 Informative References
[AddrMgmt] [AddrMgmt]
Dupont, F., "Address Management for IKE version 2", Dupont, F., "Address Management for IKE version 2",
draft-dupont-ikev2-addrmgmt-07 (work in progress), draft-dupont-ikev2-addrmgmt-07 (work in progress),
May 2005. May 2005.
[Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
Location Management", Proc. 18th Annual Computer Security Location Management", Proc. 18th Annual Computer Security
Applications Conference (ACSAC), December 2002. Applications Conference (ACSAC), December 2002.
skipping to change at page 19, line 52 skipping to change at page 21, line 6
[Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE
protocol", draft-ietf-mobike-design-02 (work in progress), protocol", draft-ietf-mobike-design-02 (work in progress),
February 2005. February 2005.
[ICMPAttacks] [ICMPAttacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-gont-tcpm-icmp-attacks-03 (work in progress), draft-gont-tcpm-icmp-attacks-03 (work in progress),
December 2004. December 2004.
[IPsecArch]
Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
in progress), March 2005.
[Kivinen] Kivinen, T., "MOBIKE protocol", [Kivinen] Kivinen, T., "MOBIKE protocol",
draft-kivinen-mobike-protocol-00 (work in progress), draft-kivinen-mobike-protocol-00 (work in progress),
February 2004. February 2004.
[MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO- [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO-
IKE)", draft-eronen-mobike-mopo-02 (work in progress), IKE)", draft-eronen-mobike-mopo-02 (work in progress),
February 2005. February 2005.
skipping to change at page 20, line 42 skipping to change at page 22, line 5
Author's Address Author's Address
Pasi Eronen (editor) Pasi Eronen (editor)
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Email: pasi.eronen@nokia.com Email: pasi.eronen@nokia.com
1. Changelog Appendix A. Changelog
(This section should be removed by the RFC editor.) (This section should be removed by the RFC editor.)
Changes from -01 to -02:
o Moved MOBIKE_SUPPORTED from IKE_SA_INIT to IKE_AUTH (issues 35,
37).
o Changed terminology related to NAT prohibition (issues 22, 24).
o Rewrote much of the ADDITIONAL_*_ADDRESS text, added
NO_ADDITIONAL_ADDRESSES notification.
o Use NAT detection payloads to detect changes in NAT mappings
(issue 34).
o Removed separate PATH_TEST message (issue 34).
o Clarified processing of UNACCEPTABLE_ADDRESSES when request has
been sent using several different addresses (issue 36).
o Clarified changing of ports 500/4500 (issue 33).
o Updated security considerations (issues 27 and 28).
o No need to include COOKIE2 in non-RR messages (issue 32).
o Many editorial fixes and clarifications (issue 38, 40).
o Use the terms initiator and responder more consistently.
o Clarified that this document does not solve all problems in MOBIKE
WG charter (issue 40).
Changes from -00 to -01: Changes from -00 to -01:
o Editorial fixes and small clarifications (issues 21, 25, 26, 29). o Editorial fixes and small clarifications (issues 21, 25, 26, 29).
o Use Protocol ID zero for notifications (issue 30). o Use Protocol ID zero for notifications (issue 30).
o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue
23). 23).
o Use the word "path" only in senses that include the route taken o Use the word "path" only in senses that include the route taken
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/