draft-ietf-mobike-protocol-04.txt   draft-ietf-mobike-protocol-05.txt 
MOBIKE Working Group P. Eronen, Ed. MOBIKE Working Group P. Eronen, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Expires: April 10, 2006 October 7, 2005 Expires: April 27, 2006 October 24, 2005
IKEv2 Mobility and Multihoming Protocol (MOBIKE) IKEv2 Mobility and Multihoming Protocol (MOBIKE)
draft-ietf-mobike-protocol-04.txt draft-ietf-mobike-protocol-05.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 April 10, 2006. This Internet-Draft will expire on April 27, 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 Internet Key Exchange (IKEv2). MOBIKE multihoming extension to Internet Key Exchange (IKEv2). MOBIKE
allows hosts to update the (outer) IP addresses associated with IKEv2 allows hosts to update the (outer) IP addresses associated with IKEv2
and IPsec Security Associations. A mobile VPN client could use and tunnel mode IPsec Security Associations. A mobile VPN client
MOBIKE to keep the connection with the VPN gateway active while could use MOBIKE to keep the connection with the VPN gateway active
moving from one address to another. Similarly, a multihomed host while moving from one address to another. Similarly, a multihomed
could use MOBIKE to move the traffic to a different interface if, for host could use MOBIKE to move the traffic to a different interface
instance, the one currently being used stops working. if, for instance, the one currently being used stops working.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4
3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4
3.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 8 2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
3.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 6
4. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 9 2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9
4.1. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 9 3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Initial Tunnel Header Addresses . . . . . . . . . . . . . 9 3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10
4.3. Additional Addresses . . . . . . . . . . . . . . . . . . . 9 3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10
4.4. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 11 3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 10
4.5. Updating Additional Addresses . . . . . . . . . . . . . . 14 3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11
4.6. Return Routability Check . . . . . . . . . . . . . . . . . 15 3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12
4.7. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 15 3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15
4.8. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 16 3.7. Return Routability Check . . . . . . . . . . . . . . . . . 16
4.9. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 17 3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 17
4.10. Failure Recovery and Timeouts . . . . . . . . . . . . . . 17 3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 18
5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 18 3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 18 3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 19
5.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 18 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 18 4.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 20
5.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 18 4.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 20
5.5. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 19 4.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 20
5.6. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 19 4.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 20
5.7. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 19 4.5. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 21
5.8. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 19 4.6. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 4.7. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 21
6.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 20 4.8. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 21
6.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.3. Denial-of-Service Attacks Against Third Parties . . . . . 21 5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 23
6.4. Spoofing Network Connectivity Indications . . . . . . . . 22 5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 23
6.5. Address and Topology Disclosure . . . . . . . . . . . . . 22 5.3. Denial-of-Service Attacks Against Third Parties . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5.4. Spoofing Network Connectivity Indications . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 5.5. Address and Topology Disclosure . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33
1. Introduction 1. Introduction
IKEv2 is used for performing mutual authentication and establishing 1.1. Motivation
and maintaining IPsec Security Associations (SAs). In the current
specifications, the IPsec and IKE SAs are created implicitly between IKEv2 is used for performing mutual authentication, as well as
the IP addresses that are used when the IKE_SA is established. These establishing and maintaining IPsec Security Associations (SAs). In
IP addresses are then used as the outer (tunnel header) addresses for the base IKEv2 protocol, the IPsec and IKE SAs are created implicitly
tunnel mode IPsec packets. Currently, it is not possible to change between the IP addresses that are used when the IKE_SA is
these addresses after the IKE_SA has been created. established. These IP addresses are then used as the outer (tunnel
header) addresses for tunnel mode IPsec packets. Currently, it is
not possible to change these addresses after the IKE_SA has been
created.
There are scenarios where these IP addresses might change. One 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 interface stops working for some reason. the currently used interface stops working for some reason.
Although the problem can be solved by creating new IKE and IPsec SAs Although the problem can be solved by creating new IKE and IPsec SAs
when the addresses need to be changed, this may not be optimal for when the addresses need to be changed, this may not be optimal for
several reasons. In some cases, creating a new IKE_SA may require several reasons. In some cases, creating a new IKE_SA may require
user interaction for authentication (entering a code from a token user interaction for authentication, such as entering a code from a
card, for instance). Creating new SAs often also involves expensive token card. Creating new SAs often also involves expensive
calculations and possibly a large number of round-trips. For these calculations and possibly a large number of round-trips. For these
reasons, a mechanism for updating the IP addresses of existing IKE reasons, a mechanism for updating the IP addresses of existing IKE
and IPsec SAs is needed. The MOBIKE protocol described in this and IPsec SAs is needed. The MOBIKE protocol described in this
document provides such a mechanism. document provides such a mechanism.
The main scenario for MOBIKE is enabling a remote access VPN user to The main scenario for MOBIKE is enabling a remote access VPN user to
move from one address to another without re-establishing all security move from one address to another without re-establishing all security
associations with the VPN gateway. For instance, a user could start associations with the VPN gateway. For instance, a user could start
from fixed Ethernet in the office, and then disconnect the laptop and from fixed Ethernet in the office and then disconnect the laptop and
move to office wireless LAN. When leaving the office the laptop move to the office's wireless LAN. When leaving the office the
could start using GPRS, and switch to a different wireless LAN when laptop could start using GPRS; when the user arrives home, the laptop
the user arrives home. MOBIKE updates only the outer (tunnel header) could switch the the home wireless LAN. MOBIKE updates only the
addresses of IPsec SAs, and the addresses and others traffic outer (tunnel header) addresses of IPsec SAs, and the addresses and
selectors used inside the tunnel stay unchanged. Thus, mobility can other traffic selectors used inside the tunnel stay unchanged. Thus,
be (mostly) invisible to applications and their connections using the mobility can be (mostly) invisible to applications and their
VPN. 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 be a mix of IPv4
of IPv4 and IPv6 addresses, and the addresses may change over time. 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.
2. Terminology and Notation 1.2. Scope and Limitations
This document focuses on the main scenario outlined above, and
supports only tunnel mode IPsec SAs.
The mobility support in MOBIKE allows both parties to move, but does
not provide a "rendezvous" mechanism that would allow simultaneous
movement of both parties, or discovering the addresses when the
IKE_SA is first established. This implies that MOBIKE is best suited
for situations where the address of at least one endpoint is
relatively stable, and can be discovered using existing mechanisms
such as DNS (see Section 3.1).
MOBIKE allows both parties to be multihomed; however, only one pair
of addresses is used for an SA at a time. In particular, load
balancing is beyond the scope of this specification.
MOBIKE follows the IKEv2 practice where a response message is sent to
the same address and port from which the request was received. This
implies that MOBIKE does not work over unidirectional paths.
NATs introduce additional limitations beyond those listed above. For
details, refer to Section 2.3.
The base version of the MOBIKE protocol does not cover all potential
future use scenarios, such as transport mode, application to securing
SCTP, or optimizations desirable in specific circumstances. Future
extensions may be defined later to support additional requirements.
Readers are encouraged to consult the MOBIKE design document [Design]
for further information and rationale behind these limitations.
1.3. Terminology and Notation
When messages containing IKEv2 payloads are described, optional When messages containing IKEv2 payloads are described, optional
payloads are shown in brackets (for instance, "[FOO]"), and a plus payloads are shown in brackets (for instance, "[FOO]"), and a plus
sign indicates that a payload can be repeated one or more times (for sign indicates that a payload can be repeated one or more times (for
instance, "FOO+"). In some cases, the diagrams also show what instance, "FOO+"). To provide context, some diagrams also show what
payloads defined in [IKEv2] would be typically included in, for existing IKEv2 payloads would typically be included in the exchanges.
instance, the IKE_AUTH exchange. These payloads are shown for These payloads are shown for illustrative purposes only; see [IKEv2]
illustrative purposes only; see [IKEv2] for an authoritative for an authoritative description.
description.
When this document talks about updating the source/destination When this document talks about updating the source/destination
addresses of an IPsec SA, it means updating IPsec-related state so addresses of an IPsec SA, it means updating IPsec-related state so
that outgoing ESP/AH packets use those addresses in the tunnel that outgoing ESP/AH packets use those addresses in the tunnel
header. Depending on how the nominal division between Security header. Depending on how the nominal division between Security
Association Database (SAD), Security Policy Database (SPD), and Peer Association Database (SAD), Security Policy Database (SPD), and Peer
Authorization Database (PAD) described in [IPsecArch] is actually Authorization Database (PAD) described in [IPsecArch] is actually
implemented, an implementation can have several different places that implemented, an implementation can have several different places that
have to be updated. have to be updated.
skipping to change at page 4, line 35 skipping to change at page 5, line 20
IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA
exchanges; in this case, the terms "exchange initiator" and "exchange exchanges; in this case, the terms "exchange initiator" and "exchange
responder" are used. The term "original initiator" (which in [IKEv2] responder" are used. The term "original initiator" (which in [IKEv2]
refers to the party who started the latest IKE_SA rekeying) is not refers to the party who started the latest IKE_SA rekeying) is not
used in this document. 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].
3. Protocol Overview 2. Protocol Overview
3.1. Basic Operation 2.1. Basic Operation
MOBIKE allows both parties to have several addresses, and there are MOBIKE allows both parties to have several addresses, and there are
up to N*M pairs of IP addresses that could potentially be used. The up to N*M pairs of IP addresses that could potentially be used. The
decision of which of these pairs to use has to take into account decision of which of these pairs to use has to take into account
several factors. First, the parties may have preferences about which several factors. First, the parties may have preferences about which
interface should be used, due to performance and cost reasons, for interface should be used due to, for instance, performance and cost
instance. Second, the decision is constrained by the fact that some reasons. 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 in the network, problems at the local link at either end, and
either end, and so on. so on.
MOBIKE solves this problem by taking a simple approach: the party MOBIKE solves this problem by taking a simple approach: the party
that initiated the IKE_SA (the "client" in a remote access VPN that initiated the IKE_SA (the "client" in a remote access VPN
scenario) is responsible for deciding which address pair is used for scenario) is responsible for deciding which address pair is used for
the IPsec SAs, and for collecting the information it needs to make the IPsec SAs and for collecting the information it needs to make
this decision (such as determining which address pairs work or do not this decision (such as determining which address pairs work or do not
work). The other party (the "gateway" in a remote access VPN work). The other party (the "gateway" in a remote access VPN
scenario) simply tells the initiator what addresses it has, but does scenario) simply tells the initiator what addresses it has but does
not update the IPsec SAs until it receives a message from the not update the IPsec SAs until it receives a message from the
initiator to do so. initiator to do so. This approach applies to the addresses in the
IPsec SAs; in the IKE_SA case, the exchange initiator can decide
which addresses are used.
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 a better position to decide initiator is a mobile node: it is in a better position to decide
which of its network interfaces should be used for both upstream and 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
messages exchanged between the peers (and thus need to be messages exchanged between the peers (and thus need to be
standardized to ensure interoperability). standardized to ensure interoperability).
Also, many of these issues are not specific to MOBIKE, but are common Also, many of these issues are not specific to MOBIKE, but are common
with the use of existing hosts in dynamic environments or with with the use of existing hosts in dynamic environments or with
mobility protocols such as Mobile IP [MIP4] [MIP6]. A number of mobility protocols such as Mobile IP [MIP4] [MIP6]. A number of
mechanisms already exist or are being developed to deal with these mechanisms already exist or are being developed to deal with these
skipping to change at page 5, line 45 skipping to change at page 6, line 32
movement detection is being specified for both IPv4 and IPv6 in movement detection is being specified for both IPv4 and IPv6 in
[DNA4], [DNA6], and so on. [DNA4], [DNA6], and so on.
Naturally, updating the addresses of IPsec SAs has to take into Naturally, updating the addresses of IPsec SAs 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 prohibition" feature large amounts of traffic. Second, a "NAT prohibition" feature
ensures 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
intended for site-to-site VPNs where the administrators may know enabled only when NAT Traversal is not used.
beforehand that NATs are not present, and thus any modification to
the packet can be considered to be an attack.
3.2. Example Protocol Runs 2.2. Example Protocol Runs
A simple MOBIKE exchange in a mobile scenario is illustrated below: A simple MOBIKE exchange in a mobile scenario is illustrated below:
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
1) HDR, SAi1, KEi, Ni, 1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_*_IP) --> N(NAT_DETECTION_*_IP) -->
<-- HDR, SAr1, KEr, Nr, <-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_*_IP) N(NAT_DETECTION_*_IP)
2) HDR, SK { IDi, CERT, AUTH, 2) (IP_I1:500 -> IP_R1:500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST), CP(CFG_REQUEST),
SAi2, TSi, TSr, SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } --> N(MOBIKE_SUPPORTED) } -->
<-- HDR, SK { IDr, CERT, AUTH, <-- (IP_R1:500 -> IP_I1:500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY), CP(CFG_REPLY),
SAr2, TSi, TSr, SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) } N(MOBIKE_SUPPORTED) }
(Initiator gets information from lower layers that its attachment (Initiator gets information from lower layers that its attachment
point and address has changed.) point and address have changed.)
3) HDR, SK { N(UPDATE_SA_ADDRESSES), 3) (IP_I2:500 -> IP_R1:500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_*_IP) } --> N(NAT_DETECTION_*_IP) } -->
<-- HDR, SK { N(NAT_DETECTION_*_IP) } <-- (IP_R1:500 -> IP_I2:500)
HDR, SK { N(NAT_DETECTION_*_IP) }
(Responder verifies that the initiator has given it (Responder verifies that the initiator has given it
a correct IP address.) a correct IP address.)
4) <-- HDR, SK { N(COOKIE2) } 4) <-- (IP_R1:500 -> IP_I2:500)
HDR, SK { N(COOKIE2) }
(IP_I2:500 -> IP_R1:500)
HDR, SK { N(COOKIE2) } --> HDR, SK { N(COOKIE2) } -->
Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform
each other that they support MOBIKE. In step 3, the initiator each other that they support MOBIKE. In step 3, the initiator
notices a change in its own address, and informs the responder about notices a change in its own address, and informs the responder about
this. At this point, it also starts to use the new address as a this by sending an INFORMATIONAL request containing the
source address in its own outgoing ESP traffic. The responder UPDATE_SA_ADDRESSES notification. The request is sent using the new
records the new address, and if so required by policy, performs a IP address. At this point, it also starts to use the new address as
return routability check of the address. When this check completes, a source address in its own outgoing ESP traffic. Upon receiving the
the responder starts to use the new address as the destination for UPDATE_SA_ADDRESSES notification the responder records the new
its outgoing ESP traffic. address, and if so required by policy, performs a return routability
check of the address. When this check (step 4) completes, the
responder starts to use the new address as the destination for its
outgoing ESP traffic.
Another protocol run in a multihoming scenario is illustrated below. Another protocol run in a multihoming scenario is illustrated below.
In this scenario, the initiator has one address but the responder has In this scenario, the initiator has one address but the responder has
two. two.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
1) HDR, SAi1, KEi, Ni, 1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_*_IP) --> N(NAT_DETECTION_*_IP) -->
<-- HDR, SAr1, KEr, Nr, <-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_*_IP) N(NAT_DETECTION_*_IP)
2) HDR, SK { IDi, CERT, AUTH, 2) (IP_I1:500 -> IP_R1:500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST), CP(CFG_REQUEST),
SAi2, TSi, TSr, SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } --> N(MOBIKE_SUPPORTED) } -->
<-- HDR, SK { IDr, CERT, AUTH, <-- (IP_R1:500 -> IP_I1:500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY), CP(CFG_REPLY),
SAr2, TSi, TSr, SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED), N(MOBIKE_SUPPORTED),
N(ADDITIONAL_IPV4_ADDRESS) } N(ADDITIONAL_IPV4_ADDRESS) }
(The initiator suspects a problem in the currently used address pair, (The initiator suspects a problem in the currently used address pair,
and probes its liveness.) and probes its liveness.)
3) HDR, SK { N(NAT_DETECTION_*_IP) } --> 3) (IP_I1:500 -> IP_R1:500)
HDR, SK { N(NAT_DETECTION_*_IP) } -->
<-- HDR, SK { N(NAT_DETECTION_*_IP) } (IP_I1:500 -> IP_R1:500)
HDR, SK { N(NAT_DETECTION_*_IP) } -->
(The initiator gives up on the current address pair, and tests the ...
other available address pair.)
4) HDR, SK { N(NAT_DETECTION_*_IP), (Eventually, the initiator gives up on the current address pair, and
N(COOKIE2) } --> tests the other available address pair.)
4) (IP_I1:500 -> IP_R2:500)
HDR, SK { N(NAT_DETECTION_*_IP) }
<-- HDR, SK { N(NAT_DETECTION_*_IP), <-- (IP_R2:500 -> IP_I1:500)
N(COOKIE2) } HDR, SK { N(NAT_DETECTION_*_IP) }
(This worked, and the initiator requests the peer to switch to new (This worked, and the initiator requests the peer to switch to new
addresses.) addresses.)
5) HDR, SK { N(UPDATE_SA_ADDRESSES), 5) (IP_I1:500 -> IP_R2:500)
N(NAT_DETECTION_*_IP) } --> HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_*_IP),
N(COOKIE2) } -->
<-- HDR, SK { N(NAT_DETECTION_*_IP) } <-- (IP_R2:500 -> IP_I1:500)
HDR, SK { N(NAT_DETECTION_*_IP),
N(COOKIE2) }
3.3. MOBIKE and Network Address Translation (NAT) 2.3. MOBIKE and Network Address Translation (NAT)
In some MOBIKE scenarios the network may contain NATs or stateful In some MOBIKE scenarios the network may contain NATs or stateful
packet filters (for brevity, the rest of this document talks simply packet filters (for brevity, the rest of this document talks simply
about NATs). The NAT Traversal feature specified in [IKEv2] allows about NATs). The NAT Traversal feature specified in [IKEv2] allows
IKEv2 to work through NATs in many cases, and MOBIKE can leverage IKEv2 to work through NATs in many cases, and MOBIKE can leverage
this functionality: when the addresses used for IPsec SAs are this functionality: when the addresses used for IPsec SAs are
changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed. changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed.
Nevertheless, there are some limitations because NATs usually Nevertheless, there are some limitations because NATs usually
introduce an asymmetry in the network: only packets coming from the introduce an asymmetry in the network: only packets coming from the
skipping to change at page 8, line 33 skipping to change at page 9, line 50
NAT types), this is not possible: the NAT will drop packets sent from NAT types), this is not possible: the NAT will drop packets sent from
the new address (unless the initiator has previously sent a packet to the new address (unless the initiator has previously sent a packet to
that address -- which it cannot do until it knows the address). that address -- which it cannot do until it knows the address).
For simplicity, MOBIKE does not attempt to handle all possible NAT- For simplicity, MOBIKE does not attempt to handle all possible NAT-
related scenarios. Instead, MOBIKE assumes that if NATs are present, related scenarios. Instead, MOBIKE assumes that if NATs are present,
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. support the case where the responder's addresses change.
"Does not fully support" means that no special effort is made to "Does not fully support" means that no special effort is made to
support this functionality. However, if the alternative is losing support this functionality. Responders may also be unaware of NATs
connectivity completely, the responder can still attempt to proceed or specific types of NATs they are behind. However, when a change
with the change, and depending on, e.g., the exact type of NAT, it has occurred that will cause a loss of connectivity, MOBIKE
may succeed. However, analyzing the exact circumstances when this responders will still attempt to inform the initiator of the change.
will or will not work is not done in this document. Depending on, for instance, the exact type of NAT, it may or may not
succeed. However, analyzing the exact circumstances when this will
or will not work is not done in this document.
3.4. Limitations 3. Protocol Exchanges
This document focuses on the main scenario outlined in Section 1, and 3.1. Initial IKE Exchange
supports only tunnel mode.
The base version of the MOBIKE protocol may not cover all potential The initiator is responsible for finding a working pair of addresses
future use scenarios, such as transport mode, application to securing so that the initial IKE exchange can be carried out. Any information
SCTP, or optimizations desirable in specific circumstances. Future from MOBIKE extensions will only be available later, when the
extensions may be defined later to support additional requirements. exchange has progressed far enough. Exactly how the addresses used
for the initial exchange are discovered is beyond the scope of this
specification; typical sources of information include local
configuration and DNS.
4. Protocol Exchanges If either or both of the peers have multiple addresses, some
combinations may not work. Thus, the initiator SHOULD try various
source and destination address combinations when retransmitting the
IKE_SA_INIT request.
4.1. Signaling Support for MOBIKE 3.2. 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_AUTH exchange (in include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in
case of multiple IKE_AUTH exchanges, in the message containing the SA case of multiple IKE_AUTH exchanges, in the message containing the SA
payload). payload).
The format of the MOBIKE_SUPPORTED notification is described in The format of the MOBIKE_SUPPORTED notification is described in
Section 5. Section 4.
4.2. Initial Tunnel Header Addresses 3.3. Initial Tunnel Header Addresses
When an IPsec SA is created, the tunnel header IP addresses (and When an IPsec SA is created, the tunnel header IP addresses (and
port, if doing UDP encapsulation) are taken from the IKE_SA, not the port, if doing UDP encapsulation) are taken from the IKE_SA, not the
IP header of the IKEv2 message requesting the IPsec SA. The IP header of the IKEv2 message requesting the IPsec SA. The
addresses in the IKE_SA are initialized as follows: If the addresses in the IKE_SA are initialized as follows: If the
IKE_SA_INIT request contains the NAT_DETECTION_*_IP notifications and IKE_SA_INIT request contains the NAT_DETECTION_*_IP notifications and
the responder supports NAT Traversal, the values are initialized from the responder supports NAT Traversal, the values are initialized from
the IP header of the first IKE_AUTH request. Otherwise, the values the IP header of the first IKE_AUTH request. Otherwise, the values
are initialized from the IP header of the IKE_SA_INIT request. are initialized from the IP header of the IKE_SA_INIT request.
The addresses are taken from the IKE_AUTH request when NAT Traversal The addresses are taken from the IKE_AUTH request when NAT Traversal
is being used because IKEv2 requires changing from port 500 to 4500 is being used because IKEv2 requires changing from port 500 to 4500
if a NAT is discovered. To simplify things, implementations that if a NAT is discovered. To simplify things, implementations that
support both this specification and NAT Traversal MUST change to port support both this specification and NAT Traversal MUST change to port
4500 if the correspondent also supports both, even if no NAT was 4500 if the correspondent also supports both, even if no NAT was
detected between them (this way, there is no need to change the ports detected between them (this way, there is no need to change the ports
later). later).
4.3. Additional Addresses 3.4. 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 notifications in ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in
the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the
message containing the SA payload). 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)]
skipping to change at page 10, line 29 skipping to change at page 11, line 40
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.
Although both the initiator and responder maintain a set of peer Although both the initiator and responder maintain a set of peer
addresses (logically associated with the IKE_SA), it is important to addresses (logically associated with the IKE_SA), it is important to
note that they use this information for slightly different purposes. note that they use this information for slightly different purposes.
The initiator uses the set of responder addresses as an input to its The initiator uses the set of responder addresses as an input to its
address selection policy; it may, at some later point, decide to move address selection policy; it may, at some later point, decide to move
the IPsec traffic to one of these addresses using the procedure the IPsec traffic to one of these addresses using the procedure
described in Section 4.4. The responder normally does not use the described in Section 3.5. The responder normally does not use the
set of initiator addresses for anything: the addresses are used only set of initiator addresses for anything: the addresses are used only
when the responder's own addresses change (see Section 4.5). when the responder's own addresses change (see Section 3.6).
The set of addresses available to the peers can change during the The set of addresses available to the peers can change during the
lifetime of the IKE_SA. The procedure for updating this information lifetime of the IKE_SA. The procedure for updating this information
is described in Section 4.5. is described in Section 3.6.
Note that if some of the initiator's interfaces are behind a NAT Note that if some of the initiator's interfaces are behind a NAT
(from the responder's point of view), the addresses received by the (from the responder's point of view), the addresses received by the
responder will be incorrect. This means the procedure for changing responder will be incorrect. This means the procedure for changing
responder addresses described in Section 4.5 does not fully work when responder addresses described in Section 3.6 does not fully work when
the initiator is behind a NAT. For the same reason, the peers also 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 SHOULD NOT use this information for any other purpose than what is
explicitly described in this document. explicitly described either in this document or a future
specification updating it.
4.4. Changing Addresses in IPsec SAs 3.5. Changing Addresses in IPsec SAs
In MOBIKE, the initiator decides what addresses are used in the IPsec In MOBIKE, the initiator decides what addresses are used in the IPsec
SAs. That is, the responder usually never updates any IPsec SAs SAs. That is, the responder usually never updates any IPsec SAs
without receiving an explicit UPDATE_SA_ADDRESSES request from the without receiving an explicit UPDATE_SA_ADDRESSES request from the
initiator. (As described below, the responder can, however, update initiator. (As described below, the responder can, however, update
the IKE_SA in some circumstances.) the IKE_SA in some circumstances.)
The reasons why the initiator wishes to change the addresses are The reasons why the initiator wishes to change the addresses are
largely beyond the scope of MOBIKE. Typically, triggers include largely beyond the scope of MOBIKE. Typically, triggers include
information received from lower layers, such as changes in IP information received from lower layers, such as changes in IP
addresses or link-down indications. Some of this information can be addresses or link-down indications. Some of this information can be
unreliable: for instance, ICMP messages could be spoofed by an unreliable: for instance, ICMP messages could be spoofed by an
attacker. Unreliable information itself MUST NOT be used to conclude attacker. Unreliable information SHOULD be treated only as a hint
than an update is needed: instead, the initiator SHOULD trigger dead that there might be a problem, and the initiator SHOULD trigger dead
peer detection (that is, send an INFORMATIONAL request). peer detection (that is, send an INFORMATIONAL request) to determine
if the current path is still usable.
Changing addresses can also be triggered by events within IKEv2. At Changing addresses can also be triggered by events within IKEv2. At
least the following events can cause the initiator to re-evaluate its least the following events can cause the initiator to re-evaluate its
local address selection policy, possibly leading to changing the local address selection policy, possibly leading to changing the
addresses. addresses.
o An IKEv2 request has been re-transmitted several times, but no o An IKEv2 request has been re-transmitted several times, but no
valid reply has been received. This suggests the current path is valid reply has been received. This suggests the current path is
no longer working. no longer working.
o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS or
notifications is received. This means the peer's addresses may NO_ADDITIONAL_ADDRESS notifications is received. This means the
have changed. peer's addresses may have changed. This is particularly important
if the announced set of address no longer contains the currently
used address.
o An UNACCEPTABLE_ADDRESSES notification is received as a response o An UNACCEPTABLE_ADDRESSES notification is received as a response
to address update request (described below). to address update request (described below).
o The initiator receives a NAT_DETECTION_DESTINATION_IP notification o The initiator receives a NAT_DETECTION_DESTINATION_IP notification
that does not match the previous UPDATE_SA_ADDRESSES response (see that does not match the previous UPDATE_SA_ADDRESSES response (see
Section 4.7 for a more detailed description). Section 3.8 for a more detailed description).
The description in the rest of this section assumes that the The description in the rest of this section assumes that the
initiator has already decided what the new addresses should be. When initiator has already decided what the new addresses should be. When
this decision has been made, the initiator: this decision has been made, the initiator:
o Updates the IKE_SA with the new addresses, and sets the o Updates the IKE_SA with the new addresses, and sets the
"pending_update" flag in the IKE_SA. "pending_update" flag in the IKE_SA.
o Updates the IPsec SAs associated with this IKE_SA with the new o Updates the IPsec SAs associated with this IKE_SA with the new
addresses (unless the initiator's policy requires a return addresses (unless the initiator's policy requires a return
routability check before updating the IPsec SAs, and the check has routability check before updating the IPsec SAs, and the check has
not been done for this responder address yet). not been done for this responder address yet).
o If the IPsec SAs were updated in the previous step: If NAT o If the IPsec SAs were updated in the previous step: If NAT
Traversal is not enabled, and the responder supports NAT Traversal Traversal is not enabled, and the responder supports NAT Traversal
(as indicated by NAT detection payloads in the IKE_SA_INIT (as indicated by NAT detection payloads in the IKE_SA_INIT
exchange), and the initiator either suspects or knows that a NAT exchange), and the initiator either suspects or knows that a NAT
is likely to be present, enables NAT Traversal. is likely to be present, enables NAT Traversal (that is, enables
UDP encapsulation of outgoing ESP packets and sending of NAT-
Keepalive packets).
o If there are outstanding IKEv2 requests (requests for which the o If there are outstanding IKEv2 requests (requests for which the
initiator has not yet received a reply), continues retransmitting 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 (which does not containing the UPDATE_SA_ADDRESSES notification (which does not
contain any data), and clears the "pending_update" flag. The contain any data), and clears the "pending_update" flag. The
request will be as follows: request will be as follows:
skipping to change at page 12, line 41 skipping to change at page 13, line 51
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 normal response message received out of order). If it has, a normal response message
(described below) is sent, but no other action is taken. (described below) is sent, but no other action is taken.
o If the NO_NATS_ALLOWED notification is present, processes it as o If the NO_NATS_ALLOWED notification is present, processes it as
described in Section 4.8. described in Section 3.9.
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 a message containing the is not, replies with a message containing the
UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). 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].)
skipping to change at page 13, line 4 skipping to change at page 14, line 14
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 a message containing the is not, replies with a message containing the
UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). 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(NAT_DETECTION_*_IP)], <-- HDR, SK { [N(NAT_DETECTION_*_IP)],
[N(COOKIE2)] } [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 4.6) and waits until the check is initiator address (see Section 3.7) and waits until the check is
completed. completed.
o Updates the IPsec SAs associated with this IKE_SA with the new o Updates the IPsec SAs associated with this IKE_SA with the new
addresses. 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: When the initiator receives the reply:
o If an address change has occurred after the request was first o If an address change has occurred after the request was first
sent, no MOBIKE processing is done for the reply message because a sent, no MOBIKE processing is done for the reply message because a
new UPDATE_SA_ADDRESSES is going to be sent (or has already been new UPDATE_SA_ADDRESSES is going to be sent (or has already been
sent, if window size greater than one is in use). sent, if window size greater than one is in use).
o If the response contains the UNEXPECTED_NAT_DETECTED notification, o If the response contains the UNEXPECTED_NAT_DETECTED notification,
it processes the response as described in Section 4.8. it processes the response as described in Section 3.9.
o If the response contains an UNACCEPTABLE_ADDRESSES notification, o If the response contains an UNACCEPTABLE_ADDRESSES notification,
the initiator MAY select another addresses and retry the exchange, the initiator MAY select another addresses and retry the exchange,
keep on using the current addresses, or disconnect. keep on using the current addresses, or disconnect.
o It updates the IPsec SAs associated with this IKE_SA with the new o It updates the IPsec SAs associated with this IKE_SA with the new
addresses (unless this was already done before sending the addresses (unless this was already done before sending the
request). request).
o If NAT Traversal is supported and NAT detection payloads were o If NAT Traversal is supported and NAT detection payloads were
included, it enables or disables NAT Traversal. included, it enables or disables NAT Traversal.
There is one exception to the rule that the responder never updates There is one exception to the rule that the responder never updates
any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If
the source address that the responder is currently using becomes the source address that the responder is currently using becomes
unavailable (i.e., sending packets using that source address is no unavailable (i.e., sending packets using that source address is no
longer possible), the responder is allowed to update the IPsec SAs to longer possible), the responder is allowed to update the IPsec SAs to
use some other address (in addition to initiating the procedure use some other address (in addition to initiating the procedure
described in the next section). described in the next section).
4.5. Updating Additional Addresses 3.6. Updating Additional Addresses
As described in Section 4.3, both the initiator and responder can As described in Section 3.4, both the initiator and responder can
send a list of additional addresses in the IKE_AUTH exchange. This send a list of additional addresses in the IKE_AUTH exchange. This
information can be updated by sending an INFORMATIONAL exchange information can be updated by sending an INFORMATIONAL exchange
request message that contains either one or more ADDITIONAL_IP4/ request message that contains either one or more ADDITIONAL_IP4/
6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. 6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification.
The message exchange will look as follows: The message exchange will look as follows:
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SK { [N(ADDITIONAL_*_ADDRESS)+], HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
[N(NO_ADDITIONAL_ADDRESSES)], [N(NO_ADDITIONAL_ADDRESSES)],
skipping to change at page 14, line 34 skipping to change at page 15, line 42
NO_ADDITIONAL_ADDRESSES notification is received, the exchange NO_ADDITIONAL_ADDRESSES notification is received, the exchange
responder: responder:
o Determines whether it has already received a newer request to o Determines whether it has already received a newer request to
update the addresses (if a window size greater than one is used, update the addresses (if a window size greater than one is used,
it is possible that the requests are received out of order). If it is possible that the requests are received out of order). If
it has, a response message is sent, but the address set is not it has, a response message is sent, but the address set is not
updated. updated.
o If the NO_NATS_ALLOWED notification is present, processes it as o If the NO_NATS_ALLOWED notification is present, processes it as
described in Section 4.8. described in Section 3.9.
o Updates the set of peer addresses based on the IP header and o Updates the set of peer addresses based on the IP header and
ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESS notifications. ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESS notifications.
o Sends a response. o Sends a response.
The initiator MAY include these notifications in the same request as The initiator MAY include these notifications in the same request as
UPDATE_SA_ADDRESSES. UPDATE_SA_ADDRESSES.
If the request to update the addresses is retransmitted using several If the request to update the addresses is retransmitted using several
skipping to change at page 15, line 7 skipping to change at page 16, line 15
There is one additional complication: when the responder wants to There is one additional complication: when the responder wants to
update the address set, the currently used addresses may no longer update the address set, the currently used addresses may no longer
work. In this case, the responder uses the additional address list work. In this case, the responder uses the additional address list
received from the initiator, and the list of its own addresses, to received from the initiator, and the list of its own addresses, to
determine which addresses to use for sending the INFORMATIONAL determine which addresses to use for sending 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, and certain types of policies may simplify
that says that only the responder's address specified in local implementation. For instance, if the responder has a single fixed
configuration is acceptable. This kind of client does not have to address, it does need to process ADDITIONAL_*_ADDRESS notifications
send or process ADDITIONAL_*_ADDRESS notifications. Similarly, a it receives (beyond ignoring unrecognized status notifications as
simple "VPN gateway" that has only a single address, and is not going already required in [IKEv2]). Furthermore, if the initiator has a
to change it, does not need to send or understand policy saying that only the responder address specified in local
ADDITIONAL_*_ADDRESS notifications. configuration is acceptable, it does not have to send its own
additional addresses to the responder (since the responder does not
need them except when changing its own address).
4.6. Return Routability Check 3.7. Return Routability Check
Both parties can optionally verify that the other party can actually Both parties can optionally verify that the other party can actually
receive packets at the claimed address. This "return routability receive packets at the claimed address. By default, this "return
check" can be done before updating the IPsec SAs, immediately after routability check" SHOULD be performed. In environments where the
updating them, or continuously during the connection. peer is expected to be well-behaved (many corporate VPNs, for
instance), or the address can be verified by some other means (e.g.,
the address is included in the peer's certificate), the return
routability check MAY be omitted.
By default, the return routability check SHOULD be done before The check can be done before updating the IPsec SAs, immediately
updating the IPsec SAs. In environments where the peer is expected after updating them, or continuously during the connection. By
to be well-behaved (many corporate VPNs, for instance), or the default, the return routability check SHOULD be done before updating
address can be verified by some other means (e.g., the address is the IPsec SAs, but in some environments it MAY be postponed until
included in the peer's certificate), the return routability check MAY after the IPsec SAs have been updated.
be omitted or 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: when a valid response is received, we purposes, with one exception (described later in this section): when
know the other party can receive packets at the claimed address. a valid response is received, we know the other party can receive
packets at the claimed address.
To ensure that the peer cannot generate the correct INFORMATIONAL To ensure that the peer cannot generate the correct INFORMATIONAL
response without seeing the request, a new payload is added to response without seeing the request, a new payload is added to
INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY
include a COOKIE2 notification, and if included, the recipient of an include a COOKIE2 notification, and if included, the recipient of an
INFORMATIONAL request MUST copy the notification as-is to the INFORMATIONAL request MUST copy the notification as-is to the
response. When processing the response, the original sender MUST response. When processing the response, the original sender MUST
verify that the value is the same one as sent. If the values do not verify that the value is the same one as sent. If the values do not
match, the IKE_SA MUST be closed. match, the IKE_SA MUST be closed. (See also Section 4.6 for the
format of the COOKIE2 notification.)
If the same INFORMATIONAL request has been sent to several different The exception mentioned earlier is as follows: If the same
addresses (i.e., the destination address in the IKE_SA has been INFORMATIONAL request has been sent to several different addresses
updated after the request was first sent), receiving the (i.e., the destination address in the IKE_SA has been updated after
INFORMATIONAL response does not tell which address is the working the request was first sent), receiving the INFORMATIONAL response
one. In this case, a new INFORMATIONAL request needs to be sent to does not tell which address is the working one. In this case, a new
check return routability. INFORMATIONAL request needs to be sent to check return routability.
4.7. Changes in NAT Mappings 3.8. Changes in NAT Mappings
IKEv2 performs Dead Peer Detection (DPD) if there has recently been IKEv2 performs Dead Peer Detection (DPD) if there has recently been
only outgoing traffic on all of the SAs associated with the IKE_SA. 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 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 have changed (for example, if the keepalive interval is too long, or
the NAT box is rebooted). More specifically, if both peers support the NAT box is rebooted). More specifically, if both peers support
both this specification and NAT Traversal, NAT_DETECTION_*_IP both this specification and NAT Traversal, NAT_DETECTION_*_IP
notifications MAY be included in any INFORMATIONAL request; if the notifications MAY be included in any INFORMATIONAL request; if the
request includes them, the responder MUST also include them in the request includes them, the responder MUST also include them in the
response (but no other action is taken, unless otherwise specified). response (but no other action is taken, unless otherwise specified).
When the initiator is behind a NAT (as detected earlier using When the initiator is behind a NAT (as detected earlier using
NAT_DETECTION_*_IP notifications), it SHOULD include these NAT_DETECTION_*_IP notifications), it SHOULD include these
notifications in DPD messages, and compare the received notifications in DPD messages, and compare the received
NAT_DETECTION_DESTINATION_IP notifications with the value from the NAT_DETECTION_DESTINATION_IP notifications with the value from the
previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response). 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 If the values do not match, the IP address and/or port seen by the
responder has changed, and the initiator SHOULD send responder has changed, and the initiator SHOULD send
UPDATE_SA_ADDRESSES as described in Section 4.4. UPDATE_SA_ADDRESSES as described in Section 3.5. If the initiator
suspects that the NAT mapping has changed, it MAY also skip the
detection step and send UPDATE_SA_ADDRESSES immediately. This saves
one roundtrip if the NAT mapping has indeed changed.
Note that this approach to detecting NAT mapping changes may cause an
extra address update when the IKE_SA is rekeyed. This is because the
NAT_DETECTION_DESTINATION_IP hash also includes the IKE SPIs, which
change when performing rekeying. This unnecessary update is
harmless, however.
When MOBIKE is in use, the dynamic updates specified in [IKEv2] When MOBIKE is in use, the dynamic updates specified in [IKEv2]
Section 2.23 (where the peer address and port are updated from the Section 2.23 (where the peer address and port are updated from the
last valid authenticated packet) work in a slightly different last valid authenticated packet) work in a slightly different
fashion. The host not behind a NAT MUST NOT use these dynamic fashion. The host not behind a NAT MUST NOT use these dynamic
updates for IKEv2 packets, but MAY use them for ESP packets. This updates for IKEv2 packets, but MAY use them for ESP packets. This
ensures that an INFORMATIONAL exchange that does not contain ensures that an INFORMATIONAL exchange that does not contain
UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be
used for, e.g., testing whether a particular path works. used for, e.g., testing whether a particular path works.
4.8. NAT Prohibition 3.9. NAT Prohibition
Basic IKEv2/IPsec without NAT Traversal support may work across some Basic IKEv2/IPsec without NAT Traversal support may work across some
types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in
tunnel mode. This is because the IKEv2 integrity checksum does not tunnel mode. This is because the IKEv2 integrity checksum does not
cover the addresses in the IP header. This may be considered a cover the addresses in the IP header. This may be considered a
problem in some circumstances, because in some sense any modification problem in some circumstances, because in some sense any modification
of the IP addresses can be considered an attack. of the IP addresses can be considered an attack.
This specification addresses the issue by protecting the IP addresses This specification addresses the issue by protecting the IP addresses
when NAT Traversal has not been explicitly enabled. This means that when NAT Traversal has not been explicitly enabled. This means that
MOBIKE without NAT Traversal support will not work if the paths MOBIKE without NAT Traversal support will not work if the paths
contain NATs, IPv4/IPv6 translation agents, or other nodes that contain NATs, IPv4/IPv6 translation agents, or other nodes that
modify the addresses in the IP header. This feature is mainly modify the addresses in the IP header. This feature is mainly
intended for site-to-site VPN cases, where the administrators may intended for IPv6 and site-to-site VPN cases, where the
know beforehand that NATs are not present, and thus any modification administrators may know beforehand that NATs are not present, and
to the packet can be considered an attack. thus any modification to the packet can be considered an attack.
More specifically, when NAT Traversal is not enabled, all messages More specifically, when NAT Traversal is not enabled, all messages
that can update the addresses associated with the IKE_SA and/or IPsec that can update the addresses associated with the IKE_SA and/or IPsec
SAs (the IKE_SA_INIT request and all INFORMATIONAL requests that SAs (the IKE_SA_INIT request and all INFORMATIONAL requests that
contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS
notifications) MUST also include a NO_NATS_ALLOWED notification. The notifications) MUST also include a NO_NATS_ALLOWED notification. The
exchange responder MUST verify that the contents of the exchange responder MUST verify that the contents of the
NO_NATS_ALLOWED notification match the addresses in the IP header. NO_NATS_ALLOWED notification match the addresses in the IP header.
If they do not match, a response containing an If they do not match, a response containing an
UNEXPECTED_NAT_DETECTED notification is sent (and in the case of the UNEXPECTED_NAT_DETECTED notification is sent (and in the case of the
IKE_SA_INIT exchange, no state is created at the responder). The IKE_SA_INIT exchange, no state is created at the responder). The
response message is sent to the address and port that the response message is sent to the address and port that the
corresponding request came from, not to the address contained in the corresponding request came from, not to the address contained in the
NO_NATS_ALLOWED notification. NO_NATS_ALLOWED notification.
If the exchange initiator receives an UNEXPECTED_NAT_DETECTION If the exchange initiator receives an UNEXPECTED_NAT_DETECTED
notification in response to its request, it SHOULD retry the notification in response to its request, it SHOULD retry the
operation several times using new IKE_SA_INIT/INFORMATIONAL requests. operation several times using new IKE_SA_INIT/INFORMATIONAL requests.
This ensures that an attacker who is able to modify only a single This ensures that an attacker who is able to modify only a single
packet does not unnecessarily cause a path to remain unused. packet does not unnecessarily cause a path to remain unused.
If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange
responder MUST NOT use the contents of the NO_NATS_ALLOWED responder MUST NOT use the contents of the NO_NATS_ALLOWED
notification for any other purpose than possibly logging the notification for any other purpose than possibly logging the
information for troubleshooting purposes. information for troubleshooting purposes.
4.9. Path Testing 3.10. 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, Dead Peer Detection alone does not tell which of several addresses, Dead Peer Detection alone does not tell which of
the other paths might work. the other paths might work.
If required by its address selection policy, the initiator can use If required by its address selection policy, the initiator can use
normal IKEv2 INFORMATIONAL request/response messages to test whether normal IKEv2 INFORMATIONAL request/response messages to test whether
a certain path works. Implementations MAY do path testing even if a certain path works. Implementations MAY do path testing even if
the path currently being used is working to, for example, detect when the path currently being used is working to, for example, detect when
a better (but previously unavailable) path becomes available. a better (but previously unavailable) path becomes available.
4.10. Failure Recovery and Timeouts 3.11. Failure Recovery and Timeouts
In MOBIKE, the initiator is responsible for detecting and recovering In MOBIKE, the initiator is responsible for detecting and recovering
from most failures. from most failures.
To give the initiator enough time to detect the error, the responder To give the initiator enough time to detect the error, the responder
SHOULD use relatively long timeout intervals when, for instance, SHOULD use relatively long timeout intervals when, for instance,
retransmitting IKEv2 requests or deciding whether to initiate dead retransmitting IKEv2 requests or deciding whether to initiate dead
peer detection. While no specific timeout lengths are required, it peer detection. While no specific timeout lengths are required, it
is suggested that responders continue retransmitting IKEv2 requests is suggested that responders continue retransmitting IKEv2 requests
for at least five minutes before giving up. for at least five minutes before giving up.
5. Payload Formats 4. Payload Formats
5.1. MOBIKE_SUPPORTED Notify Payload This specification defines several new IKEv2 Notify payload types.
The UNACCEPTABLE_ADDRESSES and UNEXPECTED_NAT_DETECTED notifications
are "error types"; the other notifications are "status types". See
[IKEv2] Section 3.10 for a general description of the Notify payload.
4.1. MOBIKE_SUPPORTED Notify Payload
The MOBIKE_SUPPORTED notification is included in the IKE_AUTH The MOBIKE_SUPPORTED notification is included in the IKE_AUTH
exchange to indicate that the implementation supports this exchange to indicate that the implementation supports this
specification. specification.
The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The
Protocol ID and SPI Size fields are set to zero. There is no data Protocol ID and SPI Size fields are set to zero. The notification
associated with this Notify type. data field MUST be left empty (zero-length) when sending, and its
contents (if any) MUST be ignored when this notification is received.
This allows the field to be used by future versions of this protocol.
5.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads 4.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads
Both parties can include ADDITIONAL_IP4_ADDRESS and/or Both parties can include ADDITIONAL_IP4_ADDRESS and/or
ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and
INFORMATIONAL exchange request messages; see Section 4.3 and INFORMATIONAL exchange request messages; see Section 3.4 and
Section 4.5 for more detailed description. Section 3.6 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-IANA2 and TBD-BY-IANA3, ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA2 and TBD-BY-IANA3,
respectively. The Protocol ID and SPI Size fields are set to zero. respectively. The Protocol ID and SPI Size fields are set to zero.
The data associated with these Notify types is either a four-octet The data associated with these Notify types is either a four-octet
IPv4 address or a 16-octet IPv6 address. IPv4 address or a 16-octet IPv6 address.
5.3. NO_ADDITIONAL_ADDRESSES Notify Payload 4.3. NO_ADDITIONAL_ADDRESSES Notify Payload
The NO_ADDITIONAL_ADDRESSES notification can be included in an The NO_ADDITIONAL_ADDRESSES notification can be included in an
INFORMATIONAL exchange request message to indicate that the exchange INFORMATIONAL exchange request message to indicate that the exchange
initiator does not have addresses beyond the one used in the exchange initiator does not have addresses beyond the one used in the exchange
(see Section 4.5 for more detailed description). (see Section 3.6 for more detailed description).
The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-IANA4. The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-IANA4.
The Protocol ID and SPI Size fields are set to zero. There is no The Protocol ID and SPI Size fields are set to zero. There is no
data associated with this Notify type. data associated with this Notify type.
5.4. UPDATE_SA_ADDRESSES Notify Payload 4.4. UPDATE_SA_ADDRESSES Notify Payload
This notification is included in INFORMATIONAL exchange requests sent This notification is included in INFORMATIONAL exchange requests sent
by the initiator to update addresses of the IKE_SA and IPsec SAs (see by the initiator to update addresses of the IKE_SA and IPsec SAs (see
Section 4.4). Section 3.5).
The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA5. The The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA5. The
Protocol ID and SPI Size fields are set to zero. There is no data Protocol ID and SPI Size fields are set to zero. There is no data
associated with this Notify type. associated with this Notify type.
5.5. UNACCEPTABLE_ADDRESSES Notify Payload 4.5. UNACCEPTABLE_ADDRESSES Notify Payload
The responder can include this notification in an INFORMATIONAL The responder can include this notification in an INFORMATIONAL
exchange response to indicate that the address change in the exchange response to indicate that the address change in the
corresponding request message (which contained an UPDATE_SA_ADDRESSES corresponding request message (which contained an UPDATE_SA_ADDRESSES
notification) was not carried out. notification) was not carried out.
The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA6. The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA6.
The Protocol ID and SPI Size fields are set to zero. There is no The Protocol ID and SPI Size fields are set to zero. There is no
data associated with this Notify type. data associated with this Notify type.
5.6. COOKIE2 Notify Payload 4.6. COOKIE2 Notify Payload
This notification MAY be included in any INFORMATIONAL request for This notification MAY be included in any INFORMATIONAL request for
return routability check purposes (see Section 4.6). If the return routability check purposes (see Section 3.7). If the
INFORMATIONAL request includes COOKIE2, the exchange responder MUST INFORMATIONAL request includes COOKIE2, the exchange responder MUST
copy the notification to the response message. copy the notification 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 by the exchange octets in length (inclusive), and MUST be chosen by the exchange
initiator in a way that is unpredictable to the exchange responder. initiator in a way that is unpredictable to the exchange responder.
The Notify Message Type for this message is TBD-BY-IANA7. The The Notify Message Type for this message is TBD-BY-IANA7. The
Protocol ID and SPI Size fields are set to zero. Protocol ID and SPI Size fields are set to zero.
5.7. NO_NATS_ALLOWED Notify Payload 4.7. NO_NATS_ALLOWED Notify Payload
See Section 4.8 for a description of this notification. See Section 3.9 for a description of this notification.
The data field of this notification contains the following The data field of this notification contains the following
information: the IP address and port from which the packet was sent, information: the IP address from which the packet was sent (4 or 16
and the IP address and port to which the packet was sent. The Notify bytes), the port from which the packet was sent (2 bytes, network
Message Type for this message is TBD-BY-IANA8. The Protocol ID and byte order), the IP addresss to which the packet was sent (4 or 16
SPI Size fields are set to zero. bytes), and the port to which the packet was sent (2 bytes, network
byte order). The total length of the data field is thus 12 bytes for
IPv4 and 36 bytes for IPv6. The Notify Message Type for this message
is TBD-BY-IANA8. The Protocol ID and SPI Size fields are set to
zero.
5.8. UNEXPECTED_NAT_DETECTED Notify Payload 4.8. UNEXPECTED_NAT_DETECTED Notify Payload
See Section 4.8 for a description of this notification. See Section 3.9 for a description of this notification.
The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9. The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9.
The Protocol ID and SPI Size fields are set to zero. There is no The Protocol ID and SPI Size fields are set to zero. There is no
data associated with this Notify type. data associated with this Notify type.
6. Security Considerations 5. Security Considerations
The main goals of this specification are to not reduce the security The main goals of this specification are to maintain 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. This section describes new threats in an appropriate manner. This section describes new
security considerations introduced by MOBIKE. See [IKEv2] for security considerations introduced by MOBIKE. See [IKEv2] for
security considerations for IKEv2 in general. security considerations for IKEv2 in general.
6.1. Traffic Redirection and Hijacking 5.1. Traffic Redirection and Hijacking
MOBIKE payloads relating to updating addresses are encrypted, MOBIKE payloads relating to updating addresses are encrypted,
integrity protected, and replay protected using the IKE_SA. This integrity protected, and replay protected using the IKE_SA. This
assures that no one except the participants can, for instance, give a assures that no one except the participants can, for instance, give a
control message to change the addresses. control message to change the addresses.
However, just like with normal IKEv2, the actual IP addresses in the However, as with normal IKEv2, the actual IP addresses in the IP
IP header are not covered by the integrity protection. This means header are not covered by the integrity protection. This means that
that a NAT between the parties (or an attacker acting as a NAT) can a NAT between the parties (or an attacker acting as a NAT) can modify
modify the addresses and cause incorrect tunnel header (outer) IP the addresses and cause incorrect tunnel header (outer) IP addresses
addresses to be used for IPsec SAs. The scope of this attack is to be used for IPsec SAs. The scope of this attack is limited mainly
limited mainly to denial-of-service because all traffic is protected to denial-of-service because all traffic is protected using IPsec.
using IPsec.
This attack can only be launched by on-path attackers that are This attack can only be launched by on-path attackers that are
capable of modifying IKEv2 messages carrying NAT detection payloads capable of modifying IKEv2 messages carrying NAT detection payloads
(such as Dead Peer Detection messages). By modifying the IP header (such as Dead Peer Detection messages). By modifying the IP header
of these packets, the attackers can lead the peers to believe a new of these packets, the attackers can lead the peers to believe a new
NAT or a changed NAT binding exists between them. The attack can NAT or a changed NAT binding exists between them. The attack can
continue as long as the attacker is on the path, modifying the IKEv2 continue as long as the attacker is on the path, modifying the IKEv2
messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms
designed to detect NAT mapping changes will eventually recognize that designed to detect NAT mapping changes will eventually recognize that
the intended traffic is not getting through, and will update the the intended traffic is not getting through, and will update the
addresses appropriately. addresses appropriately.
MOBIKE introduces the NO_NATS_ALLOWED notification that is used to MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
detect modification, by outsiders, of the addresses in the IP header. detect modification, by outsiders, of the addresses in the IP header.
When this notification is used, communication through NATs and other Such modifications can only be performed by attackers who are on the
address translators is impossible, so it is sent only when not doing path and capable of modifying the When this notification is used,
NAT Traversal. This feature is mainly intended for site-to-site VPN communication through NATs and other address translators is
cases, where the administrators may know beforehand that valid NATs impossible, so it is sent only when not doing NAT Traversal.
are not present, and thus any modification to the packet can be
considered an attack.
6.2. IPsec Payload Protection 5.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 or be should the traffic end up in an incorrect destination or be
eavesdropped along the way. eavesdropped along the way.
However, security associations originally created for the protection However, security associations originally created for the protection
of a specific flow between specific addresses may be updated by of a specific flow between specific addresses may be updated by
MOBIKE later on. This has to be taken into account if the level of MOBIKE later on. This has to be taken into account if the level of
required protection depends on, for instance, the current location of required protection depends on, for instance, the current location of
the VPN client. the VPN client.
It is recommended that security policies, for peers that are allowed It is recommended that security policies, for peers that are allowed
to use MOBIKE, are configured in a manner that takes into account to use MOBIKE, are configured in a manner that takes into account
that a single security association can be used at different times that a single security association can be used at different times
through paths of varying security properties. through paths of varying security properties.
6.3. Denial-of-Service Attacks Against Third Parties 5.3. Denial-of-Service Attacks Against Third Parties
Traffic redirection may be performed not just to gain access to the Traffic redirection may be performed not just to gain access to the
traffic (not very interesting because it is encrypted) or to deny traffic (not very interesting because it is encrypted) or to deny
service to the peers, but also to cause a denial-of-service attack 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 for 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, causing
its communications capabilities to suffer. its communications capabilities to suffer.
The attackers in this threat can be either outsiders or even one of The attackers in this threat can be either outsiders or even one of
the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers
skipping to change at page 22, line 14 skipping to change at page 25, line 11
This specification includes return routability tests to limit the This specification includes return routability tests to limit the
duration of any "third party bombing" attacks by off-path (relative duration of any "third party bombing" attacks by off-path (relative
to the victim) attackers. The tests are authenticated messages that to the victim) attackers. The tests are authenticated messages that
the peer has to respond to, and can be performed either before the the peer has to respond to, and can be performed either before the
address change takes effect, immediately afterwards, or even address change takes effect, immediately afterwards, or even
periodically during the session. The tests contain unpredictable periodically during the session. The tests contain unpredictable
data, and only someone who has the keys associated with the IKE SA data, and only someone who has the keys associated with the IKE SA
and has seen the request packet can properly respond to the test. and has seen the request packet can properly respond to the test.
6.4. Spoofing Network Connectivity Indications 5.4. Spoofing Network Connectivity Indications
Attackers may spoof various indications from lower layers and the Attackers may spoof various indications from lower layers and the
network in an effort to confuse the peers about which addresses are network in an effort to confuse the peers about which addresses are
or are not working. For example, attackers may spoof link-layer or are not working. For example, attackers may spoof link-layer
error messages in an effort to cause the parties to move their error messages in an effort to cause the parties to move their
traffic elsewhere or even to disconnect. Attackers may also spoof traffic elsewhere or even to disconnect. Attackers may also spoof
information related to network attachments, router discovery, and information related to network attachments, router discovery, and
address assignments in an effort to make the parties believe they address assignments in an effort to make the parties believe they
have Internet connectivity when, in reality, they do not. have Internet connectivity when, in reality, they do not.
skipping to change at page 22, line 44 skipping to change at page 25, line 41
Ultimately, MOBIKE depends on the delivery of IKEv2 messages to Ultimately, MOBIKE depends on the delivery of IKEv2 messages to
determine which paths can be used. If IKEv2 messages sent using a determine which paths can be used. If IKEv2 messages sent using a
particular source and destination addresses reach the recipient and a particular source and destination addresses reach the recipient and a
reply is received, MOBIKE will usually consider the path working; if reply is received, MOBIKE will usually consider the path working; if
no reply is received even after retransmissions, MOBIKE will suspect no reply is received even after retransmissions, MOBIKE will suspect
the path is broken. An attacker who can consistently control the the path is broken. An attacker who can consistently control the
delivery or non-delivery of the IKEv2 messages in the network can delivery or non-delivery of the IKEv2 messages in the network can
thus influence which addresses actually get used. thus influence which addresses actually get used.
6.5. Address and Topology Disclosure 5.5. Address and Topology Disclosure
MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications
reveal information about which networks the peers are connected to. reveal information about which networks the peers are connected to.
For example, consider a host A with two network interfaces: a For example, consider a host A with two network interfaces: a
cellular connection and a wired Ethernet connection to a company LAN. cellular connection and a wired Ethernet connection to a company LAN.
If host A now contacts host B using IKEv2/MOBIKE and sends If host A now contacts host B using IKEv2/MOBIKE and sends
ADDITIONAL_IP4/6_ADDRESS notifications, host B receives additional ADDITIONAL_IP4/6_ADDRESS notifications, host B receives additional
information it might not otherwise know. If host A used the cellular information it might not otherwise know. If host A used the cellular
connection for the IKEv2/MOBIKE traffic, host B can also see the connection for the IKEv2/MOBIKE traffic, host B can also see the
skipping to change at page 23, line 20 skipping to change at page 26, line 18
These additional addresses can also disclose more accurate location These additional addresses can also disclose more accurate location
information than just a single address. Suppose that host A uses its information than just a single address. Suppose that host A uses its
cellular connection for IKEv2/MOBIKE traffic, but also sends an cellular connection for IKEv2/MOBIKE traffic, but also sends an
ADDITIONAL_IP4_ADDRESS notification containing an IP address ADDITIONAL_IP4_ADDRESS notification containing an IP address
corresponding to, say, a wireless LAN at a particular coffee shop corresponding to, say, a wireless LAN at a particular coffee shop
location. It is likely that host B can now make a much better guess location. It is likely that host B can now make a much better guess
at A's location than would be possible based on the cellular IP at A's location than would be possible based on the cellular IP
address alone. address alone.
Furthermore, as described in Section 4.3, some of the addresses could Furthermore, as described in Section 3.4, some of the addresses could
also be private addresses behind a NAT. also be private addresses behind a NAT.
In many environments, disclosing address information is not a problem In many environments, disclosing address information is not a problem
(and indeed it cannot be avoided if the hosts wish to use those (and indeed it cannot be avoided if the hosts wish to use those
addresses for IPsec traffic). For instance, a remote access VPN addresses for IPsec traffic). For instance, a remote access VPN
client could consider the corporate VPN gateway sufficiently client could consider the corporate VPN gateway sufficiently
trustworthy for this purpose. trustworthy for this purpose. Furthermore, the ADDITIONAL_IP4/
6_ADDRESS notifications are sent encrypted, so the addresses are not
visible to eavesdroppers (unless, of course, they are later used for
sending IKEv2/IPsec traffic).
However, if MOBIKE is used in some more opportunistic approach, it However, if MOBIKE is used in some more opportunistic approach, it
can be desirable to limit the information that is sent. Naturally, can be desirable to limit the information that is sent. Naturally,
the peers do not have to disclose any addresses they do not want to the peers do not have to disclose any addresses they do not want to
use for IPsec traffic. Also, as noted in Section 4.5, an initiator use for IPsec traffic. Also, as noted in Section 3.6, an initiator
whose policy is to always use the locally configured responder whose policy is to always use the locally configured responder
address does not have to send any ADDITIONAL_IP4/6_ADDRESS payloads. address does not have to send any ADDITIONAL_IP4/6_ADDRESS payloads.
7. IANA Considerations 6. 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 several new IKEv2 notifications whose values This document defines several new IKEv2 notifications whose values
are to be allocated from the "IKEv2 Notify Message Types" namespace. are to be allocated from the "IKEv2 Notify Message Types" namespace.
Notify Message Value Notify Message Value
--------------------------- ----- --------------------------- -----
MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959)
ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959)
ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959)
NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959)
UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959)
UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191)
COOKIE2 TBD-BY-IANA7 (16396..40959) COOKIE2 TBD-BY-IANA7 (16396..40959)
NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959)
UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191)
These notifications are described in Section 5. These notifications are described in Section 4.
8. Acknowledgements 7. 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].
9. References 8. References
9.1. Normative References 8.1. Normative References
[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.
[IPsecArch] [IPsecArch]
Kent, S. and K. Seo, "Security Architecture for the Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
in progress), March 2005. in progress), March 2005.
[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.
9.2. Informative References 8.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 26, line 28 skipping to change at page 29, line 28
March 2003. March 2003.
[UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
Appendix A. Changelog Appendix A. Changelog
(This section should be removed by the RFC editor.) (This section should be removed by the RFC editor.)
Changes from -04 to -05:
o Editorial fixes and clarifications (issue 44, 47, 48, 49, 50, 53,
62, 66, 67, 68, 69).
o Ignore data in MOBIKE_SUPPORTED (issue 61).
Changes from -03 to -04: Changes from -03 to -04:
o Copy-editing done by the RFC editor. o Copy-editing done by the RFC editor.
Changes from -02 to -03: Changes from -02 to -03:
o Editorial fixes and clarifications (issues 42 and 43). o Editorial fixes and clarifications (issues 42 and 43).
o Clarified IANA considerations (issue 42). o Clarified IANA considerations (issue 42).
 End of changes. 122 change blocks. 
245 lines changed or deleted 350 lines changed or added

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