draft-ietf-mobike-protocol-05.txt   draft-ietf-mobike-protocol-06.txt 
MOBIKE Working Group P. Eronen, Ed. MOBIKE Working Group P. Eronen, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Expires: April 27, 2006 October 24, 2005 Expires: May 20, 2006 November 16, 2005
IKEv2 Mobility and Multihoming Protocol (MOBIKE) IKEv2 Mobility and Multihoming Protocol (MOBIKE)
draft-ietf-mobike-protocol-05.txt draft-ietf-mobike-protocol-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2006. This Internet-Draft will expire on May 20, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes the MOBIKE protocol, a mobility and This document describes the MOBIKE protocol, a mobility and
multihoming extension to Internet Key Exchange (IKEv2). MOBIKE multihoming extension to Internet Key Exchange (IKEv2). MOBIKE
allows hosts to update the (outer) IP addresses associated with IKEv2 allows hosts to update the (outer) IP addresses associated with IKEv2
and tunnel mode IPsec Security Associations. A mobile VPN client and tunnel mode IPsec Security Associations. A mobile VPN client
could use MOBIKE to keep the connection with the VPN gateway active could use MOBIKE to keep the connection with the VPN gateway active
while moving from one address to another. Similarly, a multihomed while moving from one address to another. Similarly, a multihomed
host could use MOBIKE to move the traffic to a different interface host could use MOBIKE to move the traffic to a different interface
if, for instance, the one currently being used stops working. if, for instance, the one currently being used stops working.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4 1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 5
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5 2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6
2.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 6 2.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 7
2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9 2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 10
3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10 3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10 3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 11
3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10 3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 11
3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 10 3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 11
3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11 3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 12
3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12 3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 13
3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15 3.6. Updating Additional Addresses . . . . . . . . . . . . . . 16
3.7. Return Routability Check . . . . . . . . . . . . . . . . . 16 3.7. Return Routability Check . . . . . . . . . . . . . . . . . 17
3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 17 3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 18 3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19
3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 19 3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 19 3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 20
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 20 3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 20
4.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 20 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 20 4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 21
4.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 20 4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . 21
4.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 20 4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . 21
4.5. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 21 4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 21
4.6. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 21 4.2.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . 21
4.7. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 21 4.2.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . 21
4.8. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 21 4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 4.2.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . 22
5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 23 4.2.5. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . 22
5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 23 4.2.6. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . 22
5.3. Denial-of-Service Attacks Against Third Parties . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5.4. Spoofing Network Connectivity Indications . . . . . . . . 25 5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 24
5.5. Address and Topology Disclosure . . . . . . . . . . . . . 25 5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 5.3. Denial-of-Service Attacks Against Third Parties . . . . . 25
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 5.4. Spoofing Network Connectivity Indications . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.5. Address and Topology Disclosure . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . . 28 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Implementation Considerations . . . . . . . . . . . . 30
A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 30
A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 31
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36
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, the IPsec and IKE SAs are created implicitly the base IKEv2 protocol, the IPsec and IKE SAs are created implicitly
between the IP addresses that are used when the IKE_SA is between the IP addresses that are used when the IKE_SA is
established. These IP addresses are then used as the outer (tunnel established. These IP addresses are then used as the outer (tunnel
skipping to change at page 4, line 24 skipping to change at page 5, line 24
for situations where the address of at least one endpoint is for situations where the address of at least one endpoint is
relatively stable, and can be discovered using existing mechanisms relatively stable, and can be discovered using existing mechanisms
such as DNS (see Section 3.1). such as DNS (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 unidirectional paths. implies that MOBIKE does not work over address pairs that provide
only unidirectional connectivity.
NATs introduce additional limitations beyond those listed above. For NATs introduce additional limitations beyond those listed above. For
details, refer to Section 2.3. 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.
Readers are encouraged to consult the MOBIKE design document [Design] Readers are encouraged to consult the MOBIKE design document [Design]
skipping to change at page 7, line 15 skipping to change at page 8, line 15
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_*_IP) --> N(NAT_DETECTION_*_IP) -->
<-- (IP_R1:500 -> IP_I1:500) <-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr, HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_*_IP) N(NAT_DETECTION_*_IP)
2) (IP_I1:500 -> IP_R1:500) 2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH, HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST), CP(CFG_REQUEST),
SAi2, TSi, TSr, SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } --> N(MOBIKE_SUPPORTED) } -->
<-- (IP_R1:500 -> IP_I1:500) <-- (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) }
(Initiator gets information from lower layers that its attachment (Initiator gets information from lower layers that its attachment
point and address have changed.) point and address have changed.)
3) (IP_I2:500 -> IP_R1:500) 3) (IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES), HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_*_IP) } --> N(NAT_DETECTION_*_IP) } -->
<-- (IP_R1:500 -> IP_I2:500) <-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(NAT_DETECTION_*_IP) } HDR, SK { N(NAT_DETECTION_*_IP) }
(Responder verifies that the initiator has given it (Responder verifies that the initiator has given it
a correct IP address.) a correct IP address.)
4) <-- (IP_R1:500 -> IP_I2:500) 4) <-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(COOKIE2) } HDR, SK { N(COOKIE2) }
(IP_I2:500 -> IP_R1:500) (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
skipping to change at page 8, line 24 skipping to change at page 9, line 24
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_*_IP) --> N(NAT_DETECTION_*_IP) -->
<-- (IP_R1:500 -> IP_I1:500) <-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr, HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_*_IP) N(NAT_DETECTION_*_IP)
2) (IP_I1:500 -> IP_R1:500) 2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH, HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST), CP(CFG_REQUEST),
SAi2, TSi, TSr, SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } --> N(MOBIKE_SUPPORTED) } -->
<-- (IP_R1:500 -> IP_I1:500) <-- (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_IPV4_ADDRESS) } N(ADDITIONAL_IPV4_ADDRESS) }
(The initiator suspects a problem in the currently used address pair, (The initiator suspects a problem in the currently used address pair,
and probes its liveness.) and probes its liveness.)
3) (IP_I1:500 -> IP_R1:500) 3) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_*_IP) } --> HDR, SK { N(NAT_DETECTION_*_IP) } -->
(IP_I1:500 -> IP_R1:500) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_*_IP) } --> HDR, SK { N(NAT_DETECTION_*_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:500 -> IP_R2:500) 4) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(NAT_DETECTION_*_IP) } HDR, SK { N(NAT_DETECTION_*_IP) }
<-- (IP_R2:500 -> IP_I1:500) <-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_*_IP) } HDR, SK { N(NAT_DETECTION_*_IP) }
(This worked, and the initiator requests the peer to switch to new (This worked, and the initiator requests the peer to switch to new
addresses.) addresses.)
5) (IP_I1:500 -> IP_R2:500) 5) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES), HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_*_IP), N(NAT_DETECTION_*_IP),
N(COOKIE2) } --> N(COOKIE2) } -->
<-- (IP_R2:500 -> IP_I1:500) <-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_*_IP), HDR, SK { N(NAT_DETECTION_*_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 talks simply
about NATs). The NAT Traversal feature specified in [IKEv2] allows about NATs). The NAT Traversal feature specified in [IKEv2] allows
IKEv2 to work through NATs in many cases, and MOBIKE can leverage IKEv2 to work through NATs in many cases, and MOBIKE can leverage
this functionality: when the addresses used for IPsec SAs are this functionality: when the addresses used for IPsec SAs are
skipping to change at page 10, line 42 skipping to change at page 11, line 42
payload). payload).
The format of the MOBIKE_SUPPORTED notification is described in The format of the MOBIKE_SUPPORTED notification is described in
Section 4. Section 4.
3.3. Initial Tunnel Header Addresses 3.3. Initial Tunnel Header Addresses
When an IPsec SA is created, the tunnel header IP addresses (and When an IPsec SA is created, the tunnel header IP addresses (and
port, if doing UDP encapsulation) are taken from the IKE_SA, not the port, if doing UDP encapsulation) are taken from the IKE_SA, not the
IP header of the IKEv2 message requesting the IPsec SA. The IP header of the IKEv2 message requesting the IPsec SA. The
addresses in the IKE_SA are initialized as follows: If the addresses in the IKE_SA are initialized from the IP header of the
IKE_SA_INIT request contains the NAT_DETECTION_*_IP notifications and first IKE_AUTH request.
the responder supports NAT Traversal, the values are initialized from
the IP header of the first IKE_AUTH request. Otherwise, the values
are initialized from the IP header of the IKE_SA_INIT request.
The addresses are taken from the IKE_AUTH request when NAT Traversal The addresses are taken from the IKE_AUTH request because IKEv2
is being used because IKEv2 requires changing from port 500 to 4500 requires changing from port 500 to 4500 if a NAT is discovered. To
if a NAT is discovered. To simplify things, implementations that simplify things, implementations that support both this specification
support both this specification and NAT Traversal MUST change to port and NAT Traversal MUST change to port 4500 if the correspondent also
4500 if the correspondent also supports both, even if no NAT was supports both, even if no NAT was detected between them (this way,
detected between them (this way, there is no need to change the ports there is no need to change the ports later if a a NAT is detected on
later). 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). message containing the SA payload).
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
skipping to change at page 14, line 44 skipping to change at page 15, line 44
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. it processes the response as described in Section 3.9.
o If the response contains an UNACCEPTABLE_ADDRESSES notification, o If the response contains an UNACCEPTABLE_ADDRESSES notification,
the initiator MAY select another addresses and retry the exchange, the initiator MAY select another addresses and retry the exchange,
keep on using the current addresses, or disconnect. keep on using the 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 before sending the addresses (unless this was already done earlier before sending the
request). request; this is the case when no return routability check was
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, it enables or disables NAT Traversal.
There is one exception to the rule that the responder never updates There is one exception to the rule that the responder never updates
any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If
the source address that the responder is currently using becomes the source address that the responder is currently using becomes
unavailable (i.e., sending packets using that source address is no unavailable (i.e., sending packets using that source address is no
longer possible), the responder is allowed to update the IPsec SAs to longer possible), the responder is allowed to update the IPsec SAs to
use some other address (in addition to initiating the procedure use some other address (in addition to initiating the procedure
described in the next section). described in the next section).
3.6. Updating Additional Addresses 3.6. Updating Additional Addresses
As described in Section 3.4, both the initiator and responder can As described in Section 3.4, both the initiator and responder can
send a list of additional addresses in the IKE_AUTH exchange. This send a list of additional addresses in the IKE_AUTH exchange. This
information can be updated by sending an INFORMATIONAL exchange information can be updated by sending an INFORMATIONAL exchange
request message that contains either one or more ADDITIONAL_IP4/ request message that contains either one or more ADDITIONAL_IP4/
6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. 6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification.
If the exchange initiator has only a single IP address, it is placed
in the IP header, and the message contains the
NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has
several addresses, one of them is placed in the IP header, and the
rest in ADDITIONAL_IP4/6_ADDRESS notifications. The new list of
addresses replaces the old information (in other words, there are no
separate add/delete operations; instead, the complete list is sent
every time these notifications are used).
The message exchange will look as follows: The message exchange will look as follows:
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SK { [N(ADDITIONAL_*_ADDRESS)+], HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
[N(NO_ADDITIONAL_ADDRESSES)], [N(NO_ADDITIONAL_ADDRESSES)],
[N(NO_NATS_ALLOWED)], [N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } --> [N(COOKIE2)] } -->
<-- HDR, SK { [N(COOKIE2)] } <-- HDR, SK { [N(COOKIE2)] }
When a request containing ADDITIONAL_*_ADDRESS or When a request containing ADDITIONAL_IP4/6_ADDRESS or
NO_ADDITIONAL_ADDRESSES notification is received, the exchange NO_ADDITIONAL_ADDRESSES notification is received, the exchange
responder: responder:
o Determines whether it has already received a newer request to o Determines whether it has already received a newer request to
update the addresses (if a window size greater than one is used, update the addresses (if a window size greater than one is used,
it is possible that the requests are received out of order). If it is possible that the requests are received out of order). If
it has, a response message is sent, but the address set is not it has, a response message is sent, but the address set is not
updated. updated.
o If the NO_NATS_ALLOWED notification is present, processes it as o If the NO_NATS_ALLOWED notification is present, processes it as
skipping to change at page 16, line 32 skipping to change at page 17, line 42
additional addresses to the responder (since the responder does not additional addresses to the responder (since the responder does not
need them except when changing its own address). need them except when changing its own 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
routability check" SHOULD be performed. In environments where the routability check" SHOULD be performed. In environments where the
peer is expected to be well-behaved (many corporate VPNs, for peer is expected to be well-behaved (many corporate VPNs, for
instance), or the address can be verified by some other means (e.g., instance), or the address can be verified by some other means (e.g.,
the address is included in the peer's certificate), the return a certificate issued by an authority trusted for this purpose), the
routability check MAY be omitted. return routability check MAY be omitted.
The check can be done before updating the IPsec SAs, immediately The check can be done before updating the IPsec SAs, immediately
after updating them, or continuously during the connection. By after updating them, or continuously during the connection. By
default, the return routability check SHOULD be done before updating default, the return routability check SHOULD be done before updating
the IPsec SAs, but in some environments it MAY be postponed until the IPsec SAs, but in some environments it MAY be postponed until
after the IPsec SAs have been updated. after the IPsec SAs have been updated.
Any INFORMATIONAL exchange can be used for return routability Any INFORMATIONAL exchange can be used for return routability
purposes, with one exception (described later in this section): when purposes, with one exception (described later in this section): when
a valid response is received, we know the other party can receive a valid response is received, we know the other party can receive
packets at the claimed address. packets at the claimed address.
To ensure that the peer cannot generate the correct INFORMATIONAL To ensure that the peer cannot generate the correct INFORMATIONAL
response without seeing the request, a new payload is added to response without seeing the request, a new payload is added to
INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY
include a COOKIE2 notification, and if included, the recipient of an include a COOKIE2 notification, and if included, the recipient of an
INFORMATIONAL request MUST copy the notification as-is to the INFORMATIONAL request MUST copy the notification as-is to the
response. When processing the response, the original sender MUST response. When processing the response, the original sender MUST
verify that the value is the same one as sent. If the values do not verify that the value is the same one as sent. If the values do not
match, the IKE_SA MUST be closed. (See also Section 4.6 for the match, the IKE_SA MUST be closed. (See also Section 4.2.5 for the
format of the COOKIE2 notification.) format of the COOKIE2 notification.)
The exception mentioned earlier is as follows: If the same The exception mentioned earlier is as follows: If the same
INFORMATIONAL request has been sent to several different addresses INFORMATIONAL request has been sent to several different addresses
(i.e., the destination address in the IKE_SA has been updated after (i.e., the destination address in the IKE_SA has been updated after
the request was first sent), receiving the INFORMATIONAL response the request was first sent), receiving the INFORMATIONAL response
does not tell which address is the working one. In this case, a new does not tell which address is the working one. In this case, a new
INFORMATIONAL request needs to be sent to check return routability. INFORMATIONAL request needs to be sent to check return routability.
3.8. Changes in NAT Mappings 3.8. Changes in NAT Mappings
skipping to change at page 18, line 27 skipping to change at page 19, line 36
when NAT Traversal has not been explicitly enabled. This means that when NAT Traversal has not been explicitly enabled. This means that
MOBIKE without NAT Traversal support will not work if the paths MOBIKE without NAT Traversal support will not work if the paths
contain NATs, IPv4/IPv6 translation agents, or other nodes that contain NATs, IPv4/IPv6 translation agents, or other nodes that
modify the addresses in the IP header. This feature is mainly modify the addresses in the IP header. This feature is mainly
intended for IPv6 and site-to-site VPN cases, where the intended for IPv6 and site-to-site VPN cases, where the
administrators may know beforehand that NATs are not present, and administrators may know beforehand that NATs are not present, and
thus any modification to the packet can be considered an attack. thus any modification to the packet can be considered an attack.
More specifically, when NAT Traversal is not enabled, all messages More specifically, when NAT Traversal is not enabled, all messages
that can update the addresses associated with the IKE_SA and/or IPsec that can update the addresses associated with the IKE_SA and/or IPsec
SAs (the IKE_SA_INIT request and all INFORMATIONAL requests that SAs (the first IKE_AUTH request and all INFORMATIONAL requests that
contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS contain any of the following notifications: UPDATE_SA_ADDRESSES,
notifications) MUST also include a NO_NATS_ALLOWED notification. The ADDITIONAL_IP4/6_ADDRESS, NO_ADDITIONAL_ADDRESSES) MUST also include
exchange responder MUST verify that the contents of the a NO_NATS_ALLOWED notification. The exchange responder MUST verify
NO_NATS_ALLOWED notification match the addresses in the IP header. that the contents of the NO_NATS_ALLOWED notification match the
If they do not match, a response containing an addresses in the IP header. If they do not match, a response
UNEXPECTED_NAT_DETECTED notification is sent (and in the case of the containing an UNEXPECTED_NAT_DETECTED notification is sent. The
IKE_SA_INIT exchange, no state is created at the responder). The
response message is sent to the address and port that the response message is sent to the address and port that the
corresponding request came from, not to the address contained in the corresponding request came from, not to the address contained in the
NO_NATS_ALLOWED notification. NO_NATS_ALLOWED notification.
If the exchange initiator receives an UNEXPECTED_NAT_DETECTED If the exchange initiator receives an UNEXPECTED_NAT_DETECTED
notification in response to its request, it SHOULD retry the notification in response to its INFORMATIONAL request, it SHOULD
operation several times using new IKE_SA_INIT/INFORMATIONAL requests. retry the operation several times using new INFORMATIONAL requests.
This ensures that an attacker who is able to modify only a single Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the
packet does not unnecessarily cause a path to remain unused. IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several
times, starting from a new IKE_SA_INIT request. This ensures that an
attacker who is able to modify only a single packet does not
unnecessarily cause a path to remain unused.
If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange
responder MUST NOT use the contents of the NO_NATS_ALLOWED responder MUST NOT use the contents of the NO_NATS_ALLOWED
notification for any other purpose than possibly logging the notification for any other purpose than possibly logging the
information for troubleshooting purposes. information for troubleshooting purposes.
3.10. Path Testing 3.10. Path Testing
IKEv2 Dead Peer Detection allows the peers to detect if the currently IKEv2 Dead Peer Detection allows the peers to detect if the currently
used path has stopped working. However, if either of the peers has used path has stopped working. However, if either of the peers has
skipping to change at page 20, line 5 skipping to change at page 20, line 38
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
MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but
as addresses may change, it is not sufficient to just verify that the
peer is alive, but also that it is synchronized with the address
updates and has not, for instance, ignored an address update due to
failure to complete return routability test. This means that when
there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the
addresses used in those packets and determine that they correspond to
those that should be employed. If they do not, such packets SHOULD
NOT be used as evidence that the peer is able to communicate with
this node and or that the peer has received all address updates.
4. Payload Formats 4. Payload Formats
This specification defines several new IKEv2 Notify payload types. This specification defines several new IKEv2 Notify payload types.
The UNACCEPTABLE_ADDRESSES and UNEXPECTED_NAT_DETECTED notifications See [IKEv2] Section 3.10 for a general description of the Notify
are "error types"; the other notifications are "status types". See payload.
[IKEv2] Section 3.10 for a general description of the Notify payload.
4.1. MOBIKE_SUPPORTED Notify Payload 4.1. Notify Messages - Error Types
4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload
The responder can include this notification in an INFORMATIONAL
exchange response to indicate that the address change in the
corresponding request message (which contained an UPDATE_SA_ADDRESSES
notification) was not carried out.
The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA6.
The Protocol ID and SPI Size fields are set to zero. There is no
data associated with this Notify type.
4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload
See Section 3.9 for a description of this notification.
The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9.
The Protocol ID and SPI Size fields are set to zero. There is no
data associated with this Notify type.
4.2. Notify Messages - Status Types
4.2.1. MOBIKE_SUPPORTED Notify Payload
The MOBIKE_SUPPORTED notification is included in the IKE_AUTH The MOBIKE_SUPPORTED notification is included in the IKE_AUTH
exchange to indicate that the implementation supports this exchange to indicate that the implementation supports this
specification. specification.
The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The
Protocol ID and SPI Size fields are set to zero. The notification Protocol ID and SPI Size fields are set to zero. The notification
data field MUST be left empty (zero-length) when sending, and its data field MUST be left empty (zero-length) when sending, and its
contents (if any) MUST be ignored when this notification is received. contents (if any) MUST be ignored when this notification is received.
This allows the field to be used by future versions of this protocol. This allows the field to be used by future versions of this protocol.
4.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads 4.2.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads
Both parties can include ADDITIONAL_IP4_ADDRESS and/or Both parties can include ADDITIONAL_IP4_ADDRESS and/or
ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and
INFORMATIONAL exchange request messages; see Section 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 TBD-BY-IANA2 and TBD-BY-IANA3,
respectively. The Protocol ID and SPI Size fields are set to zero. respectively. The Protocol ID and SPI Size fields are set to zero.
The data associated with these Notify types is either a four-octet The data associated with these Notify types is either a four-octet
IPv4 address or a 16-octet IPv6 address. IPv4 address or a 16-octet IPv6 address.
4.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 TBD-BY-IANA4.
The Protocol ID and SPI Size fields are set to zero. There is no The Protocol ID and SPI Size fields are set to zero. There is no
data associated with this Notify type. data associated with this Notify type.
4.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 TBD-BY-IANA5. The
Protocol ID and SPI Size fields are set to zero. There is no data Protocol ID and SPI Size fields are set to zero. There is no data
associated with this Notify type. associated with this Notify type.
4.5. UNACCEPTABLE_ADDRESSES Notify Payload 4.2.5. COOKIE2 Notify Payload
The responder can include this notification in an INFORMATIONAL
exchange response to indicate that the address change in the
corresponding request message (which contained an UPDATE_SA_ADDRESSES
notification) was not carried out.
The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA6.
The Protocol ID and SPI Size fields are set to zero. There is no
data associated with this Notify type.
4.6. COOKIE2 Notify Payload
This notification MAY be included in any INFORMATIONAL request for This notification MAY be included in any INFORMATIONAL request for
return routability check purposes (see Section 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 TBD-BY-IANA7. The
Protocol ID and SPI Size fields are set to zero. Protocol ID and SPI Size fields are set to zero.
4.7. 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 data field of this notification contains the following The Notify Message Type for this message is TBD-BY-IANA8. The
information: the IP address from which the packet was sent (4 or 16 notification data contains the IP addresses and ports from/to which
bytes), the port from which the packet was sent (2 bytes, network the packet was sent. For IPv4, the notification data is 12 octets
byte order), the IP addresss to which the packet was sent (4 or 16 long and is defined as follows:
bytes), and the port to which the packet was sent (2 bytes, network
byte order). The total length of the data field is thus 12 bytes for
IPv4 and 36 bytes for IPv6. The Notify Message Type for this message
is TBD-BY-IANA8. The Protocol ID and SPI Size fields are set to
zero.
4.8. UNEXPECTED_NAT_DETECTED Notify Payload 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Destination IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See Section 3.9 for a description of this notification. For IPv6, the notification data is 36 octets long and is defined as
follows:
The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9. 1 2 3
The Protocol ID and SPI Size fields are set to zero. There is no 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
data associated with this Notify type. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Source IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Destination IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol ID and SPI Size fields are set to zero.
5. Security Considerations 5. Security Considerations
The main goals of this specification are to maintain the security The main goals of this specification are to maintain the security
offered by usual IKEv2 procedures and to counter mobility-related offered by usual IKEv2 procedures and to counter mobility-related
threats in an appropriate manner. This section describes new threats in an appropriate manner. This section describes new
security considerations introduced by MOBIKE. See [IKEv2] for security considerations introduced by MOBIKE. See [IKEv2] for
security considerations for IKEv2 in general. security considerations for IKEv2 in general.
5.1. Traffic Redirection and Hijacking 5.1. Traffic Redirection and Hijacking
skipping to change at page 23, line 40 skipping to change at page 24, line 40
of these packets, the attackers can lead the peers to believe a new of these packets, the attackers can lead the peers to believe a new
NAT or a changed NAT binding exists between them. The attack can NAT or a changed NAT binding exists between them. The attack can
continue as long as the attacker is on the path, modifying the IKEv2 continue as long as the attacker is on the path, modifying the IKEv2
messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms
designed to detect NAT mapping changes will eventually recognize that designed to detect NAT mapping changes will eventually recognize that
the intended traffic is not getting through, and will update the the intended traffic is not getting through, and will update the
addresses appropriately. addresses appropriately.
MOBIKE introduces the NO_NATS_ALLOWED notification that is used to MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
detect modification, by outsiders, of the addresses in the IP header. detect modification, by outsiders, of the addresses in the IP header.
Such modifications can only be performed by attackers who are on the When this notification is used, communication through NATs and other
path and capable of modifying the When this notification is used, address translators is impossible, so it is sent only when not doing
communication through NATs and other address translators is NAT Traversal. This feature is mainly intended for IPv6 and site-to-
impossible, so it is sent only when not doing NAT Traversal. site VPN cases, where the administrators may know beforehand that
NATs are not present.
5.2. IPsec Payload Protection 5.2. IPsec Payload Protection
The use of IPsec protection on payload traffic protects the The use of IPsec protection on payload traffic protects the
participants against disclosure of the contents of the traffic, participants against disclosure of the contents of the traffic,
should the traffic end up in an incorrect destination or be should the traffic end up in an incorrect destination or be
eavesdropped along the way. eavesdropped along the way.
However, security associations originally created for the protection However, security associations originally created for the protection
of a specific flow between specific addresses may be updated by of a specific flow between specific addresses may be updated by
skipping to change at page 24, line 30 skipping to change at page 25, line 32
multimedia stream may be redirected towards a victim host, causing multimedia stream may be redirected towards a victim host, causing
its communications capabilities to suffer. its communications capabilities to suffer.
The attackers in this threat can be either outsiders or even one of The attackers in this threat can be either outsiders or even one of
the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers
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.
Normally, such attacks would expire in a short time frame due to the If the attack is launched by an outsider, the traffic flow would
lack of responses (such as transport layer acknowledgements) from the normally stop soon due to the lack of responses (such as transport
victim. However, as described in [Aura02], malicious participants layer acknowledgements). However, if the original recipient of the
would typically be able to spoof such acknowledgements and maintain flow is malicious, it could maintain the traffic flow for an extended
the traffic flow for an extended period of time. For instance, if period of time, since it often would be able to send the required
the attacker opened the TCP stream itself before redirecting it to acknowledgements (see [Aura02] for more discussion).
the victim, the attacker becomes aware of the sequence number space
used in this particular session.
It should also be noted, as shown in [Bombing], that without ingress It should also be noted, as shown in [Bombing], that without ingress
filtering in the attacker's network, such attacks are already filtering in the attacker's network, such attacks are already
possible simply by sending spoofed packets from the attacker to the possible simply by sending spoofed packets from the attacker to the
victim directly. Furthermore, if the attacker's network has ingress victim directly. Furthermore, if the attacker's network has ingress
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
skipping to change at page 25, line 11 skipping to change at page 26, line 10
This specification includes return routability tests to limit the This specification includes return routability tests to limit the
duration of any "third party bombing" attacks by off-path (relative duration of any "third party bombing" attacks by off-path (relative
to the victim) attackers. The tests are authenticated messages that to the victim) attackers. The tests are authenticated messages that
the peer has to respond to, and can be performed either before the the peer has to respond to, and can be performed either before the
address change takes effect, immediately afterwards, or even address change takes effect, immediately afterwards, or even
periodically during the session. The tests contain unpredictable periodically during the session. The tests contain unpredictable
data, and only someone who has the keys associated with the IKE SA data, and only someone who has the keys associated with the IKE SA
and has seen the request packet can properly respond to the test. and has seen the request packet can properly respond to the test.
The duration of the attack can also be limited if the victim reports
the unwanted traffic to the originating IPsec tunnel endpoint using
ICMP error messages or INVALID_SPI notifications. As described in
[IKEv2] Section 2.21, this SHOULD trigger a liveness test, which also
doubles as a return routability check if the COOKIE2 notification is
included.
5.4. Spoofing Network Connectivity Indications 5.4. Spoofing Network Connectivity Indications
Attackers may spoof various indications from lower layers and the Attackers may spoof various indications from lower layers and the
network in an effort to confuse the peers about which addresses are network in an effort to confuse the peers about which addresses are
or are not working. For example, attackers may spoof link-layer or are not working. For example, attackers may spoof link-layer
error messages in an effort to cause the parties to move their error messages in an effort to cause the parties to move their
traffic elsewhere or even to disconnect. Attackers may also spoof traffic elsewhere or even to disconnect. Attackers may also spoof
information related to network attachments, router discovery, and information related to network attachments, router discovery, and
address assignments in an effort to make the parties believe they address assignments in an effort to make the parties believe they
have Internet connectivity when, in reality, they do not. have Internet connectivity when, in reality, they do not.
skipping to change at page 27, line 5 skipping to change at page 28, line 5
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. are to be allocated from the "IKEv2 Notify Message Types" namespace.
Notify Message Value Notify Messages - Error Types Value
--------------------------- ----- ----------------------------- -----
UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191)
UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191)
Notify Messages - Status Types Value
------------------------------ -----
MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959)
ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959)
ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959)
NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959)
UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959)
UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191)
COOKIE2 TBD-BY-IANA7 (16396..40959) COOKIE2 TBD-BY-IANA7 (16396..40959)
NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959)
UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191)
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, Francis Dupont, Paul would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo
Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also Bagnulo, Stephane Beaulieu, Lakshminath Dondeti, Francis Dupont, Paul
incorporates ideas and text from earlier MOBIKE protocol proposals, Hoffman, James Kempf, Tero Kivinen, Pete McCann, Mohan Parthasarathy,
including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the Pekka Savola, Bill Sommerfeld, Maureen Stillman, Shinta Sugimoto,
MOBIKE design document [Design]. Sami Vaarala, and Hannes Tschofenig. This document also incorporates
ideas and text from earlier MOBIKE protocol proposals, including
[AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design
document [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) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004. October 2004.
[IPsecArch] [IPsecArch]
Kent, S. and K. Seo, "Security Architecture for the Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
in progress), March 2005. in progress), March 2005.
[KEYWORDS] [KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[UDPEncap]
Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
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",
draft-dupont-ikev2-addrmgmt-07 (work in progress), draft-dupont-ikev2-addrmgmt-07 (work in progress),
May 2005. May 2005.
[Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
Location Management", Proc. 18th Annual Computer Security Location Management", Proc. 18th Annual Computer Security
Applications Conference (ACSAC), December 2002. Applications Conference (ACSAC), December 2002.
[Bombing] Dupont, F., "A note about 3rd party bombing in Mobile [Bombing] Dupont, F., "A note about 3rd party bombing in Mobile
IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), IPv6", draft-dupont-mipv6-3bombing-02 (work in progress),
June 2005. June 2005.
[DNA4] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", [DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
draft-ietf-dhc-dna-ipv4-15 (work in progress), Network Attachment (DNA) in IPv4",
August 2005. draft-ietf-dhc-dna-ipv4-17 (work in progress),
October 2005.
[DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting [DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting
Network Attachment in IPv6 - Best Current Practices for Network Attachment in IPv6 - Best Current Practices for
hosts", draft-ietf-dna-hosts-01 (work in progress), hosts", draft-ietf-dna-hosts-02 (work in progress),
June 2005. October 2005.
[Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE
protocol", draft-ietf-mobike-design-02 (work in progress), protocol", draft-ietf-mobike-design-04 (work in progress),
February 2005. October 2005.
[ICMPAttacks] [ICMPAttacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-gont-tcpm-icmp-attacks-03 (work in progress), draft-gont-tcpm-icmp-attacks-05 (work in progress),
December 2004. October 2005.
[Kivinen] Kivinen, T., "MOBIKE protocol", [Kivinen] Kivinen, T., "MOBIKE protocol",
draft-kivinen-mobike-protocol-00 (work in progress), draft-kivinen-mobike-protocol-00 (work in progress),
February 2004. February 2004.
[MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
skipping to change at page 29, line 24 skipping to change at page 30, line 26
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
Appendix A. Changelog Appendix A. Implementation Considerations
A.1. Links from SPD Cache to Outbound SAD Entries
[IPsecArch] Section 4.4.2 says that "For outbound processing, each
SAD entry is pointed to by entries in the SPD-S part of the SPD
cache". The document does not specify how exactly this "pointing" is
done, since this is an implementation detail that does not have to be
standardized.
However, it is clear that the links between the SPD cache and the SAD
have to be done correctly to ensure that outbound packets are sent
over the right SA. Some implementations are known to have problems
in this area.
In particular, simply storing the (remote tunnel header IP address,
remote SPI) pair in the SPD cache is not sufficient, since the pair
does not always uniquely identify a single SAD entry. For instance,
two hosts behind the same NAT can accidentally happen to choose the
same SPI value. The situation can also occur when a host is assigned
an IP address previously used by some other host, and the SAs
associated with the old host have not yet been deleted by dead peer
detection. This may lead to packets being sent over the wrong SA or,
if the key management daemon ensures the pair is unique, denying the
creation of otherwise valid SAs.
Storing the remote tunnel header IP address in the SPD cache may also
complicate the implementation of MOBIKE, since the address can change
during the lifetime of the SA. Thus, we recommend implementing the
links between the SPD cache and the SAD in a way that does not
require modification when the tunnel header IP address is updated by
MOBIKE.
A.2. Creating Outbound SAs
When an outbound packet requires IPsec processing but no suitable SA
exists, a new SA will be created. In this case, the host has to
determine (1) who is the right peer for this SA, (2) whether the host
already has an IKE_SA with this peer, and (3) if no IKE_SA exists,
the IP address(es) of the peer for contacting it.
Neither [IPsecArch] nor MOBIKE specifies how exactly these three
steps are carried out. [IPsecArch] Section 4.4.3.4 says:
For example, assume that IKE A receives an outbound packet
destined for IP address X, a host served by a security
gateway. RFC 2401 and 2401bis do not specify how A determines
the address of the IKE peer serving X. However, any peer
contacted by A as the presumed representative for X must be
registered in the PAD in order to allow the IKE exchange to be
authenticated. Moreover, when the authenticated peer asserts
that it represents X in its traffic selector exchange, the PAD
will be consulted to determine if the peer in question is
authorized to represent X.
In step 1, there may be more than one possible peer (e.g., several
security gateways that are allowed to represent X). In step 3, the
host may need to consult a directory such as DNS to determine the
peer IP address(es).
When performing these steps, implementations may use information
contained in the SPD, the PAD, and possibly some other
implementation-specific databases. Regardless of how exactly the
steps are implemented, it is important to remember that IP addresses
can change, and that an IP address alone does not always uniquely
identify a single IKE peer (for the same reasons as why the
combination of the remote IP address and SPI does not uniquely
identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1
and 2 it may be easier to identify the "right peer" using its
authenticated identity instead of its current IP address. However,
these implementation details are beyond the scope of this
specification.
Appendix B. Changelog
(This section should be removed by the RFC editor.) (This section should be removed by the RFC editor.)
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: Changes from -04 to -05:
o Editorial fixes and clarifications (issue 44, 47, 48, 49, 50, 53, o Editorial fixes and clarifications (issue 44, 47, 48, 49, 50, 53,
62, 66, 67, 68, 69). 62, 66, 67, 68, 69).
o Ignore data in MOBIKE_SUPPORTED (issue 61). o Ignore data in MOBIKE_SUPPORTED (issue 61).
Changes from -03 to -04: Changes from -03 to -04:
o Copy-editing done by the RFC editor. o Copy-editing done by the RFC editor.
 End of changes. 55 change blocks. 
162 lines changed or deleted 331 lines changed or added

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