IKEv2 Mobility and Multihoming T. Kivinen
(MOBIKE) Safenet, Inc.
Internet-Draft February 24, 2004
Expires: August 24, 2004
MOBIKE protocol
draft-kivinen-mobike-protocol-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes the base MOBIKE (IKEv2 mobility and
multihoming) protocol. The base protocol contains protocol to notify
the other end about the address changes and rules how to change to
use new IP-addresses.
Kivinen Expires August 24, 2004 [Page 1]
Internet-Draft MOBIKE protocol February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Multihoming Rules . . . . . . . . . . . . . . . . . . . . . . 4
3. Address Notify Protocol . . . . . . . . . . . . . . . . . . . 5
4. Scope of SA changes . . . . . . . . . . . . . . . . . . . . . 6
5. Zero Address Set . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Normative references . . . . . . . . . . . . . . . . . . . . . 10
Non-normative references . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Kivinen Expires August 24, 2004 [Page 2]
Internet-Draft MOBIKE protocol February 2004
1. Introduction
The protocol described here will try to use as much as possible of
the existing IKEv2 [I-D.ietf-ipsec-ikev2] features and code. It uses
IKEv2 notify payloads to notify about the address updates. It uses
multiple notify payloads when multiple IP-address are present, and it
uses IKEv2 dead-peer-detection as return routability checks. It also
ties IKE SA and IPsec SAs created by that IKE SA together, and both
of them move to new IP-address at the same time.
Kivinen Expires August 24, 2004 [Page 3]
Internet-Draft MOBIKE protocol February 2004
2. Multihoming Rules
Peer SHOULD use the most preferred address as long as there is no
indication that it does not work. If it receives direct notification
which changes the most preferred address, it SHOULD immediately start
to use that address. If that new preferred address have not been used
before, it SHOULD also initate dead-peer-detection using that new
address (return routability check). The traffic should still be moved
immediately to new address, while doing the dead-peer-detection. The
dead-peer-detection MAY be left out, if successfull
dead-peer-detection has already been performed to the address
earlier. If the last dead-peer-detection to that address has failed,
then the traffic SHOULD only be moved to that address after
successfull dead-peer-detection has been done on that address.
If indirect indication of address change is received (i.e. source
address of the incoming packet change, ICMP is received, or no
packets from the other has been seen for a while), then the peer
SHOULD initiate dead-peer-detection on the currently used address.
While no response is received after some time and few
retransmissions, the next retransmissions SHOULD use the most
preferred address not yet tried. At that time the retransmission
timers are reset back to the original (i.e. exponential backoff
timers are reset to the original values every time new IP-address is
tried). This means that each address are tried one at the time, in
the order: currently used address, and then from most preferred one
to the least preferred one, but not trying currently used address
twice. All the dead-peer-detection packets are empty informational
exchange packets having same message-id.
If any of the dead-peer-detection packets receive reply, then that
IP-address is marked as to be currently used address, and all traffic
is moved to that IP-address. If no response is received after trying
all IP-address, then the IKE SA is deleted along with all IPsec SAs
created by it.
Even when doing dead-peer-detection as a response to the direct
update request, the process of trying all IP-address is same, i.e.
first try the most preferred one given in the notification, and then
if that fails move to the next IP-address etc.
Kivinen Expires August 24, 2004 [Page 4]
Internet-Draft MOBIKE protocol February 2004
3. Address Notify Protocol
To notify the other end that the IP-addresses have changed the peer
uses informational exchange containing ordered list of IKEv2 notify
payloads. The payloads contain all the possible IP-address for the
peer, from the most preferred to the least preferred, and they
overwrite the old address list for the IKE SA. In case of out of
order processing of the informational exchanges, the most resent one
(having larger message-id) is used, and the older ones are simply
acknoledged without any processing. In case the peer supports message
id window the the peer should store the message-id of last address
change notification in case it receives older notifications later.
Each notify payload contains 1 IP-address, either IPv4 or IPv6. The
type of the IP-address inside can be seen from the notify message
type. The protocol ID MUST be set to 1 (IKE), and the SPI Size MUST
be 0, which means that the SPI field will be left out. The Notify
message type is either IPV4_ADDRESS_CHANGE (42004) or
IPV6_ADDRESS_CHANGE (42006) depending on the IP-address type (42004
for IPv4 and 42006 for IPv6). The notification data will contain the
IP-address in network byte order as either 4 or 16 bytes. There might
be extra data after the the IP-address and that data MUST be ignored
(i.e. it is reserved for future expansion).
The notify payload will be as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID=0 ! SPI Size=0 ! Notify Message Type = 42004/6 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data = IPv4 or IPv6 address ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There can be multiple notify payloads each having one IP-address, and
the responder MUST be able to process at least 4 first notify
payloads, and it MAY ignore the rest.
All notify payloads are sent as one IKEv2 packet, and the responder
MUST acknowledge the packet. The acknowledgement packet MUST NOT
contain the responders IPV4_ADDRESS_CHANGE and/or IPV6_ADDRESS_CHANGE
notifications (order of such packets related to the normal address
change notifications initiated by the same peer, is not specified).
Kivinen Expires August 24, 2004 [Page 5]
Internet-Draft MOBIKE protocol February 2004
4. Scope of SA changes
Every time the IKE SA addresses are updated, all the IPsec SAs
created using that IKE SA are updated at the same time, and IKE SA
and IPsec SAs share the currently used IP-address.
Kivinen Expires August 24, 2004 [Page 6]
Internet-Draft MOBIKE protocol February 2004
5. Zero Address Set
Disconnect notifications are sent as separate informational exchange,
having DISCONNECT_NOTIFY (42000) notify payload. The Protocol ID MUST
be set to 0, SPI Size MUST be 0, SPI field will be omitted, and the
notification data contains 32-bit number indicating the time in
seconds how long the peer assumes to be disconnected. This time can
be used by the other end to decide whether to allow the disconnect,
or whether to reject it by sending delete notification of the IKE SA
inside the acknowledgement packet.
Kivinen Expires August 24, 2004 [Page 7]
Internet-Draft MOBIKE protocol February 2004
6. Security Considerations
As all the messages are already authenticated by the IKEv2 there is
no problem that any attackers would modify the actual contents of the
packets. The IP addresses in the packets are not authenticated, and
are only an indication that something might be different, they do not
cause any other actions then initiation of dead-peer-detection to the
authenticated addresses.
One type of attacks which needs to be taken care of the MOBIKE
protocol is also various flooding attacks. See
[I-D.nikander-mobileip-v6-ro-sec] and [Aur02] for more information
about flooding attacks.
Kivinen Expires August 24, 2004 [Page 8]
Internet-Draft MOBIKE protocol February 2004
7. IANA Considerations
This document allocates 3 new status types to the IKEv2 Notify
Messages - Status Types registry. The allocated types are:
NOTIFY MESSAGES - STATUS TYPES Value
------------------------------ -----
DISCONNECT_NOTIFY 42000
IPV4_ADDRESS_CHANGE 42004
IPV6_ADDRESS_CHANGE 42006
Kivinen Expires August 24, 2004 [Page 9]
Internet-Draft MOBIKE protocol February 2004
Normative references
[I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-12 (work in progress), January
2004.
[Kiv04] Kivinen, T., "Design of the MOBIKE protocol",
draft-kivinen-mobike-design-00 (work in progress),
February 2004.
Kivinen Expires August 24, 2004 [Page 10]
Internet-Draft MOBIKE protocol February 2004
Non-normative references
[I-D.nikander-mobileip-v6-ro-sec]
Nikander, P., "Mobile IP version 6 Route Optimization
Security Design Background",
draft-nikander-mobileip-v6-ro-sec-02 (work in progress),
December 2003.
[Aur02] Aura, T., Roe, M. and J. Arkko, "Security of Internet
Location Management", In Proc. 18th Annual Computer
Security Applications Conference, pages 78-87, Las Vegas,
NV USA, December 2002.
Author's Address
Tero Kivinen
Safenet, Inc.
Fredrikinkatu 47
HELSINKI FIN-00100
FI
EMail: kivinen@safenet-inc.com
Kivinen Expires August 24, 2004 [Page 11]
Internet-Draft MOBIKE protocol February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Kivinen Expires August 24, 2004 [Page 12]
Internet-Draft MOBIKE protocol February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kivinen Expires August 24, 2004 [Page 13]