draft-ietf-mobike-protocol-08.txt   rfc4555.txt 
MOBIKE Working Group P. Eronen, Ed. Network Working Group P. Eronen, Ed.
Internet-Draft Nokia Request for Comments: 4555 Nokia
Expires: August 26, 2006 February 22, 2006
IKEv2 Mobility and Multihoming Protocol (MOBIKE) IKEv2 Mobility and Multihoming Protocol (MOBIKE)
draft-ietf-mobike-protocol-08.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any Status of This Memo
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2006. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 the IP addresses associated with IKEv2 and tunnel mode IPsec allows the IP addresses associated with IKEv2 and tunnel mode IPsec
Security Associations to change. A mobile VPN client could use Security Associations to change. A mobile Virtual Private Network
MOBIKE to keep the connection with the VPN gateway active while (VPN) client could use MOBIKE to keep the connection with the VPN
moving from one address to another. Similarly, a multihomed host gateway active while moving from one address to another. Similarly,
could use MOBIKE to move the traffic to a different interface if, for a multihomed host could use MOBIKE to move the traffic to a different
instance, the one currently being used stops working. interface if, for instance, the one currently being used stops
working.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 5 1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6 2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 7 2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 6
2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 10 2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9
3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 11 3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 11 3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10
3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 11 3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10
3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 12 3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 11
3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 12 3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11
3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 13 3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12
3.6. Updating Additional Addresses . . . . . . . . . . . . . . 16 3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15
3.7. Return Routability Check . . . . . . . . . . . . . . . . . 18 3.7. Return Routability Check . . . . . . . . . . . . . . . . . 17
3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18 3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19 3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19
3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20 3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 21 3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 20
3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 21 3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 20
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 22 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 22 4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 21
4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . 22 4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 21
4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 22 5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 24
4.2.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . 22 5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 24
4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS 5.3. Denial-of-Service Attacks against Third Parties . . . . . 25
Notify Payloads . . . . . . . . . . . . . . . . . . . 22 5.4. Spoofing Network Connectivity Indications . . . . . . . . 26
4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . 23 5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27
4.2.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
4.2.5. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . 23 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.6. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . . 29
5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 25 Appendix A. Implementation Considerations . . . . . . . . . . . . 31
5.3. Denial-of-Service Attacks Against Third Parties . . . . . 26 A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31
5.4. Spoofing Network Connectivity Indications . . . . . . . . 27 A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 31
5.5. Address and Topology Disclosure . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Implementation Considerations . . . . . . . . . . . . 32
A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 32
A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 32
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Introduction 1. Introduction
1.1. Motivation 1.1. Motivation
IKEv2 is used for performing mutual authentication, as well as IKEv2 is used for performing mutual authentication, as well as
establishing and maintaining IPsec Security Associations (SAs). In establishing and maintaining IPsec Security Associations (SAs). In
the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec
SAs are created implicitly between the IP addresses that are used SAs are created implicitly between the IP addresses that are used
when the IKE_SA is established. These IP addresses are then used as when the IKE_SA is established. These IP addresses are then used as
skipping to change at page 4, line 39 skipping to change at page 3, line 39
token card. Creating new SAs often involves expensive calculations token card. Creating new SAs often involves expensive calculations
and possibly a large number of round-trips. For these reasons, a and possibly a large number of round-trips. For these reasons, a
mechanism for updating the IP addresses of existing IKE and IPsec SAs mechanism for updating the IP addresses of existing IKE and IPsec SAs
is needed. The MOBIKE protocol described in this document provides is needed. The MOBIKE protocol described in this document provides
such a mechanism. 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 the office's wireless LAN. When leaving the office the move to the office's wireless LAN. When the user leaves the office,
laptop could start using GPRS; when the user arrives home, the laptop the laptop could start using General Packet Radio Service (GPRS);
could switch to the home wireless LAN. MOBIKE updates only the outer when the user arrives home, the laptop could switch to the home
(tunnel header) addresses of IPsec SAs, and the addresses and other wireless LAN. MOBIKE updates only the outer (tunnel header)
traffic selectors used inside the tunnel stay unchanged. Thus, addresses of IPsec SAs, and the addresses and other traffic selectors
mobility can be (mostly) invisible to applications and their used inside the tunnel stay unchanged. Thus, mobility can be
connections using the VPN. (mostly) invisible to applications and their connections using the
VPN.
MOBIKE also supports more complex scenarios where the VPN gateway MOBIKE also supports more complex scenarios where the VPN gateway
also has several network interfaces: these interfaces could be also has several network interfaces: these interfaces could be
connected to different networks or ISPs, they may be a mix of IPv4 connected to different networks or ISPs, they may be a mix 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.
1.2. Scope and Limitations 1.2. Scope and Limitations
This document focuses on the main scenario outlined above, and This document focuses on the main scenario outlined above and
supports only tunnel mode IPsec SAs. supports only tunnel mode IPsec SAs.
The mobility support in MOBIKE allows both parties to move, but does The mobility support in MOBIKE allows both parties to move, but does
not provide a "rendezvous" mechanism that would allow simultaneous not provide a "rendezvous" mechanism that would allow simultaneous
movement of both parties, or discovering the addresses when the movement of both parties or discovery of the addresses when the
IKE_SA is first established. Therefore, MOBIKE is best suited for IKE_SA is first established. Therefore, MOBIKE is best suited for
situations where the address of at least one endpoint is relatively situations where the address of at least one endpoint is relatively
stable, and can be discovered using existing mechanisms such as DNS stable and can be discovered using existing mechanisms such as DNS
(see Section 3.1). (see Section 3.1).
MOBIKE allows both parties to be multihomed; however, only one pair MOBIKE allows both parties to be multihomed; however, only one pair
of addresses is used for an SA at a time. In particular, load of addresses is used for an SA at a time. In particular, load
balancing is beyond the scope of this specification. balancing is beyond the scope of this specification.
MOBIKE follows the IKEv2 practice where a response message is sent to MOBIKE follows the IKEv2 practice where a response message is sent to
the same address and port from which the request was received. This the same address and port from which the request was received. This
implies that MOBIKE does not work over address pairs that provide implies that MOBIKE does not work over address pairs that provide
only unidirectional connectivity. only unidirectional connectivity.
NATs introduce additional limitations beyond those listed above. For Network Address Translators (NATs) introduce additional limitations
details, refer to Section 2.3. beyond those listed above. For details, refer to Section 2.3.
The base version of the MOBIKE protocol does not cover all potential The base version of the MOBIKE protocol does not cover all potential
future use scenarios, such as transport mode, application to securing future use scenarios, such as transport mode, application to securing
SCTP, or optimizations desirable in specific circumstances. Future SCTP, or optimizations desirable in specific circumstances. Future
extensions may be defined later to support additional requirements. extensions may be defined later to support additional requirements.
Please consult the MOBIKE design document [Design] for further Please consult the MOBIKE design document [Design] for further
information and rationale behind these limitations. information and rationale behind these limitations.
1.3. Terminology and Notation 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+"). To provide context, some diagrams also show what instance, "FOO+"). To provide context, some diagrams also show what
existing IKEv2 payloads would typically be included in the exchanges. existing IKEv2 payloads would typically be included in the exchanges.
These payloads are shown for illustrative purposes only; see [IKEv2] These payloads are shown for illustrative purposes only; see [IKEv2]
for an authoritative description. for an authoritative description.
When this document talks about updating the source/destination When this document describes 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 Encapsulating Security Payload (ESP)/Authentication
header. Depending on how the nominal division between Security Header (AH) packets use those addresses in the tunnel header.
Association Database (SAD), Security Policy Database (SPD), and Peer Depending on how the nominal divisions between Security Association
Authorization Database (PAD) described in [IPsecArch] is actually Database (SAD), Security Policy Database (SPD), and Peer
Authorization Database (PAD) described in [IPsecArch] are actually
implemented, an implementation can have several different places that implemented, an implementation can have several different places that
have to be updated. have to be updated.
In this document, the term "initiator" means the party who originally In this document, the term "initiator" means the party who originally
initiated the first IKE_SA (in a series of possibly several rekeyed initiated the first IKE_SA (in a series of possibly several rekeyed
IKE_SAs); "responder" is the other peer. During the lifetime of the IKE_SAs); "responder" is the other peer. During the lifetime of the
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
skipping to change at page 6, line 40 skipping to change at page 5, line 48
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 in the network, problems at the local link at either end, and outages in the network, problems at the local link at 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. This approach applies to the addresses in the initiator to do so. This approach applies to the addresses in the
IPsec SAs; in the IKE_SA case, the exchange initiator can decide IPsec SAs; in the IKE_SA case, the exchange initiator can decide
which addresses are used. 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 a 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
skipping to change at page 7, line 20 skipping to change at page 6, line 26
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).
Many of these issues are not specific to MOBIKE, but are common with Many of these issues are not specific to MOBIKE, but are common with
the use of existing hosts in dynamic environments or with mobility the use of existing hosts in dynamic environments or with mobility
protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms
already exist or are being developed to deal with these issues. For already exist or are being developed to deal with these issues. For
instance, link layer and IP layer mechanisms can be used to track the instance, link-layer and IP-layer mechanisms can be used to track the
status of connectivity within the local link [RFC2461]; movement status of connectivity within the local link [RFC2461]; movement
detection is being specified for both IPv4 and IPv6 in [DNA4], detection is being specified for both IPv4 and IPv6 in [DNA4],
[DNA6], and so on. [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 translation agents, or other similar devices. This feature is
enabled only when NAT Traversal is not used. enabled only when NAT Traversal is not used.
2.2. Example Protocol Exchanges 2.2. Example Protocol Exchanges
A simple MOBIKE exchange in a mobile scenario is illustrated below. A simple MOBIKE exchange in a mobile scenario is illustrated below.
The notation is based on [IKEv2] Section 1.2. In addition, the The notation is based on [IKEv2], Section 1.2. In addition, the
source/destination IP addresses and ports are shown for each packet: source/destination IP addresses and ports are shown for each packet:
here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by
the initiator and the responder. the initiator and the responder.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
1) (IP_I1:500 -> IP_R1:500) 1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni, HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) --> N(NAT_DETECTION_DESTINATION_IP) -->
skipping to change at page 8, line 41 skipping to change at page 7, line 41
3) (IP_I2:4500 -> IP_R1:4500) 3) (IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES), HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } --> N(NAT_DETECTION_DESTINATION_IP) } -->
<-- (IP_R1:4500 -> IP_I2:4500) <-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP), HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } N(NAT_DETECTION_DESTINATION_IP) }
(Responder verifies that the initiator has given it (Responder verifies that the initiator has given it a correct IP
a correct IP address.) address.)
4) <-- (IP_R1:4500 -> IP_I2:4500) 4) <-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(COOKIE2) } HDR, SK { N(COOKIE2) }
(IP_I2:4500 -> IP_R1:4500) (IP_I2:4500 -> IP_R1:4500)
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 by sending an INFORMATIONAL request containing the this by sending an INFORMATIONAL request containing the
UPDATE_SA_ADDRESSES notification. The request is sent using the new UPDATE_SA_ADDRESSES notification. The request is sent using the new
IP address. At this point, it also starts to use the new address as IP address. At this point, it also starts to use the new address as
a source address in its own outgoing ESP traffic. Upon receiving the a source address in its own outgoing ESP traffic. Upon receiving the
UPDATE_SA_ADDRESSES notification the responder records the new UPDATE_SA_ADDRESSES notification, the responder records the new
address, and if so required by policy, performs a return routability address and, if it is required by policy, performs a return
check of the address. When this check (step 4) completes, the routability check of the address. When this check (step 4)
responder starts to use the new address as the destination for its completes, the responder starts to use the new address as the
outgoing ESP traffic. 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) (IP_I1:500 -> IP_R1:500) 1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni, HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_SOURCE_IP),
skipping to change at page 9, line 43 skipping to change at page 8, line 43
SAi2, TSi, TSr, SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } --> N(MOBIKE_SUPPORTED) } -->
<-- (IP_R1:4500 -> IP_I1:4500) <-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH, HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY), CP(CFG_REPLY),
SAr2, TSi, TSr, SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED), N(MOBIKE_SUPPORTED),
N(ADDITIONAL_IP4_ADDRESS) } N(ADDITIONAL_IP4_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) (IP_I1:4500 -> IP_R1:4500) 3) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP), HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } --> N(NAT_DETECTION_DESTINATION_IP) } -->
(IP_I1:4500 -> IP_R1:4500) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP), HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } --> N(NAT_DETECTION_DESTINATION_IP) } -->
... ...
(Eventually, the initiator gives up on the current address pair, and (Eventually, the initiator gives up on the current address pair and
tests the other available address pair.) tests the other available address pair.)
4) (IP_I1:4500 -> IP_R2:4500) 4) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP), HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } N(NAT_DETECTION_DESTINATION_IP) }
<-- (IP_R2:4500 -> IP_I1:4500) <-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP), HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } N(NAT_DETECTION_DESTINATION_IP) }
skipping to change at page 10, line 41 skipping to change at page 9, line 41
N(NAT_DETECTION_DESTINATION_IP), N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) } --> N(COOKIE2) } -->
<-- (IP_R2:4500 -> IP_I1:4500) <-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP), HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP), N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) } N(COOKIE2) }
2.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 simply
about NATs). The NAT Traversal feature specified in [IKEv2] allows describes NATs). The NAT Traversal feature specified in [IKEv2]
IKEv2 to work through NATs in many cases, and MOBIKE can leverage allows IKEv2 to work through NATs in many cases, and MOBIKE can
this functionality: when the addresses used for IPsec SAs are leverage this functionality: when the addresses used for IPsec SAs
changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed. are 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 into the network: only packets coming from the
"inside" cause state to be created. This asymmetry leads to "inside" cause state to be created. This asymmetry leads to
restrictions on what MOBIKE can do. To give a concrete example, restrictions on what MOBIKE can do. To give a concrete example,
consider a situation where both peers have only a single address, and consider a situation where both peers have only a single address, and
the initiator is behind a NAT. If the responder's address now the initiator is behind a NAT. If the responder's address now
changes, it needs to send a packet to the initiator using its new changes, it needs to send a packet to the initiator using its new
address. However, if the NAT is, for instance, of the common address. However, if the NAT is, for instance, of the common
"restricted cone" type (see [STUN] for one description of different "restricted cone" type (see [STUN] for one description of different
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
the new address (unless the initiator has previously sent a packet to from the new address (unless the initiator has previously sent a
that address -- which it cannot do until it knows the address). packet to 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 the case where the
support the case where the responder's addresses change, meaning that responder's addresses change is not fully supported (meaning that no
no special effort is made to support this functionality. Responders special effort is made to support this functionality). Responders
may also be unaware of NATs or specific types of NATs they are may also be unaware of NATs or specific types of NATs they are
behind. However, when a change has occurred that will cause a loss behind. However, when a change has occurred that will cause a loss
of connectivity, MOBIKE responders will still attempt to inform the of connectivity, MOBIKE responders will still attempt to inform the
initiator of the change. Depending on, for instance, the exact type initiator of the change. Depending on, for instance, the exact type
of NAT, it may or may not succeed. However, analyzing the exact 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 circumstances when this will or will not work is not done in this
document. document.
3. Protocol Exchanges 3. Protocol Exchanges
skipping to change at page 12, line 19 skipping to change at page 11, line 21
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 from the IP header of the addresses in the IKE_SA are initialized from the IP header of the
first IKE_AUTH request. first IKE_AUTH request.
The addresses are taken from the IKE_AUTH request because IKEv2 The addresses are taken from the IKE_AUTH request because IKEv2
requires changing from port 500 to 4500 if a NAT is discovered. To requires changing from port 500 to 4500 if a NAT is discovered. To
simplify things, implementations that support both this specification simplify things, implementations that support both this specification
and NAT Traversal MUST change to port 4500 if the correspondent also and NAT Traversal MUST change to port 4500 if the correspondent also
supports both, even if no NAT was detected between them (this way, supports both, even if no NAT was detected between them (this way,
there is no need to change the ports later if a a NAT is detected on there is no need to change the ports later if a NAT is detected on
some other path). some other path).
3.4. 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). Here "ADDITIONAL_*_ADDRESS" message containing the SA payload). Here "ADDITIONAL_*_ADDRESS"
means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS
notification. notification.
skipping to change at page 13, line 39 skipping to change at page 12, line 39
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 SHOULD be treated only as a hint attacker. Unreliable information SHOULD be treated only as a hint
that there might be a problem, and 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) to determine Peer Detection (that is, send an INFORMATIONAL request) to determine
if the current path is still usable. 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 an ADDITIONAL_IP4_ADDRESS, o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS,
ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
received. This means the peer's addresses may have changed. This received. This means the peer's addresses may have changed. This
is particularly important if the announced set of address no is particularly important if the announced set of addresses no
longer contains the currently used address. 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 3.8 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
skipping to change at page 16, line 11 skipping to change at page 15, line 16
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 3.9. the initiator 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 previously used addresses, or disconnect. keep on using the previously used 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 earlier before sending the addresses (unless this was already done earlier before sending the
request; this is the case when no return routability check was request; this is the case when no return routability check was
required). required).
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, the initiator 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).
3.6. Updating Additional Addresses 3.6. Updating Additional Addresses
skipping to change at page 17, line 28 skipping to change at page 16, line 34
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 3.9. described in Section 3.9.
o Updates the set of peer addresses based on the IP header and the o Updates the set of peer addresses based on the IP header and the
ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS and ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, and
NO_ADDITIONAL_ADDRESSES notifications. NO_ADDITIONAL_ADDRESSES 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
different source addresses, a new INFORMATIONAL request MUST be sent. different source addresses, a new INFORMATIONAL request MUST be sent.
skipping to change at page 17, line 52 skipping to change at page 17, line 10
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, and certain types of policies may simplify are acceptable to use, and certain types of policies may simplify
implementation. For instance, if the responder has a single fixed implementation. For instance, if the responder has a single fixed
address, it does not need to process the ADDITIONAL_IP4_ADDRESS and address, it does not need to process the ADDITIONAL_IP4_ADDRESS and
ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring
unrecognized status notifications as already required in [IKEv2]). unrecognized status notifications, as already required in [IKEv2]).
Furthermore, if the initiator has a policy saying that only the Furthermore, if the initiator has a policy saying that only the
responder address specified in local configuration is acceptable, it responder address specified in local configuration is acceptable, it
does not have to send its own additional addresses to the responder does not have to send its own additional addresses to the responder
(since the responder does not need them except when changing its own (since the responder does not need them except when changing its own
address). address).
3.7. 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. By default, this "return receive packets at the claimed address. By default, this "return
skipping to change at page 19, line 16 skipping to change at page 18, line 27
have changed (for example, if the keepalive interval 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, the both this specification and NAT Traversal, the
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_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 the When the initiator is behind a NAT (as detected earlier using the
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
notifications), it SHOULD include these notifications in DPD notifications), it SHOULD include these notifications in DPD messages
messages, and compare the received NAT_DETECTION_DESTINATION_IP and compare the received NAT_DETECTION_DESTINATION_IP notifications
notifications with the value from the previous UPDATE_SA_ADDRESSES with the value from the previous UPDATE_SA_ADDRESSES response (or the
response (or the IKE_SA_INIT response). If the values do not match, IKE_SA_INIT response). If the values do not match, the IP address
the IP address and/or port seen by the responder has changed, and the and/or port seen by the responder has changed, and the initiator
initiator SHOULD send UPDATE_SA_ADDRESSES as described in SHOULD send UPDATE_SA_ADDRESSES as described in Section 3.5. If the
Section 3.5. If the initiator suspects that the NAT mapping has initiator suspects that the NAT mapping has changed, it MAY also skip
changed, it MAY also skip the detection step and send the detection step and send UPDATE_SA_ADDRESSES immediately. This
UPDATE_SA_ADDRESSES immediately. This saves one roundtrip if the NAT saves one roundtrip if the NAT mapping has indeed changed.
mapping has indeed changed.
Note that this approach to detecting NAT mapping changes may cause an 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 extra address update when the IKE_SA is rekeyed. This is because the
NAT_DETECTION_DESTINATION_IP hash also includes the IKE SPIs, which NAT_DETECTION_DESTINATION_IP hash also includes the IKE Security
change when performing rekeying. This unnecessary update is Parameter Indexes (SPIs), which change when performing rekeying.
harmless, however. 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.
3.9. 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
skipping to change at page 21, line 16 skipping to change at page 20, line 30
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.
3.11. 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.
3.12. Dead Peer Detection 3.12. Dead Peer Detection
MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but
as addresses may change, it is not sufficient to just verify that the as addresses may change, it is not sufficient to just verify that the
peer is alive, but also that it is synchronized with the address peer is alive, but also that it is synchronized with the address
updates and has not, for instance, ignored an address update due to updates and has not, for instance, ignored an address update due to
failure to complete return routability test. This means that when failure to complete return routability test. This means that when
there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the
addresses used in those packets and determine that they correspond to addresses used in those packets and determine that they correspond to
those that should be employed. If they do not, such packets SHOULD those that should be employed. If they do not, such packets SHOULD
NOT be used as evidence that the peer is able to communicate with NOT be used as evidence that the peer is able to communicate with
this node and or that the peer has received all address updates. this node and or that the peer has received all address updates.
4. Payload Formats 4. Payload Formats
This specification defines several new IKEv2 Notify payload types. This specification defines several new IKEv2 Notify payload types.
See [IKEv2] Section 3.10 for a general description of the Notify See [IKEv2], Section 3.10, for a general description of the Notify
payload. payload.
4.1. Notify Messages - Error Types 4.1. Notify Messages - Error Types
4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload 4.1.1. 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 40. The
The Protocol ID and SPI Size fields are set to zero. There is no Protocol ID and SPI Size fields are set to zero. There is no data
data associated with this Notify type. associated with this Notify type.
4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload 4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload
See Section 3.9 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 41. The
The Protocol ID and SPI Size fields are set to zero. There is no Protocol ID and SPI Size fields are set to zero. There is no data
data associated with this Notify type. associated with this Notify type.
4.2. Notify Messages - Status Types 4.2. Notify Messages - Status Types
4.2.1. MOBIKE_SUPPORTED Notify Payload 4.2.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 16396. The Protocol
Protocol ID and SPI Size fields are set to zero. The notification ID and SPI Size fields are set to zero. The notification data field
data field MUST be left empty (zero-length) when sending, and its MUST be left empty (zero-length) when sending, and its contents (if
contents (if any) MUST be ignored when this notification is received. any) MUST be ignored when this notification is received. This allows
This allows the field to be used by future versions of this protocol. the field to be used by future versions of this protocol.
4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify 4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify
Payloads 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 3.4 and INFORMATIONAL exchange request messages; see Section 3.4 and
Section 3.6 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 16397 and 16398, respectively. The
respectively. The Protocol ID and SPI Size fields are set to zero. Protocol ID and SPI Size fields are set to zero. The data associated
The data associated with these Notify types is either a four-octet with these Notify types is either a four-octet IPv4 address or a
IPv4 address or a 16-octet IPv6 address. 16-octet IPv6 address.
4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload 4.2.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 3.6 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 16399. The
The Protocol ID and SPI Size fields are set to zero. There is no Protocol ID and SPI Size fields are set to zero. There is no data
data associated with this Notify type. associated with this Notify type.
4.2.4. UPDATE_SA_ADDRESSES Notify Payload 4.2.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 3.5). 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 16400. 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.
4.2.5. COOKIE2 Notify Payload 4.2.5. 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 3.7). 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 16401. The Protocol ID
Protocol ID and SPI Size fields are set to zero. and SPI Size fields are set to zero.
4.2.6. NO_NATS_ALLOWED Notify Payload 4.2.6. NO_NATS_ALLOWED Notify Payload
See Section 3.9 for a description of this notification. See Section 3.9 for a description of this notification.
The Notify Message Type for this message is TBD-BY-IANA8. The The Notify Message Type for this message is 16402. The notification
notification data contains the IP addresses and ports from/to which data contains the IP addresses and ports from/to which the packet was
the packet was sent. For IPv4, the notification data is 12 octets sent. For IPv4, the notification data is 12 octets long and is
long and is defined as follows: defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source IPv4 address ! ! Source IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Destination IPv4 address ! ! Destination IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port ! ! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 25 skipping to change at page 24, line 25
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, as with normal IKEv2, the actual IP addresses in the IP However, as with normal IKEv2, the actual IP addresses in the IP
header are not covered by the integrity protection. This means that header are not covered by the integrity protection. This means that
a NAT between the parties (or an attacker acting as a NAT) can modify a NAT between the parties (or an attacker acting as a NAT) can modify
the addresses and cause incorrect tunnel header (outer) IP addresses the addresses and cause incorrect tunnel header (outer) IP addresses
to be used for IPsec SAs. The scope of this attack is limited mainly to be used for IPsec SAs. The scope of this attack is limited mainly
to denial-of-service because all traffic is protected using IPsec. to denial of service because all traffic is protected 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
skipping to change at page 26, line 23 skipping to change at page 25, line 23
from certain IP addresses. from certain IP addresses.
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.
This is especially critical for traffic selector authorization. The This is especially critical for traffic selector authorization. The
(logical) Peer Authorization Database (PAD) contains the information (logical) Peer Authorization Database (PAD) contains the information
used by IKEv2 when determining what kind of IPsec SAs a peer is used by IKEv2 when determining what kind of IPsec SAs a peer is
allowed to create. This process is described in [IPsecArch] Section allowed to create. This process is described in [IPsecArch], Section
4.4.3. When a peer requests the creation of an IPsec SA with some 4.4.3. When a peer requests the creation of an IPsec SA with some
traffic selectors, the PAD must contain "Child SA Authorization Data" traffic selectors, the PAD must contain "Child SA Authorization Data"
linking the identity authenticated by IKEv2 and the addresses linking the identity authenticated by IKEv2 and the addresses
permitted for traffic selectors. See also [Clarifications] for a permitted for traffic selectors. See also [Clarifications] for a
more extensive discussion. more extensive discussion.
It is important to note that simply sending IKEv2 packets using some It is important to note that simply sending IKEv2 packets using some
particular address does not automatically imply a permission to particular address does not automatically imply a permission to
create IPsec SAs with that address in the traffic selectors. create IPsec SAs with that address in the traffic selectors.
However, some implementations are known to use policies where simply However, some implementations are known to use policies where simply
skipping to change at page 26, line 46 skipping to change at page 25, line 46
the ability to send (or spoof) IP packets with source address X and the ability to send (or spoof) IP packets with source address X and
receive (or eavesdrop) packets sent to X. receive (or eavesdrop) packets sent to X.
Using this kind of policies or extensions with MOBIKE may need Using this kind of policies or extensions with MOBIKE may need
special care to enforce the temporary nature of the permission. For special care to enforce the temporary nature of the permission. For
example, when the peer moves to some other address Y (and is no example, when the peer moves to some other address Y (and is no
longer reachable at X), it might be necessary to close IPsec SAs with longer reachable at X), it might be necessary to close IPsec SAs with
traffic selectors matching X. However, these interactions are beyond traffic selectors matching X. However, these interactions are beyond
the scope of this document. the scope of this document.
5.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 or to deny service to the peers, but also to cause a denial- traffic or to deny service to the peers, but also to cause a denial-
of-service attack for a third party. For instance, a high-speed TCP of-service attack on a third party. For instance, a high-speed TCP
session or a multimedia stream may be redirected towards a victim session or a multimedia stream may be redirected towards a victim
host, causing its communications capabilities to suffer. host, causing 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
can be easily dealt with if the authentication performed in the can be easily dealt with if the authentication performed in the
initial IKEv2 negotiation can be traced to persons who can be held initial IKEv2 negotiation can be traced to persons who can be held
responsible for the attack. This may not be the case in all responsible for the attack. This may not be the case in all
scenarios, particularly with opportunistic approaches to security. scenarios, particularly with opportunistic approaches to security.
skipping to change at page 27, line 33 skipping to change at page 26, line 33
filtering, this attack is largely prevented for MOBIKE as well. filtering, this attack is largely prevented for MOBIKE as well.
Consequently, it makes little sense to protect against attacks of Consequently, it makes little sense to protect against attacks of
similar nature in MOBIKE. However, it still makes sense to limit the similar nature in MOBIKE. However, it still makes sense to limit the
amplification capabilities provided to attackers, so that they cannot amplification capabilities provided to attackers, so that they cannot
use stream redirection to send a large number of packets to the use stream redirection to send a large number of packets to the
victim by sending just a few packets themselves. victim by sending just a few packets themselves.
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 before the address
address change takes effect, immediately afterwards, or even change takes effect, immediately afterwards, or even periodically
periodically during the session. The tests contain unpredictable during the session. The tests contain unpredictable data, and only
data, and only someone who has the keys associated with the IKE SA someone who has the keys associated with the IKE SA and has seen the
and has seen the request packet can properly respond to the test. request packet can properly respond to the test.
The duration of the attack can also be limited if the victim reports The duration of the attack can also be limited if the victim reports
the unwanted traffic to the originating IPsec tunnel endpoint using the unwanted traffic to the originating IPsec tunnel endpoint using
ICMP error messages or INVALID_SPI notifications. As described in ICMP error messages or INVALID_SPI notifications. As described in
[IKEv2] Section 2.21, this SHOULD trigger a liveness test, which also [IKEv2], Section 2.21, this SHOULD trigger a liveness test, which
doubles as a return routability check if the COOKIE2 notification is also doubles as a return routability check if the COOKIE2
included. notification is included.
5.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.
This may cause use of non-preferred addresses or even denial-of- This may cause use of non-preferred addresses or even denial of
service. service.
MOBIKE does not provide any protection of its own for indications MOBIKE does not provide any protection of its own for indications
from other parts of the protocol stack. These vulnerabilities can be from other parts of the protocol stack. These vulnerabilities can be
mitigated through the use of techniques specific to the other parts mitigated through the use of techniques specific to the other parts
of the stack, such as validation of ICMP errors [ICMPAttacks], link of the stack, such as validation of ICMP errors [ICMPAttacks], link
layer security, or the use of [SEND] to protect IPv6 Router and layer security, or the use of [SEND] to protect IPv6 Router and
Neighbor Discovery. Neighbor Discovery.
Ultimately, MOBIKE depends on the delivery of IKEv2 messages to Ultimately, MOBIKE depends on the delivery of IKEv2 messages to
skipping to change at page 29, line 33 skipping to change at page 28, line 33
address does not have to send any ADDITIONAL_IP4_ADDRESS/ address does not have to send any ADDITIONAL_IP4_ADDRESS/
ADDITIONAL_IP6_ADDRESS payloads. ADDITIONAL_IP6_ADDRESS payloads.
6. 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. have been allocated from the "IKEv2 Notify Message Types" namespace.
Notify Messages - Error Types Value Notify Messages - Error Types Value
----------------------------- ----- ----------------------------- -----
UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) UNACCEPTABLE_ADDRESSES 40
UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) UNEXPECTED_NAT_DETECTED 41
Notify Messages - Status Types Value Notify Messages - Status Types Value
------------------------------ ----- ------------------------------ -----
MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) MOBIKE_SUPPORTED 16396
ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) ADDITIONAL_IP4_ADDRESS 16397
ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) ADDITIONAL_IP6_ADDRESS 16398
NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) NO_ADDITIONAL_ADDRESSES 16399
UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) UPDATE_SA_ADDRESSES 16400
COOKIE2 TBD-BY-IANA7 (16396..40959) COOKIE2 16401
NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) NO_NATS_ALLOWED 16402
These notifications are described in Section 4. These notifications are described in Section 4.
7. 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, Tuomas Aura, Marcelo would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo
Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti, Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti,
Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann, Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann,
Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld, Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld,
Maureen Stillman, Shinta Sugimoto, Sami Vaarala, and Hannes Maureen Stillman, Shinta Sugimoto, Hannes Tschofenig, and Sami
Tschofenig. This document also incorporates ideas and text from Vaarala. This document also incorporates ideas and text from earlier
earlier MOBIKE-like protocol proposals, including [AddrMgmt], MOBIKE-like protocol proposals, including [AddrMgmt], [Kivinen],
[Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design document [MOPO], and [SMOBIKE], and the MOBIKE design document [Design].
[Design].
8. References 8. References
8.1. Normative References 8.1. Normative References
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2)
RFC 4306, December 2005. Protocol", RFC 4306, December 2005.
[IPsecArch] [IPsecArch] Kent, S. and K. Seo, "Security Architecture for the
Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 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.
8.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", Work in Progress, November 2005.
draft-dupont-ikev2-addrmgmt-08 (work in progress),
November 2005.
[Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of
Location Management", Proc. 18th Annual Computer Security Internet Location Management", Proc. 18th Annual
Applications Conference (ACSAC), December 2002. Computer Security Applications Conference (ACSAC),
December 2002.
[Bombing] Dupont, F., "A note about 3rd party bombing in Mobile [Bombing] Dupont, F., "A note about 3rd party bombing in
IPv6", draft-dupont-mipv6-3bombing-03 (work in progress), Mobile IPv6", Work in Progress, December 2005.
December 2005.
[Clarifications] [Clarifications] Eronen, P. and P. Hoffman, "IKEv2 Clarifications
Eronen, P. and P. Hoffman, "IKEv2 Clarifications and and Implementation Guidelines", Work in Progress,
Implementation Guidelines", February 2006.
draft-eronen-ipsec-ikev2-clarifications-07 (work in
progress), February 2006.
[DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting [DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment (DNA) in IPv4", Network Attachment in IPv4 (DNAv4)", RFC 4436,
draft-ietf-dhc-dna-ipv4-18 (work in progress), March 2006.
December 2005.
[DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting [DNA6] Narayanan, S., Daley, G., and N. Montavont,
Network Attachment in IPv6 - Best Current Practices for "Detecting Network Attachment in IPv6 - Best
hosts", draft-ietf-dna-hosts-02 (work in progress), Current Practices for hosts", Work in Progress,
October 2005. October 2005.
[Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE [Design] Kivinen, T. and H. Tschofenig, "Design of the
protocol", draft-ietf-mobike-design-07 (work in progress), MOBIKE protocol", Work in Progress, January 2006.
January 2006.
[ICMPAttacks] [ICMPAttacks] Gont, F., "ICMP attacks against TCP", Work in
Gont, F., "ICMP attacks against TCP", Progress, October 2005.
draft-gont-tcpm-icmp-attacks-05 (work in progress),
October 2005.
[Kivinen] Kivinen, T., "MOBIKE protocol", [Kivinen] Kivinen, T., "MOBIKE protocol", Work in Progress,
draft-kivinen-mobike-protocol-00 (work in progress),
February 2004. February 2004.
[MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [MIP4] Perkins, C., "IP Mobility Support for IPv4",
August 2002. RFC 3344, August 2002.
[MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
in IPv6", RFC 3775, June 2004. Support in IPv6", RFC 3775, June 2004.
[MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO- [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2
IKE)", draft-eronen-mobike-mopo-02 (work in progress), (MOPO-IKE)", Work in Progress, February 2005.
February 2005.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
Neighbor Discovery (SEND)", RFC 3971, March 2005. "SEcure Neighbor Discovery (SEND)", RFC 3971,
March 2005.
[SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and
Multihoming Extensions for IKEv2 (SMOBIKE)", Multihoming Extensions for IKEv2 (SMOBIKE)",
draft-eronen-mobike-simple-00 (work in progress), Work in Progress, March 2004.
March 2004.
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R.
"STUN - Simple Traversal of User Datagram Protocol (UDP) Mahy, "STUN - Simple Traversal of User Datagram
Through Network Address Translators (NATs)", RFC 3489, Protocol (UDP) Through Network Address Translators
March 2003. (NATs)", RFC 3489, March 2003.
[UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- [UNSAF] Daigle, L., "IAB Considerations for UNilateral
Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
Appendix A. Implementation Considerations Appendix A. Implementation Considerations
A.1. Links from SPD Cache to Outbound SAD Entries A.1. Links from SPD Cache to Outbound SAD Entries
[IPsecArch] Section 4.4.2 says that "For outbound processing, each [IPsecArch], Section 4.4.2, says that "For outbound processing, each
SAD entry is pointed to by entries in the SPD-S part of the SPD SAD entry is pointed to by entries in the SPD-S part of the SPD
cache". The document does not specify how exactly this "pointing" is cache". The document does not specify how exactly this "pointing" is
done, since this is an implementation detail that does not have to be done, since this is an implementation detail that does not have to be
standardized. standardized.
However, it is clear that the links between the SPD cache and the SAD However, it is clear that the links between the SPD cache and the SAD
have to be done correctly to ensure that outbound packets are sent have to be done correctly to ensure that outbound packets are sent
over the right SA. Some implementations are known to have problems over the right SA. Some implementations are known to have problems
in this area. in this area.
In particular, simply storing the (remote tunnel header IP address, In particular, simply storing the (remote tunnel header IP address,
remote SPI) pair in the SPD cache is not sufficient, since the pair remote SPI) pair in the SPD cache is not sufficient, since the pair
does not always uniquely identify a single SAD entry. For instance, does not always uniquely identify a single SAD entry. For instance,
two hosts behind the same NAT can accidentally happen to choose the two hosts behind the same NAT can accidentally happen to choose the
same SPI value. The situation can also occur when a host is assigned same SPI value. The situation can also occur when a host is assigned
an IP address previously used by some other host, and the SAs an IP address previously used by some other host, and the SAs
associated with the old host have not yet been deleted by dead peer associated with the old host have not yet been deleted by Dead Peer
detection. This may lead to packets being sent over the wrong SA or, Detection. This may lead to packets being sent over the wrong SA or,
if the key management daemon ensures the pair is unique, denying the if the key management daemon ensures the pair is unique, denying the
creation of otherwise valid SAs. creation of otherwise valid SAs.
Storing the remote tunnel header IP address in the SPD cache may also Storing the remote tunnel header IP address in the SPD cache may also
complicate the implementation of MOBIKE, since the address can change complicate the implementation of MOBIKE, since the address can change
during the lifetime of the SA. Thus, we recommend implementing the during the lifetime of the SA. Thus, we recommend implementing the
links between the SPD cache and the SAD in a way that does not links between the SPD cache and the SAD in a way that does not
require modification when the tunnel header IP address is updated by require modification when the tunnel header IP address is updated by
MOBIKE. MOBIKE.
A.2. Creating Outbound SAs A.2. Creating Outbound SAs
When an outbound packet requires IPsec processing but no suitable SA When an outbound packet requires IPsec processing but no suitable SA
exists, a new SA will be created. In this case, the host has to exists, a new SA will be created. In this case, the host has to
determine (1) who is the right peer for this SA, (2) whether the host determine (1) who is the right peer for this SA, (2) whether the host
already has an IKE_SA with this peer, and (3) if no IKE_SA exists, already has an IKE_SA with this peer, and (3) if no IKE_SA exists,
the IP address(es) of the peer for contacting it. the IP address(es) of the peer for contacting it.
Neither [IPsecArch] nor MOBIKE specifies how exactly these three Neither [IPsecArch] nor MOBIKE specifies how exactly these three
steps are carried out. [IPsecArch] Section 4.4.3.4 says: steps are carried out. [IPsecArch], Section 4.4.3.4, says:
For example, assume that IKE A receives an outbound packet For example, assume that IKE A receives an outbound packet
destined for IP address X, a host served by a security gateway. destined for IP address X, a host served by a security gateway.
RFC 2401 [RFC2401] and this document do not specify how A RFC 2401 [RFC2401] and this document do not specify how A
determines the address of the IKE peer serving X. However, any determines the address of the IKE peer serving X. However, any
peer contacted by A as the presumed representative for X must be peer contacted by A as the presumed representative for X must be
registered in the PAD in order to allow the IKE exchange to be registered in the PAD in order to allow the IKE exchange to be
authenticated. Moreover, when the authenticated peer asserts that authenticated. Moreover, when the authenticated peer asserts that
it represents X in its traffic selector exchange, the PAD will be it represents X in its traffic selector exchange, the PAD will be
consulted to determine if the peer in question is authorized to consulted to determine if the peer in question is authorized to
skipping to change at page 33, line 38 skipping to change at page 32, line 34
steps are implemented, it is important to remember that IP addresses steps are implemented, it is important to remember that IP addresses
can change, and that an IP address alone does not always uniquely can change, and that an IP address alone does not always uniquely
identify a single IKE peer (for the same reasons as why the identify a single IKE peer (for the same reasons as why the
combination of the remote IP address and SPI does not uniquely combination of the remote IP address and SPI does not uniquely
identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1
and 2 it may be easier to identify the "right peer" using its and 2 it may be easier to identify the "right peer" using its
authenticated identity instead of its current IP address. However, authenticated identity instead of its current IP address. However,
these implementation details are beyond the scope of this these implementation details are beyond the scope of this
specification. specification.
Appendix B. Changelog
(This section should be removed by the RFC editor.)
Changes from -07 to -08:
o Clarified meaning of ADDITIONAL_*_ADDRESS and other notations.
o Clarified number of retries and UNEXPECTED_NAT_DETECTED.
o Added text about traffic selector authorization to security
considerations.
o Updated quotations to match RFC 4301.
o Updated acknowledgements and references.
o Small editorial fixes for IESG evaluation and IETF last call.
Changes from -06 to -07:
o Editorial fixes from AD evaluation.
Changes from -06.a to -06:
o Clarified text about certificates and omitting RR (issue 54).
o Take initial addresses from IKE_AUTH even when not doing NAT-T
(issue 60).
o Added text about dead peer detection (issue 71).
o Fixed port numbers in examples (issue 73).
o Updated acknowledgements list and references.
Changes from -05 to -06.a:
o Clarified third-party DoS security considerations (issue 45).
o Clarified the use of ADDITIONAL_*_ADDRESS/NO_ADDITIONAL_ADDRESSES
notifications and deleting addresses (issues 46 and 58).
o Better separation of error and status types (issue 59).
o Changed order of fields in NO_NATS_ALLOWED and provided a bit
diagram (issue 59).
o Added implementation considerations appendix (issues 51 and 70).
o Editorial fixes and clarifications (issues 54, 56, 59, 64, 72).
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:
o Copy-editing done by the RFC editor.
Changes from -02 to -03:
o Editorial fixes and clarifications (issues 42 and 43).
o Clarified IANA considerations (issue 42).
o Added security considerations about address and topology
disclosure (issue 42).
o Added a suggestion about retransmission timeout (issue 42).
o Change dynamic address updates: MUST NOT do them based on IKEv2
packets, MAY do based on ESP (issue 34).
o Mandate NAT prohibition if not doing NAT traversal (issue 41).
o Clarified security considerations related to NATs (issue 41).
o Don't use SHA-1 in NO_NATS_ALLOWED, just send the addresses (issue
42).
o Added a short section about path testing.
o Added an example protocol run in Section 1.
Changes from -01 to -02:
o Moved MOBIKE_SUPPORTED from IKE_SA_INIT to IKE_AUTH (issues 35,
37).
o Changed terminology related to NAT prohibition (issues 22, 24).
o Rewrote much of the ADDITIONAL_*_ADDRESS text, added
NO_ADDITIONAL_ADDRESSES notification.
o Use NAT detection payloads to detect changes in NAT mappings
(issue 34).
o Removed separate PATH_TEST message (issue 34).
o Clarified processing of UNACCEPTABLE_ADDRESSES when request has
been sent using several different addresses (issue 36).
o Clarified changing of ports 500/4500 (issue 33).
o Updated security considerations (issues 27 and 28).
o No need to include COOKIE2 in non-RR messages (issue 32).
o Many editorial fixes and clarifications (issue 38, 40).
o Use the terms initiator and responder more consistently.
o Clarified that this document does not solve all problems in MOBIKE
WG charter (issue 40).
Changes from -00 to -01:
o Editorial fixes and small clarifications (issues 21, 25, 26, 29).
o Use Protocol ID zero for notifications (issue 30).
o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue
23).
o Use the word "path" only in senses that include the route taken
(issue 29).
Author's Address Author's Address
Pasi Eronen (editor) Pasi Eronen (editor)
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Email: pasi.eronen@nokia.com EMail: pasi.eronen@nokia.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 38, line 29 skipping to change at page 33, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 83 change blocks. 
410 lines changed or deleted 237 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/