draft-ietf-mobike-protocol-07.txt   draft-ietf-mobike-protocol-08.txt 
MOBIKE Working Group P. Eronen, Ed. MOBIKE Working Group P. Eronen, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Expires: June 23, 2006 December 20, 2005 Expires: August 26, 2006 February 22, 2006
IKEv2 Mobility and Multihoming Protocol (MOBIKE) IKEv2 Mobility and Multihoming Protocol (MOBIKE)
draft-ietf-mobike-protocol-07.txt draft-ietf-mobike-protocol-08.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 June 23, 2006. This Internet-Draft will expire on August 26, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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 VPN client could use
MOBIKE to keep the connection with the VPN gateway active while MOBIKE to keep the connection with the VPN gateway active while
moving from one address to another. Similarly, a multihomed host moving from one address to another. Similarly, a multihomed host
could use MOBIKE to move the traffic to a different interface if, for could use MOBIKE to move the traffic to a different interface if, for
instance, the one currently being used stops working. instance, the one currently being used stops working.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 5 1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 5
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6 2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6
2.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 7 2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 7
2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 10 2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 10
3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 11 3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 11 3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 11
3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 11 3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 11
3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 12 3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 12
3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 12 3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 12
3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 13 3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 13
3.6. Updating Additional Addresses . . . . . . . . . . . . . . 16 3.6. Updating Additional Addresses . . . . . . . . . . . . . . 16
3.7. Return Routability Check . . . . . . . . . . . . . . . . . 18 3.7. Return Routability Check . . . . . . . . . . . . . . . . . 18
3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18 3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
skipping to change at page 2, line 45 skipping to change at page 2, line 45
Notify Payloads . . . . . . . . . . . . . . . . . . . 22 Notify Payloads . . . . . . . . . . . . . . . . . . . 22
4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . 23 4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . 23
4.2.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . 23 4.2.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . 23
4.2.5. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . 23 4.2.5. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . 23
4.2.6. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . 23 4.2.6. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 25 5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 25
5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 25 5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 25
5.3. Denial-of-Service Attacks Against Third Parties . . . . . 26 5.3. Denial-of-Service Attacks Against Third Parties . . . . . 26
5.4. Spoofing Network Connectivity Indications . . . . . . . . 27 5.4. Spoofing Network Connectivity Indications . . . . . . . . 27
5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27 5.5. Address and Topology Disclosure . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Implementation Considerations . . . . . . . . . . . . 31 Appendix A. Implementation Considerations . . . . . . . . . . . . 32
A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31 A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 32
A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 32 A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 32
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 33 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 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, the IPsec and IKE SAs are created implicitly the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec
between the IP addresses that are used when the IKE_SA is SAs are created implicitly between the IP addresses that are used
established. These IP addresses are then used as the outer (tunnel when the IKE_SA is established. These IP addresses are then used as
header) addresses for tunnel mode IPsec packets. Currently, it is the outer (tunnel header) addresses for tunnel mode IPsec packets
not possible to change these addresses after the IKE_SA has been (transport mode IPsec SAs are beyond the scope of this document).
created. Currently, it is not possible to change these addresses after the
IKE_SA has been created.
There are scenarios where these IP addresses might change. One There are scenarios where these IP addresses might change. One
example is mobility: a host changes its point of network attachment, example is mobility: a host changes its point of network attachment
and receives a new IP address. Another example is a multihoming host and receives a new IP address. Another example is a multihoming host
that would like to change to a different interface if, for instance, that would like to change to a different interface if, for instance,
the currently used interface stops working for some reason. the currently used interface stops working for some reason.
Although the problem can be solved by creating new IKE and IPsec SAs Although the problem can be solved by creating new IKE and IPsec SAs
when the addresses need to be changed, this may not be optimal for when the addresses need to be changed, this may not be optimal for
several reasons. In some cases, creating a new IKE_SA may require several reasons. In some cases, creating a new IKE_SA may require
user interaction for authentication, such as entering a code from a user interaction for authentication, such as entering a code from a
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 leaving the office the
laptop could start using GPRS; when the user arrives home, the laptop laptop could start using GPRS; when the user arrives home, the laptop
could switch the the home wireless LAN. MOBIKE updates only the could switch to the home wireless LAN. MOBIKE updates only the outer
outer (tunnel header) addresses of IPsec SAs, and the addresses and (tunnel header) addresses of IPsec SAs, and the addresses and other
other traffic selectors used inside the tunnel stay unchanged. Thus, traffic selectors used inside the tunnel stay unchanged. Thus,
mobility can be (mostly) invisible to applications and their mobility can be (mostly) invisible to applications and their
connections using the VPN. connections using the VPN.
MOBIKE also supports more complex scenarios where the VPN gateway MOBIKE also supports more complex scenarios where the VPN gateway
also has several network interfaces: these interfaces could be also has several network interfaces: these interfaces could be
connected to different networks or ISPs, they may 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.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
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 Runs 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
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
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) -->
<-- (IP_R1:500 -> IP_I1:500) <-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr, HDR, SAr1, KEr, Nr,
skipping to change at page 12, line 27 skipping to change at page 12, line 27
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 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). message containing the SA payload). Here "ADDITIONAL_*_ADDRESS"
means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS
notification.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SK { IDi, [CERT], [IDr], AUTH, HDR, SK { IDi, [CERT], [IDr], AUTH,
[CP(CFG_REQUEST)] [CP(CFG_REQUEST)]
SAi2, TSi, TSr, SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED), N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_*_ADDRESS)+] } --> [N(ADDITIONAL_*_ADDRESS)+] } -->
<-- HDR, SK { IDr, [CERT], AUTH, <-- HDR, SK { IDr, [CERT], AUTH,
skipping to change at page 20, line 32 skipping to change at page 20, line 32
from, not to the address contained in the NO_NATS_ALLOWED from, not to the address contained in the NO_NATS_ALLOWED
notification. notification.
If the exchange initiator receives an UNEXPECTED_NAT_DETECTED If the exchange initiator receives an UNEXPECTED_NAT_DETECTED
notification in response to its INFORMATIONAL request, it SHOULD notification in response to its INFORMATIONAL request, it SHOULD
retry the operation several times using new INFORMATIONAL requests. retry the operation several times using new INFORMATIONAL requests.
Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the
IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several
times, starting from a new IKE_SA_INIT request. This ensures that an 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 attacker who is able to modify only a single packet does not
unnecessarily cause a path to remain unused. unnecessarily cause a path to remain unused. The exact number of
retries is not specified in this document because it does not affect
interoperability. However, because the IKE message will also be
rejected if the attacker modifies the integrity checksum field, a
reasonable number here would be the number of retries that is being
used for normal retransmissions.
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 25, line 50 skipping to change at page 25, line 50
When this notification is used, communication through NATs and other When this notification is used, communication through NATs and other
address translators is impossible, so it is sent only when not doing address translators is impossible, so it is sent only when not doing
NAT Traversal. This feature is mainly intended for IPv6 and site-to- NAT Traversal. This feature is mainly intended for IPv6 and site-to-
site VPN cases, where the administrators may know beforehand that site VPN cases, where the administrators may know beforehand that
NATs are not present. 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 subject
eavesdropped along the way. to eavesdropping.
However, security associations originally created for the protection However, security associations originally created for the protection
of a specific flow between specific addresses may be updated by of a specific flow between specific addresses may be updated by
MOBIKE later on. This has to be taken into account if the level of MOBIKE later on. This has to be taken into account if the (outer) IP
required protection depends on, for instance, the current location of address of the peer was used when deciding what kind of IPsec SAs the
the VPN client. peer is allowed to create.
For instance, the level of required protection might depend on the
current location of the VPN client, or access might be allowed only
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
(logical) Peer Authorization Database (PAD) contains the information
used by IKEv2 when determining what kind of IPsec SAs a peer is
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
traffic selectors, the PAD must contain "Child SA Authorization Data"
linking the identity authenticated by IKEv2 and the addresses
permitted for traffic selectors. See also [Clarifications] for a
more extensive discussion.
It is important to note that simply sending IKEv2 packets using some
particular address does not automatically imply a permission to
create IPsec SAs with that address in the traffic selectors.
However, some implementations are known to use policies where simply
being reachable at some address X implies a temporary permission to
create IPsec SAs for address X. Here "being reachable" usually means
the ability to send (or spoof) IP packets with source address X and
receive (or eavesdrop) packets sent to X.
Using this kind of policies or extensions with MOBIKE may need
special care to enforce the temporary nature of the permission. For
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
traffic selectors matching X. However, these interactions are beyond
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 for 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
skipping to change at page 29, line 29 skipping to change at page 30, line 9
UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959)
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)
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, Lakshminath Dondeti, Francis Dupont, Paul Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti,
Hoffman, James Kempf, Tero Kivinen, Pete McCann, Mohan Parthasarathy, Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann,
Pekka Savola, Bill Sommerfeld, Maureen Stillman, Shinta Sugimoto, Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld,
Sami Vaarala, and Hannes Tschofenig. This document also incorporates Maureen Stillman, Shinta Sugimoto, Sami Vaarala, and Hannes
ideas and text from earlier MOBIKE-like protocol proposals, including Tschofenig. This document also incorporates ideas and text from
[AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design earlier MOBIKE-like protocol proposals, including [AddrMgmt],
document [Design]. [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), RFC 4306, December 2005.
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", RFC 4301, December 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.
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-08 (work in progress),
May 2005. November 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-03 (work in progress),
June 2005. December 2005.
[Clarifications]
Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines",
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 (DNA) in IPv4",
draft-ietf-dhc-dna-ipv4-17 (work in progress), draft-ietf-dhc-dna-ipv4-18 (work in progress),
October 2005. December 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-02 (work in progress), hosts", draft-ietf-dna-hosts-02 (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 MOBIKE
protocol", draft-ietf-mobike-design-04 (work in progress), protocol", draft-ietf-mobike-design-07 (work in progress),
October 2005. January 2006.
[ICMPAttacks] [ICMPAttacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-gont-tcpm-icmp-attacks-05 (work in progress), draft-gont-tcpm-icmp-attacks-05 (work in progress),
October 2005. 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.
skipping to change at page 32, line 26 skipping to change at page 33, line 10
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 destined for IP address X, a host served by a security gateway.
gateway. RFC 2401 and 2401bis do not specify how A determines RFC 2401 [RFC2401] and this document do not specify how A
the address of the IKE peer serving X. However, any peer determines the address of the IKE peer serving X. However, any
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 authenticated. Moreover, when the authenticated peer asserts that
that it represents X in its traffic selector exchange, the PAD it represents X in its traffic selector exchange, the PAD will be
will be consulted to determine if the peer in question is consulted to determine if the peer in question is authorized to
authorized to represent X. represent X.
In step 1, there may be more than one possible peer (e.g., several 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 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 host may need to consult a directory such as DNS to determine the
peer IP address(es). peer IP address(es).
When performing these steps, implementations may use information When performing these steps, implementations may use information
contained in the SPD, the PAD, and possibly some other contained in the SPD, the PAD, and possibly some other
implementation-specific databases. Regardless of how exactly the implementation-specific databases. Regardless of how exactly the
steps are implemented, it is important to remember that IP addresses steps are implemented, it is important to remember that IP addresses
skipping to change at page 33, line 10 skipping to change at page 33, line 42
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 Appendix B. Changelog
(This section should be removed by the RFC editor.) (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: Changes from -06 to -07:
o Editorial fixes from AD evaluation. o Editorial fixes from AD evaluation.
Changes from -06.a to -06: Changes from -06.a to -06:
o Clarified text about certificates and omitting RR (issue 54). o Clarified text about certificates and omitting RR (issue 54).
o Take initial addresses from IKE_AUTH even when not doing NAT-T o Take initial addresses from IKE_AUTH even when not doing NAT-T
(issue 60). (issue 60).
skipping to change at page 37, line 41 skipping to change at page 38, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 29 change blocks. 
61 lines changed or deleted 123 lines changed or added

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