IKEv2 Mobility and Multihoming                                T. Kivinen
(MOBIKE)                                                   Safenet, Inc.
Internet-Draft                                         February 24, 2004
Expires: August 24, 2004

                            MOBIKE protocol

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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 24, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.


   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

              Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              draft-ietf-ipsec-ikev2-12 (work in progress), January

   [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

              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

   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

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

   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

Kivinen                 Expires August 24, 2004                [Page 12]

Internet-Draft              MOBIKE protocol                February 2004



   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Kivinen                 Expires August 24, 2004                [Page 13]