< draft-ietf-mobike-protocol-00.txt   draft-ietf-mobike-protocol-01.txt >
Network Working Group P. Eronen, Ed. MOBIKE Working Group P. Eronen, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Expires: December 30, 2005 June 28, 2005 Expires: January 16, 2006 July 15, 2005
IKEv2 Mobility and Multihoming Protocol (MOBIKE) IKEv2 Mobility and Multihoming Protocol (MOBIKE)
draft-ietf-mobike-protocol-00.txt draft-ietf-mobike-protocol-01.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 December 30, 2005. This Internet-Draft will expire on January 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. The purpose of MOBIKE is to update multihoming extension to IKEv2. MOBIKE allows mobile and/or
the (outer) IP addresses associated with IKE and IPsec Security multihomed hosts to update the (outer) IP addresses associated with
Associations (SAs). The main scenario for MOBIKE is making it IKE and IPsec Security Associations (SAs). The main scenario for
possible for a remote access VPN user to move from one address to MOBIKE is making it possible for a remote access VPN user to move
another without re-establishing all security associations with the from one address to another while keeping the connection with the VPN
VPN gateway. gateway active.
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 . . . . . . . . . . . . . . . . . . . . . . . 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 path of IPsec SAs . . . . . . . . . . . . . . . . 7 2.3 Changing addresses in IPsec SAs . . . . . . . . . . . . . 7
2.4 Updating additional addresses . . . . . . . . . . . . . . 8 2.4 Updating additional addresses . . . . . . . . . . . . . . 9
2.5 Path testing . . . . . . . . . . . . . . . . . . . . . . . 9 2.5 Path testing . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Return routability check . . . . . . . . . . . . . . . . . 10 2.6 Return routability check . . . . . . . . . . . . . . . . . 11
2.7 NAT prevention . . . . . . . . . . . . . . . . . . . . . . 11 2.7 NAT prevention . . . . . . . . . . . . . . . . . . . . . . 11
3. Payload formats . . . . . . . . . . . . . . . . . . . . . . . 13 3. Payload formats . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 MOBIKE_SUPPORTED notification payload . . . . . . . . . . 13 3.1 MOBIKE_SUPPORTED notification payload . . . . . . . . . . 13
3.2 ADDITIONAL_ADDRESS notification payload . . . . . . . . . 13 3.2 ADDITIONAL_IP4/6_ADDRESS notification payloads . . . . . . 13
3.3 CHANGE_PATH notification payload . . . . . . . . . . . . . 13 3.3 UPDATE_SA_ADDRESSES notification payload . . . . . . . . . 13
3.4 UNACCEPTABLE_PATH notification payload . . . . . . . . . . 13 3.4 UNACCEPTABLE_ADDRESSES notification payload . . . . . . . 13
3.5 COOKIE2 notification payload . . . . . . . . . . . . . . . 14 3.5 COOKIE2 notification payload . . . . . . . . . . . . . . . 14
3.6 NAT_PREVENTION notification payload . . . . . . . . . . . 14 3.6 NAT_PREVENTION notification payload . . . . . . . . . . . 14
3.7 NAT_PREVENTED notification payload . . . . . . . . . . . . 14 3.7 NAT_PREVENTED notification payload . . . . . . . . . . . . 14
4. Security considerations . . . . . . . . . . . . . . . . . . . 15 4. Security considerations . . . . . . . . . . . . . . . . . . . 15
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1 Normative references . . . . . . . . . . . . . . . . . . . 18 7.1 Normative references . . . . . . . . . . . . . . . . . . . 19
7.2 Informative references . . . . . . . . . . . . . . . . . . 19 7.2 Informative references . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21 1. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 22
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
tunnel mode IPsec packets. Currently, it is not possible to change tunnel mode IPsec packets. Currently, it is not possible to change
these addresses after the IKE_SA has been created. these addresses after the IKE_SA has been created.
There are scenarios where these IP addresses might change. One There are scenarios where these IP addresses might change. One
example is mobility: a host changes its point of network attachment, example is mobility: a host changes its point of network attachment,
and receives a new IP address. Another example is a multihoming host and receives a new IP address. Another example is a multihoming host
that would like to change to a different interface if, for instance, that would like to change to a different interface if, for instance,
the currently used address stops working for some reason. the currently used address stops working for some reason.
In some cases, the the problem can be solved by simply creating new Although the problem can be solved by creating new IKE and IPsec SAs
IKE and IPsec SAs after the IP address has changed. In static when the addresses need to be changed, this may not be optimal for
multihoming scenarios, it may even be possible to have several IKE several reasons. In some cases, creating a new IKE_SA may require
and IPsec SAs simultaneously, and perform some kind of dynamic user interaction for authentication (entering a code from a token
routing over them [RFC3884]. However, this can be problematic for card, for instance). Creating new SAs often also involves expensive
several reasons. Creating a new IKE_SA may require user interaction calculations and possibly a large number of roundtrips. Due to these
for authentication (entering a code from a token card, for instance). reasons, a mechanism for updating the IP addresses of existing IKE
Creating new SAs often also involves expensive calculations and and IPsec SAs is needed. The MOBIKE protocol described in this
possibly a large number of roundtrips. Due to these reasons, a document provides such a mechanism.
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 making it possible for a remote The main scenario for MOBIKE is making it possible for a remote
access VPN user to move from one address to another without re- access VPN user to move from one address to another without re-
establishing all security associations with the VPN gateway. For establishing all security associations with the VPN gateway. For
instance, a user could start from fixed Ethernet in the office, and instance, a user could start from fixed Ethernet in the office, and
then disconnect the laptop and move to office wireless LAN. When then disconnect the laptop and move to office wireless LAN. When
leaving the office the laptop could start using GPRS, and switch to a leaving the office the laptop could start using GPRS, and switch to a
different wireless LAN when the user arrives home. MOBIKE updates different wireless LAN when the user arrives home. MOBIKE updates
only the outer (tunnel header) addresses of IPsec SAs, and the only the outer (tunnel header) addresses of IPsec SAs, and the
addresses and others traffic selectors used inside the tunnel stay addresses and others traffic selectors used inside the tunnel stay
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.
More complex scenarios arise when the VPN gateway also has several MOBIKE also supports more complex scenarios where the VPN gateway
network interfaces: these interfaces could be connected to different also has several network interfaces: these interfaces could be
networks or ISPs, they may have may be a mix of IPv4 and IPv6 connected to different networks or ISPs, they may have may be a mix
addresses, and the addresses may change over time. Furthermore, both of IPv4 and IPv6 addresses, and the addresses may change over time.
parties could be VPN gateways relaying traffic for other parties. Furthermore, both parties could be VPN gateways relaying traffic for
other parties.
1.2 MOBIKE protocol overview 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
skipping to change at page 4, line 31 skipping to change at page 4, line 31
the IPsec SAs, and collecting the information it needs to make this the IPsec SAs, and collecting the information it needs to make this
decision (such as determining which address pairs work or do not decision (such as determining which address pairs work or do not
work). The other party (the "gateway" in remote access VPN scenario) work). The other party (the "gateway" in remote access VPN scenario)
simply tells the initiator what addresses it has, but does not update 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 the IPsec SAs until it receives a message from the initiator to do
so. so.
Making the decision at the initiator is consistent with how normal Making the decision at the initiator is consistent with how normal
IKEv2 works: the initiator decides which addresses it uses when IKEv2 works: the initiator decides which addresses it uses when
contacting the responder. It also makes sense especially when the contacting the responder. It also makes sense especially when the
initiator is the mobile node: it is in better position to decide initiator is the mobile node: it is in a better position to decide
which of its network interfaces should be used for both upstream and which of its network interfaces should be used for both upstream and
downstream traffic. downstream traffic.
The details of exactly how the initiator makes the decision, what The details of exactly how the initiator makes the decision, what
information is used in making it, how the information is collected, information is used in making it, how the information is collected,
how preferences affect the decision, and when a decision needs to be how preferences affect the decision, and when a decision needs to be
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
skipping to change at page 5, line 22 skipping to change at page 5, line 22
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 design 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 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 prevention" feature ensures
that IP addresses have not been modified by NATs, IPv4/IPv6 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 1.3 Terminology and notations
When messages containing IKEv2 payloads are shown, 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+").
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].
IPsec Security Association (SA)
An ESP or AH Security Association.
Path
A particular combination of source IP address and destination IP
address (note: this definition does not consider the route taken
by the packets in the network).
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_SA_INIT request
and response messages. and response messages.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni, HDR, SAi1, KEi, Ni,
N(MOBIKE_SUPPORTED), N(MOBIKE_SUPPORTED),
[N(NAT_DETECTION_*)] --> [N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP)] -->
<-- HDR, SAr1, KEr, Nr, <-- HDR, SAr1, KEr, Nr,
[N(NAT_DETECTION_*)], [N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP)]
[CERTREQ], [CERTREQ],
N(MOBIKE_SUPPORTED) 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_ADDRESS notification payloads in the IKE_AUTH exchange (in ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notification
case of multiple IKE_AUTH exchanges, in the message containing the SA payloads in the IKE_AUTH exchange (in case of multiple IKE_AUTH
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(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(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 path of IPsec SAs 2.3 Changing addresses in IPsec SAs
In MOBIKE, the initiator of the IKE_SA decides what addresses are In MOBIKE, the initiator of the IKE_SA decides what addresses are
used in the IPsec SAs. That is, the responder never updates any used in the IPsec SAs. That is, the responder never updates any
IPsec SAs without receiving an explicit CHANGE_PATH request from the IPsec SAs without receiving an explicit UPDATE_SA_ADDRESSES request
initiator. (As described below, the responder can, however, update from the initiator. (As described below, the responder can, however,
the IKE_SA in some circumstances.) update the IKE_SA in some circumstances.)
The description in this section assumes that the initiator has The description in this section assumes that the initiator has
already decided what the new addresses should be. How this decision already decided what the new addresses should be. How this decision
is made is beyond the scope of this specification. When this is made is beyond the scope of this specification. When this
decision has been made, the initiator decision has been made, the initiator
o Updates the IKE_SA and IPsec SAs with the new addresses, and sets o Updates the IKE_SA and IPsec SAs with the new addresses, and sets
the "pending_update" flag in the IKE_SA. 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
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 CHANGE_PATH notification payload (which does not containing the UPDATE_SA_ADDRESSES notification payload (which
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(CHANGE_PATH), HDR, SK { N(UPDATE_SA_ADDRESSES),
N(COOKIE2), N(COOKIE2),
[N(NAT_DETECTION_*),] [N(NAT_DETECTION_*_IP)],
[N(NAT_PREVENTION)] } --> [N(NAT_PREVENTION)] } -->
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
CHANGE_PATH request). UPDATE_SA_ADDRESSES request).
Note that if the responder has NAT Traversal enabled, it can update 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 the addresses in both the IKE_SA and IPsec SAs as usual (if it
implements the "SHOULD" from [IKEv2] Section 2.23. implements the "SHOULD" from [IKEv2] Section 2.23).
When processing an INFORMATIONAL request containing the CHANGE_PATH
notification, the responder
o Compares the Message ID with the latest_update_received counter in When processing an INFORMATIONAL request containing the
the IKE_SA. If latest_update_received is greater than the UPDATE_SA_ADDRESSES notification, the responder
received Message ID, the reply is sent as usual, but no other o Determines whether it has already received a newer
action is taken; otherwise, updates the latest_update_received UPDATE_SA_ADDRESSES request than this one (if the responder uses a
counter. window size greater than one, it is possible that requests are
received out of order). If it has, a response message is sent,
but no other action is taken.
o If the NAT_PREVENTION payload is present, processes it as o If the NAT_PREVENTION 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), N(UNACCEPTABLE_PATH)}". is not, replies with "HDR, SK {N(COOKIE2),
N(UNACCEPTABLE_ADDRESSES)}".
o Updates the IP addresses in the IKE_SA and IPsec SAs with the
values from the IP header.
o If NAT Traversal is supported and NAT detection payloads were o Updates the IP addresses in the IKE_SA with the values from the IP
included, enables or disables NAT Traversal. 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: o Replies with an INFORMATIONAL response:
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
<-- HDR, SK { N(COOKIE2), <-- HDR, SK { N(COOKIE2),
[N(NAT_DETECTION_*)] } [N(NAT_DETECTION_*_IP)] }
o If necessary, initiates a return routability check for the new
initiator address (see Section 2.6) and waits for the check to
finish..
o Updates the IPsec SAs with the new addresses.
o If NAT Traversal is supported and NAT detection payloads were
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 the response contains the NAT_PREVENTED payload, processes it
as described in Section 2.7. as described in Section 2.7.
o If the response contains an UNACCEPTABLE_PATH notification o If the response contains an UNACCEPTABLE_ADDRESSES notification
payload, the initiator MAY select another path and retry the payload, the initiator MAY select another addresses and retry the
exchange, keep on using the current path, 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 2.4 Updating additional addresses
As described in Section 2.2, both the initiator and responder can As described in Section 2.2, both the initiator and responder can
send a list of additional addresses (in addition to the one used for 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 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 exchange. If this list of addresses changes, a new list can be sent
in any INFORMATIONAL exchange request message. in any INFORMATIONAL exchange request message.
When the responder (of the original IKE_SA) receives an INFORMATIONAL When the responder (of the original IKE_SA) receives an INFORMATIONAL
request containing ADDITIONAL_ADDRESS payloads, it simply stores the request containing ADDITIONAL_*_ADDRESS payloads, it simply stores
information, but no other action is taken. the information, but no other action is taken.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SK { N(ADDITIONAL_ADDRESS)+, HDR, SK { N(ADDITIONAL_*_ADDRESS)+,
N(COOKIE2) } --> N(COOKIE2) } -->
<-- HDR, SK { N(COOKIE2) } <-- HDR, SK { N(COOKIE2) }
When the initiator receives an INFORMATIONAL request containing When the initiator receives an INFORMATIONAL request containing
ADDITIONAL_ADDRESS, it stores the information and also determines ADDITIONAL_*_ADDRESS, it stores the information and also determines
whether the currently used path needs to be changed (for instance, if whether the currently used addresses need to be changed (for
the currently used address is no longer included in the list); if it instance, if the currently used address is no longer included in the
does, the initiator proceeds as described in the previous section. list); if it does, the initiator proceeds as described in
Section 2.3.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
<-- HDR, SK { N(ADDITIONAL_ADDRESS)+, <-- HDR, SK { N(ADDITIONAL_*_ADDRESS)+,
N(COOKIE2) } N(COOKIE2) }
HDR, SK { N(COOKIE2) } --> HDR, SK { N(COOKIE2) } -->
If the implementation supports window sizes greater than one, it also If the implementation supports window sizes greater than one, it also
has to keep track of the Message ID of the latest update it has has to keep track of the Message ID of the latest update it has
received, to avoid the situation where new information is overwritten received, to avoid the situation where new information is overwritten
by older. by older.
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 path may no send a new additional address list, the currently used addresses may
longer work. In this case, the responder uses the additional address no longer work. In this case, the responder uses the additional
list received from the initiator, the list of its own addresses, and, address list received from the initiator, the list of its own
if necessary, the path testing feature (see Section 2.5) to determine addresses, and, if necessary, the path testing feature (see
a path that works, updates the addresses in the IKE_SA (but not IPsec Section 2.5) to determine a path that works, updates the addresses in
SAs), and then sends the INFORMATIONAL request. This is the only the IKE_SA (but not IPsec SAs), and then sends the INFORMATIONAL
time the responder uses the additional address list received from the request. This is the only time the responder uses the additional
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
or paths are acceptable to use. A minimal "mobile client" could have are acceptable to use. A minimal "mobile client" could have a policy
a policy that says that only the responder's address specified in that says that only the responder's address specified in local
local configuration is acceptable. This kind of client does not have configuration is acceptable. This kind of client does not have to
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 Path testing
IKEv2 Dead Peer Detection allows the peers to detect if the currently IKEv2 Dead Peer Detection allows the peers to detect if the currently
used path has stopped working. However, if either of the peers has used path has stopped working. However, if either of the peers has
several addresses, DPD alone does not indicate which of the other several addresses, DPD alone does not indicate which of the other
paths might work. The path testing feature allows the parties to paths might work. The path testing feature allows the parties to
determine whether a particular path (pair of addresses) works, determine whether a particular path (pair of addresses) works,
without yet committing to changing over to these addresses. without yet committing to changing over to these addresses.
MOBIKE introduces a new IKEv2 exchange type, PATH_TEST, for testing 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 connectivity. This exchange is not part of any IKE_SA, so it is not
cryptographically protected. It also does not result in the cryptographically protected. It also does not result in the
responder keeping any state. responder keeping any state.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR(0,0), N(COOKIE2), HDR(0,0), N(COOKIE2),
[N(NAT_DETECTION_*)] --> [N(NAT_DETECTION_*_IP)] -->
<-- HDR(0,0), N(COOKIE2), <-- HDR(0,0), N(COOKIE2),
[N(NAT_DETECTION_*)] [N(NAT_DETECTION_*_IP)]
The reason for introducing a new exchange type, instead of using The reason for introducing a new exchange type, instead of using
INFORMATIONAL exchanges, is to simplify implementations by allowing INFORMATIONAL exchanges, is to simplify implementations by allowing
MOBIKE to work with window size 1. MOBIKE to work with window size 1.
Performing path testing over several different paths is not required Performing path testing over several different paths is not required
if the node has other information that enables it to select which if the node has other information that enables it to select which
path should be used. Also, responders do not perform path testing path should be used. Also, responders do not perform path testing
unless they update their list of additional addresses (as described unless they update their list of additional addresses (as described
in the previous section). Implementations MAY do path testing even in Section 2.4). Implementations MAY do path testing even if the
if the currently used path is working to e.g. detect when a better currently used path is working to e.g. detect when a better but
but previously unavailable path becomes available, or to speed up previously unavailable path becomes available, or to speed up
recovery in fault situations. recovery in fault situations.
Implementations that perform path testing MUST take steps to avoid Implementations that perform path testing MUST take steps to avoid
causing unnecessary congestion. TBD: add some more details here. causing unnecessary congestion. TBD: add some more details here.
2.6 Return routability check 2.6 Return routability check
Both the initiator and the responder can optionally verify that the Both the initiator and the responder can optionally verify that the
other party can actually receive packets at the claimed address. other party can actually receive packets at the claimed address.
This "return routability check" can be done before updating the IPsec This "return routability check" MAY be done before updating the IPsec
SAs, immediately after updating them, or continuously during the SAs, immediately after 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.
skipping to change at page 11, line 20 skipping to change at page 11, line 35
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 all
INFORMATIONAL messages. The sender of an INFORMATIONAL request MUST INFORMATIONAL messages. The sender of an INFORMATIONAL request MUST
include a COOKIE2 notification payload, and the recipient of an include a COOKIE2 notification payload, and the recipient of an
INFORMATIONAL request MUST copy the payload as-is to the response. INFORMATIONAL request MUST copy the payload as-is to the response.
When processing the response, the original sender MUST verify that 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 the value is the same one as sent. If the values do not match, the
IKE_SA MUST be closed. 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 destination address in the IKE_SA has been updated after the the INFORMATIONAL request has been sent to several different
INFORMATIONAL request was sent, then it is possible that the request addresses (i.e., the destination address in the IKE_SA has been
has been sent to several different addresses. In this case, updated after the request was first sent), receiving the
receiving the INFORMATIONAL response does not tell which address is INFORMATIONAL response does not tell which address is the working
the working one; thus, a new INFORMATIONAL request needs to be sent. one. In this case, a new INFORMATIONAL request needs to be sent to
check return routability.
2.7 NAT prevention 2.7 NAT prevention
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 prevention" feature allows both the initiator and responder
skipping to change at page 11, line 51 skipping to change at page 12, line 18
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 NAT_PREVENTION 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 The initiator MAY include a NAT_PREVENTION payload in an IKE_SA_INIT
request. The responder MUST compare the NAT_PREVENTION payload with request. The responder then MUST calculate the expected value based
the values from the IP header. If they do not match, the responder on the values from the IP header, and compare this with the value in
the NAT_PREVENTION payload. If they do not match, the responder
replies with "HDR(A,0), N(NAT_PREVENTED)" and does not create any replies with "HDR(A,0), N(NAT_PREVENTED)" and does not create any
state. state.
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 NAT_PREVENTION 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 NAT_PREVENTION 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. It may peer_address, peer_port) from the first IKE_AUTH request.
also decide to perform a return routability check soon after the
IKE_AUTH exchanges have been completed.
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.
NAT_PREVENTION payloads can also be included when changing the path NAT_PREVENTION payloads can also be included when changing the
of IPsec SAs (see Section 2.3). TBD: add better description. addresses of IPsec SAs (see Section 2.3). TBD: add better
description.
3. Payload formats 3. Payload formats
3.1 MOBIKE_SUPPORTED notification payload 3.1 MOBIKE_SUPPORTED notification payload
The MOBIKE_SUPPORTED notification payload is included in the The MOBIKE_SUPPORTED notification payload is included in the
IKE_SA_INIT messages to indicate that the implementation supports IKE_SA_INIT messages to indicate that the implementation supports
this specification. this specification.
The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA
(16396..40959). The Protocol ID field is set to one (1), and SPI (16396..40959). The Protocol ID and SPI Size fields are set to zero.
Size is set to zero. There is no data associated with this Notify There is no data associated with this Notify type.
type.
3.2 ADDITIONAL_ADDRESS notification payload 3.2 ADDITIONAL_IP4/6_ADDRESS notification payloads
Both initiator and responder can include ADDITIONAL_ADDRESS payloads Both initiator and responder can include ADDITIONAL_IP4_ADDRESS
in the IKE_AUTH exchange and INFORMATIONAL exchange request messages; and/or ADDITIONAL_IP6_ADDRESS payloads in the IKE_AUTH exchange and
see Section 2.2 and Section 2.4 for more detailed description. INFORMATIONAL exchange request messages; see Section 2.2 and
Section 2.4 for more detailed description.
The Notify Message Type for ADDITIONAL_ADDRESS is TBD-BY-IANA The Notify Message Types for ADDITIONAL_IP4_ADDRESS and
(16396..40959). The Protocol ID field is set to one (1), and SPI ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA (16396..40959) and TBD-BY-IANA
Size is set to zero. The data associated with this Notify type is (16396..40959), respectively. The Protocol ID and SPI Size fields
either an IPv4 address or an IPv6 address; the type is determined by are set to zero. The data associated with these Notify types is
the payload length. either a four-octet IPv4 address or a 16-octet IPv6 address.
3.3 CHANGE_PATH notification payload 3.3 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 of the IKE_SA to update addresses of the IKE_SA and
IPsec SAs (see Section 2.3). IPsec SAs (see Section 2.3).
The Notify Message Type for CHANGE_PATH is TBD-BY-IANA The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA
(16396..40959). The Protocol ID field is set to one (1), and SPI (16396..40959). The Protocol ID and SPI Size fields are set to zero.
Size is set to zero. There is no data associated with this Notify There is no data associated with this Notify type.
type.
3.4 UNACCEPTABLE_PATH notification payload 3.4 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 a CHANGE_PATH in the corresponding request message (which contained an
notification payload) was not carried out. UPDATE_SA_ADDRESSES notification payload) was not carried out.
The Notify Message Type for UNACCEPTABLE_PATH is TBD-BY-IANA The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA
(40..8191). The Protocol ID field is set to one (1), and SPI Size is (40..8191). The Protocol ID and SPI Size fields are set to zero.
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.5 COOKIE2 notification payload
This payload is included in all INFORMATIONAL exchange messages for This payload is included in all INFORMATIONAL exchange messages for
return routability check purposes (see Section 2.6). It is also used return routability check purposes (see Section 2.6). It is also used
in PATH_TEST messages to match requests and responses (see in PATH_TEST messages to match requests and responses (see
Section 2.5). Section 2.5).
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 in a way that is
unpredictable to the recipient. The Notify Message Type for this unpredictable to the recipient. The Notify Message Type for this
message is TBD-BY-IANA (16396..40959). The Protocol ID field is set message is TBD-BY-IANA (16396..40959). The Protocol ID and SPI Size
to one (1), and SPI Size is set to zero. fields are set to zero.
3.6 NAT_PREVENTION notification payload 3.6 NAT_PREVENTION 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 field is set to one (1), and SPI Size is set to zero. The Protocol ID and SPI Size fields are set to zero.
3.7 NAT_PREVENTED notification payload 3.7 NAT_PREVENTED 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 NAT_PREVENTED is TBD-BY-IANA (40..8191).
The Protocol ID field is set to one (1), and SPI Size is set to zero. The Protocol ID and SPI Size fields are set to zero. There is no
There is no data associated with this Notify type. 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. In some specific cases MOBIKE is
also capable of protecting address changes better than existing NAT also capable of protecting address changes better than existing NAT
Traversal procedures. Traversal procedures.
The threats arising in scenarios targeted by MOBIKE are: The threats arising in scenarios targeted by MOBIKE are:
Traffic redirection and hijacking Traffic redirection and hijacking
Insecure mobility management mechanisms may allow inappropriate Insecure mobility management mechanisms may allow inappropriate
redirection of traffic. This may allow inspection of the traffic redirection of traffic. This may allow inspection of the
as well as man-in-the-middle and session hijacking attacks. 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 The scope of these attacks in the MOBIKE case is limited, as
traffic is protected using IPsec. However, it should be observed all traffic is protected using IPsec. However, it should be
that security associations originally created for the protection observed that security associations originally created for the
of a specific flow between specific addresses may be moved through protection of a specific flow between specific addresses may be
MOBIKE. The level of required protection may be different in a moved through MOBIKE. The level of required protection may be
new location of a VPN client, for instance. different in a new location of a VPN client, for instance.
Third-party denial-of-service through flooding Third-party denial-of-service through flooding
Traffic redirection may be performed not just to gain access to Traffic redirection may be performed not just to gain access to
the traffic, but also to cause a denial-of-service attack for a the traffic, but also to cause a denial-of-service attack for a
third party. For instance, a high-speed TCP session or a third party. For instance, a high-speed TCP session or a
multimedia stream may be redirected towards a victim host, causing multimedia stream may be redirected towards a victim host,
its communications capabilities to suffer. causing its communications capabilities to suffer.
The attackers in this threat can be either outsiders or even one The attackers in this threat can be either outsiders or even
of the participants. In usual VPN usage scenarios attacks by one of the participants. In usual VPN usage scenarios attacks
participants can be easily dealt with. However, this requires by participants can be easily dealt with. However, this
that strong authentication was performed in the initial IKEv2 requires that strong authentication was performed in the
negotiation. This may not be the case in all scenarios, initial IKEv2 negotiation. This may not be the case in all
particularly with opportunistic approaches to security. scenarios, particularly with opportunistic approaches to
security.
Normally such attacks would expire in a short time frame due to Normally such attacks would expire in a short time frame due to
the lack of responses (such as transport layer acknowledgements) the lack of responses (such as transport layer
from the victim. However, as described in [Aura02], malicious acknowledgements) from the victim. However, as described in
participants would typically be able to spoof such [Aura02], malicious participants would typically be able to
acknowledgements and maintain the traffic flow for an extended spoof such acknowledgements and maintain the traffic flow for
period of time. For instance, if the attacker opened the TCP an extended period of time. For instance, if the attacker
stream itself before redirecting it to the victim, the attacker opened the TCP stream itself before redirecting it to the
becomes aware of the sequence number space used in this particular victim, the attacker becomes aware of the sequence number space
session. used in this particular session.
It should also be noted, as shown in [Bombing], that without It should also be noted, as shown in [Bombing], that without
ingress filtering in the attacker's network such attacks are ingress filtering in the attacker's network such attacks are
already possible simply by sending spoofed packets from the already possible simply by sending spoofed packets from the
attacker to the victim directly. Consequently, it makes little attacker to the victim directly. Consequently, it makes little
sense to protect against attacks of similar nature in MOBIKE. sense to protect against attacks of similar nature in MOBIKE.
However, it still makes sense to limit the amplification However, it still makes sense to limit the amplification
capabilities provided to attackers, so that they cannot use stream capabilities provided to attackers, so that they cannot use
redirection to send 1000 packets to the victim by sending just a stream redirection to send 1000 packets to the victim by
few packets themselves. sending just a few packets themselves.
Note that a variant of the flooding attack exists in IKEv2 NAT Note that a variant of the flooding attack exists in IKEv2 NAT
Traversal functionality [PseudoNAT]. In this variant, the Traversal functionality [PseudoNAT]. In this variant, the
attacker has to be on the path between the participants, changing attacker has to be on the path between the participants,
the addresses in the packets that pass by. This attack is changing the addresses in the packets that pass by. This
possible because the addresses in the outer headers are not attack is possible because the addresses in the outer headers
protected. When the attacker leaves the path, the correct are not protected. When the attacker leaves the path, the
situation is restored after the exchange of the next packets correct situation is restored after the exchange of the next
between the participants. packets between the participants.
Spoofing indications related to network connectivity Spoofing indications related to network connectivity
Attackers may also spoof various indications from lower layers and Attackers may also spoof various indications from lower layers
the network in an effort to confuse the peers about which and the network in an effort to confuse the peers about which
addresses are or are not working. For example, attackers may addresses are or are not working. For example, attackers may
spoof ICMP error messages in an effort to cause the parties to spoof ICMP error messages in an effort to cause the parties to
move their traffic elsewhere or even to disconnect. Attackers may move their traffic elsewhere or even to disconnect. Attackers
also spoof information related to network attachments, router may also spoof information related to network attachments,
discovery, and address assignments in an effort to make the router discovery, and address assignments in an effort to make
parties believe they have Internet connectivity when in reality the parties believe they have Internet connectivity when in
they do not. reality they do not.
This may cause use of non-preferred addresses or even denial-of- This may cause use of non-preferred addresses or even denial-
service. of-service.
Denial-of-service of the participants through MOBIKE Denial-of-service of the participants through MOBIKE
Inappropriate MOBIKE protocol mechanisms might make it possible Inappropriate MOBIKE protocol mechanisms might make it possible
for attackers to disconnect the participants, or to move them to for attackers to disconnect the participants, or to move them
non-operational addresses. to non-operational addresses.
MOBIKE addresses these threats using the following countermeasures: MOBIKE addresses these threats using the following countermeasures:
Payload traffic protection Payload traffic 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. It is
recommended that security policies be configured in a manner that recommended that security policies be configured in a manner
takes into account that a single security association can be used that takes into account that a single security association can
through different paths at different times. be used through different paths at different times.
Protection of MOBIKE payloads Protection of MOBIKE payloads
The payloads used in MOBIKE are encrypted, integrity protected, The payloads used in MOBIKE are encrypted, integrity protected,
and replay protected. This assures that no one except the and replay protected. This assures that no one except the
participants can, for instance, give a control message to change participants can, for instance, give a control message to
the addresses. change the addresses.
Note, however, that the actual IP address communicated in these Note, however, that the actual IP address communicated in these
messages is in the outer IP header and not protected, just as in messages is in the outer IP header and not protected, just as
IKEv2 NAT Traversal. MOBIKE adds the NAT_PREVENTION payload, in IKEv2 NAT Traversal. MOBIKE adds the NAT_PREVENTION
however, which can be used to prevent modifications by outsiders. payload, however, which can be used to prevent modifications by
Where this payload is used, communication through NATs and other outsiders. Where this payload is used, communication through
address translators is impossible, however. This feature is NATs and other address translators is impossible, however.
mainly intended for site-to-site VPN cases, where the This feature is mainly intended for site-to-site VPN cases,
administrators may know beforehand that NATs are not present, and where the administrators may know beforehand that NATs are not
thus any modification to the packet can be considered to be an present, and thus any modification to the packet can be
attack. considered to be an attack.
Explicit address change Explicit address change
MOBIKE allows only address changes that are explicitly requested. MOBIKE allows only address changes that are explicitly
This provides additional security beyond to what IKEv2 NAT requested. This provides additional security beyond to what
Traversal has, but it should be noted that the benefits of this IKEv2 NAT Traversal has, but it should be noted that the
can only be realized when MOBIKE is used without intervening NATs benefits of this can only be realized when MOBIKE is used
and NAT Traversal. without intervening NATs and NAT Traversal.
When NAT Traversal is supported, the peer's address may be updated When NAT Traversal is supported, the peer's address may be
automatically to allow changes in NAT mappings. The "continued updated automatically to allow changes in NAT mappings. The
return routability" feature, implemented by the COOKIE2 payload, "continued return routability" feature, implemented by the
allows verification of the new address after the change. This COOKIE2 payload, allows verification of the new address after
limits the duration of any "third party bombing" attack by off- the change. This limits the duration of any "third party
path (relative to the victim) attackers. bombing" attack by off-path (relative to the victim) attackers.
Return routability tests Return routability tests
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 ensure that third party flooding
attacks are prevented. The tests are authenticated messages that attacks are prevented. The tests are authenticated messages
the peer has to respond to in order for the address change to be that the peer has to respond to in order for the address change
committed to. The tests contain unpredictable data, and can only to be committed to. The tests contain unpredictable data, and
be properly responded to by someone who has the keys associated can only be properly responded to by someone who has the keys
with the IKEv2 security association and who has seen the request associated with the IKEv2 security association and who has seen
packet for the test. the request packet for the test.
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. However, MOBIKE is resistant
to incorrect information from these sources in the sense that it to incorrect information from these sources in the sense that it
provides its own security for both the signaling of addressing provides its own security for both the signaling of addressing
information as well as actual payload data transmission. Denial-of- information as well as actual payload data transmission. Denial-of-
service vulnerabilities remain, however. Some aspects of these service vulnerabilities remain, however. Some aspects of these
vulnerabilities can be mitigated through the use of techniques vulnerabilities can be mitigated through the use of techniques
specific to the other parts of the stack, such as properly dealing specific to the other parts of the stack, such as properly dealing
with ICMP errors [ICMPAttacks], link layer security, or the use of with ICMP errors [ICMPAttacks], link layer security, or the use of
skipping to change at page 20, line 6 skipping to change at page 20, line 20
[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.
[PseudoNAT] [PseudoNAT]
Dupont, F. and J-J. Bernard, "Transient pseudo-NAT attacks Dupont, F. and J-J. Bernard, "Transient pseudo-NAT attacks
or how NATs are even more evil than you believed", or how NATs are even more evil than you believed",
draft-dupont-transient-pseudonat-04 (expired) (work in draft-dupont-transient-pseudonat-04 (expired) (work in
progress), June 2004. progress), June 2004.
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
Transport Mode for Dynamic Routing", RFC 3884,
September 2004.
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and
Multihoming Extensions for IKEv2 (SMOBIKE)", Multihoming Extensions for IKEv2 (SMOBIKE)",
draft-eronen-mobike-simple-00 (work in progress), draft-eronen-mobike-simple-00 (work in progress),
March 2004. March 2004.
[UNSAF] Daigle, L., "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
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
(This section should be removed by the RFC editor.)
Changes from -00 to -01:
o Editorial fixes and small clarifications (issues 21, 25, 26, 29).
o Use Protocol ID zero for notifications (issue 30).
o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue
23).
o Use the word "path" only in senses that include the route taken
(issue 29).
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 81 change blocks. 
257 lines changed or deleted 284 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/