Network Working Group P. Eronen
Internet-Draft Nokia
Expires: September 27, 2004 H. Tschofenig
Siemens
March 29, 2004
Simple Mobility and Multihoming Extensions for IKEv2 (SMOBIKE)
draft-eronen-mobike-simple-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3667.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 27, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes how existing NAT Traversal functionality
could be leveraged to better support mobility and multihoming for
IKEv2. The purpose is not to specify a finished solution, but rather
to provide input for discussions in the MOBIKE WG. In particular,
this draft raises questions to what extent the complexity present in
the two other MOBIKE protocol proposals is actually necessary. These
questions are not answered in this document, but are to be discussed
in the MOBIKE WG.
Eronen & Tschofenig Expires September 27, 2004 [Page 1]
Internet-Draft SMOBIKE March 2004
1. Introduction
IKEv2 NAT Traversal, defined in [4] and [5], allows IPsec to work
through NATs. The main functional components of NAT Traversal are
the following:
o Presence of NAT is detected during the IKEv2 IKE_SA_INIT exchange
using NAT_DETECTION_SOURCE_IP and NET_DETECTION_DESTINATION_IP
Notify payloads.
o ESP packets are encapsulated in UDP.
o The peer behind the NAT sends NAT-keepalive packets to keep NAT
mappings alive if no normal traffic has been sent for some time.
o The peer that is not behind the NAT dynamically updates the other
peer's address to recover from changes in NAT mappings. That is,
IKEv2 and ESP packets are sent to the IP address and port from
which the last valid authenticated packet from the other end was
received.
The last functionality also allows a form of mobility: in typical
corporate VPN gateway scenario, the client can move (that is, change
its IP address) while keeping the VPN connection up as long as it was
behind a NAT when the IKEv2 SA was originally established. This is
because from the gateways point of view, a change in the client's IP
address is indistinguishable from a change in NAT mappings.
Figure 1 shows the standard VPN scenario where the mobility
enhancements of IPsec could be deployed. In this scenario the IKEv2
initiator establishes an IPsec tunnel to the VPN GW. After the tunnel
establishment the the IKEv2 initiator changes its IP address. Several
reasons could be responsible for this address change, such as
interface switching, DHCP lease time expiry, IPv6 privacy extensions,
or mobility. In Figure 1 we focus on the mobility case. As a result
the SAD entries have to be updated on both nodes (typically via
extensions to the PF_KEY interface). No update for the IKE-SA is
required since it is not bound to an IP address. A NAT might be along
the path between the two IKEv2 peers.
Eronen & Tschofenig Expires September 27, 2004 [Page 2]
Internet-Draft SMOBIKE March 2004
Initial
IKEv2
Exchange +-----------+ +--------+
(1) | IKEv2 | | App. |
+-/////////----->+ Responder +<--------->+ Server |
/ | (VPN GW) | | |
/ +-----+-----+ +--------+
/ ^
| | IKEv2 signaling /
| | IPsec data traffic
v v (2)
+------+-----+ +------+-----+
| IKEv2 |Movement | IKEv2 |
| Initiator |........>| Initiator |
| VPN client | | VPN client |
+------------+ +------------+
Figure 1: Mobility in VPN scenario
It might be worth noting that mobility and static multi-homing are
different with respect to their requirements. This draft is also
applicable to static multi-homing to a large extent.
This document specifies how this existing functionality can be
leveraged to better support mobility and multihoming. This is done by
allowing the use of dynamic address updates and/or UDP encapsulation
even when no NATs are detected.
The main purpose of this draft is not to specify a finished solution,
but rather to provide input for discussions in the MOBIKE WG. In
particular, this draft tries to present a simpler alternative to the
two other proposals, [1] and [6], and raises questions to what extent
the complexity in the other two proposals is actually necessary.
Furthermore, the authors believe that ability to work together with
NATs is a required functionality.
2. SMOBIKE Protocol
2.1 Indicating support for SMOBIKE
Implementations that support SMOBIKE indicate this by including a
Vendor ID payload in the IKE_SA_INIT exchange (first two messages).
The value for this payload is 30DB45C6 AF1CA28C DAC08C30 9CE062C5
(MD5 hash of the string "draft-eronen-mobike-simple").
2.2 Enabling dynamic address updates
In NAT Traversal, the peer that is not behind the NAT dynamically
Eronen & Tschofenig Expires September 27, 2004 [Page 3]
Internet-Draft SMOBIKE March 2004
updates the other peer's address to recover from changes in NAT
mappings. That is, IKEv2 and ESP packets are sent to the IP address
and port from which the last valid authenticated packet from the
other end was received.
By sending the USE_DYNAMIC_ADDRESS_UPDATES Notify payload, a peer can
instruct the other peer to dynamically update its address even when
no NAT is present. Note that this enables just dynamic address
updates, but does not automatically mean UDP encapsulation.
2.3 Changing addresses
The procedure when changing address depends on how UDP encapsulation
is used. Note that the same procedure applies to both a mobile host
moving to another address, and a multihomed host switching to another
interface.
If the host does not support UDP encapsulation (perhaps it is
disabled by configuration), just start using the new address.
If the host is currently using UDP encapsulation, and wants to
keep on using it, just starting using the new address.
If the host is unsure whether the current setting of UDP
encapsulation is the right one for the new address, perform a new
NAT detection.
If the current setting of UDP encapsulation is the right one, it is
sufficient to just start using the new address; the other party will
update the address when it receives an authenticated packet. If there
are no ESP packets to send, the host can send an empty IKEv2
Informational exchange.
In some cases, it may be necessary to either turn on UDP
encapsulation (when moving to behind a NAT), or turn it off (when
moving back to clear). A host can request a new NAT detection by
sending an Informational exchange with NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP payloads.
These payloads are processed the same way as in initial IKE_SA_INIT
exchange.
2.4 UDP encapsulation without NATs
There are cases when UDP encapsulation is needed even when no NATs
are present. A typical example would be a stateful firewall that
performs similar filtering as a "symmetric" NAT [8], but does not
change the IP addresses (and therefore is not detected by
Eronen & Tschofenig Expires September 27, 2004 [Page 4]
Internet-Draft SMOBIKE March 2004
NAT_DETECTION payloads).
A host can be configured to always use UDP encapsulation, or it can
guess that UDP encapsulation might be needed if it does not receive
any ESP packets. In some mobile or ad hoc networks UDP encapsulation
could be always used since a route change in the network might cause
packets to traverse a NAT even without end-host mobility.
The host can then force the use of UDP encapsulation by including a
USE_UDP_ENCAPSULATION Notify payload in the same message as
NAT_DETECTION payloads.
3. Analysis
This section presents a short analysis of how SMOBIKE handles
different mobility and multihoming cases.
1. One or both of the parties are mobile and/or multi-homed. No NATs
(or stateful firewalls) are present.
SMOBIKE works fine, except in some variations of simultaneous
address change (see below). This case is typical in multihoming
situations: e.g. a multihomed host talking to a single-homed host,
or two multihomed gateways/hosts talking to each other.
The only case where SMOBIKE does not work is if (a) both parties
change addresses simultaneously and (b) disable their old
addresses before the other party has received the update. In this
case, neither of the parties knows the current address of the
other party, so they cannot communicate.
2. One party is stationary, single-homed, and not behind a NAT. The
other party is be mobile and/or multihomed, and sometimes behind a
NAT (or stateful firewall).
SMOBIKE handles this as well. UDP encapsulation can also be
switched off when it is not needed. This case is the typical case
of a mobile client talking to a single-homed VPN gateway.
3. Both parties are mobile and/or multihomed, and there is a "full
cone" NAT (see [8] for a description of different NAT types)
between them.
This case could be made to work (except for the special case
simultaneous address change described above).
Eronen & Tschofenig Expires September 27, 2004 [Page 5]
Internet-Draft SMOBIKE March 2004
4. Both parties are mobile and/or multihomed, and there is a
"restricted cone", "port restricted cone" or "symmetric" NAT [8],
or a stateful firewall, between them.
This case does not work. The NAT (or firewall) blocks the address
updates sent by the party outside the NAT.
Assuming that simultaneous mobility is not very important, this
analysis would seem to indicate that more complex solutions are
justified only if they not only handle cases #1-#3, but also improve
case #4. Not handling case #2 would in our opinion be a serious
deficiency.
SMOBIKE does not support moving traffic to a new address before the
host is able to send packets using the new address as a source
address. Other than that, SMOBIKE works for both "break-before-make"
(host breaks its old connection before the new connection is fully
established) and "make-before-break" (both connections work for a
while during mobility) situations.
4. Security Considerations
In the current version, this section lists only the most important
points about this protocol.
Just like normal IKEv2 NAT Traversal, SMOBIKE does not send the IP
addresses inside IKEv2 payloads, only in the IP header. These
addresses are not integrity protection and not authenticated.
Protecting these addresses would render the protocol incompatible
with NAT Traversal. This problem is already known from other areas
such as Mobile IP NAT traversal.
This leads to two possible problems, also known as "transient
pseudo-NAT attack" and "third party bombing".
In the "transient pseudo-NAT attack" [3], an attacker intercepts
authenticated packets and changes their source IP address (and port).
As a consequence the recipient will start using the incorrect peer
address, and send IPsec protected data traffic to this address. If
the adversary provides an address which is a blackhole then traffic
sent to this address will be dropped. This represents a denial of
service attack. Obviously, an attacker who can modify packets between
the parties could also change e.g. the ICV field, causing the packets
to be dropped. Also, the situation is self-fixing: when an unmodified
packet gets through, the address is updated back to the correct one.
In "third party bombing" [2], a valid peer redirects its traffic to
some third party with the intent of flooding the victim with large
Eronen & Tschofenig Expires September 27, 2004 [Page 6]
Internet-Draft SMOBIKE March 2004
amounts of traffic. For this attack to continue, the attacker has to
keep sending traffic with spoofed IP address, because otherwise dead
peer detection will fix the situation. Even if the MOBIKE extensions
had more complex return routability checks, the attacker could claim
not to support them, and use normal IKEv2 NAT Traversal for the
attack instead. A regular IKEv2 dead peer exchange will also detect
third party bombing.
Both attacks require that the adversary is along the data path. Note
that unlike, for instance, in standard Mobile IP, IPsec protects the
transmitted payloads from eavesdropping and modification, and thus
the consequences of traffic redirection are different.
It might be worth mentioning that a truly secure NAT traversal can be
accomplished only if the client can determine which NAT devices are
actually authorized to modify the addresses, and communicate with
them in secure fashion to determine the current mappings. This
requires a protocol for communicating with the NAT, such as NSIS. A
detailed discussion of these approaches is far beyond the scope of
this document.
5. IANA Considerations
Two new Notify payloads, USE_DYNAMIC_ADDRESS_UPDATES and
USE_UDP_ENCAPSULATION.
6. Acknowledgments
This draft obviously borrows many ideas from Tero Kivinen and Francis
Dupont, although it ended up looking a bit different than their work.
References
[1] Dupont, F., "Address Management for IKE version 2",
draft-dupont-ikev2-addrmgmt-04 (work in progress), February
2004.
[2] Dupont, F., "A note about 3rd party bombing in Mobile IPv6",
draft-dupont-mipv6-3bombing-00 (work in progress), February
2004.
[3] Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks or how
NATs are even more evil than you believed",
draft-dupont-transient-pseudonat-03 (work in progress), February
2004.
[4] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M.
Stenberg, "UDP Encapsulation of IPsec Packets",
Eronen & Tschofenig Expires September 27, 2004 [Page 7]
Internet-Draft SMOBIKE March 2004
draft-ietf-ipsec-udp-encaps-08 (work in progress), February
2004.
[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-13 (work in progress), March 2004.
[6] Kivinen, T., "MOBIKE protocol", draft-kivinen-mobike-protocol-00
(work in progress), February 2004.
[7] Kivinen, T., "Design of the MOBIKE protocol",
draft-kivinen-mobike-design-00 (work in progress), February
2004.
[8] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)", RFC 3489, March 2003.
Authors' Addresses
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Eronen & Tschofenig Expires September 27, 2004 [Page 8]
Internet-Draft SMOBIKE March 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eronen & Tschofenig Expires September 27, 2004 [Page 9]