Internet Engineering Task Force Mohamed M Khalil INTERNET DRAFT Liem Le Nortel Networks Date: June 1999 Expires: December, 1999 Security Enhancements for Route Optimization 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. Abstract This document defines an extension to the current route optimization algorithm [1] to improve the security and minimize the window of data loss of the current optimization algorithm. Khalil, Le Expires December 1999 [Page 1] Internet-Draft draft-khalil-mobileip-optim-sec-00.txt July 1999 Table of Contents 1. Introduction 2. Specification Language 3. Problem Statement 4. Foreign Agent Smooth Handoff 4.1 Start Forward Data message 4.2 Binding Request Message 4.3 Binding Update Message 4.4 Request Acknowledge Message 1. Introduction This document defines an extension to the current route optimization algorithm [1] to improve the security and minimize the window of data loss. The goal of this extension is to : a. Prevent unauthorized new foreign agent from receiving data forwarded to the mobile node from the previous foreign agent during the process of handoff. This would happen if the previous foreign agent starts forwarding data to the new foreign agent before the mobile node has authenticated the new foreign agent using the MN-FA authentication extension included in the registration reply message. b. Minimize the window of data loss during the process of handoff. According to current route optimization [1], the previous foreign agent is notified of the handoff by the Binding Update message sent by the new foreign agent that is initiated as a result of receiving a Registration Request (with previous foreign agent notification extension) from the mobile node. In our approach, the previous foreign agent is notified of the handoff directly by the mobile node at the same time it sends the Registration Request message to the new foreign agent. To achieve the previous goals we SHOULD take into consideration of the following rules: 1- Prior to the mobile node's authentication of the new foreign agent, the mobile node SHOULD send a message to the previous foreign agent to do the following [1]: - Delete the mobile node from the visiting list and create a binding update cache entry for the mobile node using the new care-of address. Khalil, Le Expires December 1999 [Page 2] Internet-Draft draft-khalil-mobileip-optim-sec-00.txt July 1999 - Instructs the previous foreign agent to start buffering data destined to the mobile node from other correspondent nodes. 2- After mobile node authenticates the new foreign agent, mobile node SHOULD send a message to the previous foreign agent to start forwarding data to the new foreign agent. 2. Specification Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. 3. Problem Statement Cloning a mobile node is an existing problem with the current wireless systems which has been solved with different security mechanisms and techniques. Since mobile routers will be common in the next few years, cloning a mobile agent (e.g. foreign agent or home agent is an immanent threat for sub-networks who implement mobile IP protocol. According to the current routing algorithm [1] a mobile node sends A registration request with the Previous Foreign Agent Notification Extension [1] to the new foreign agent. As part of the registration procedure the new foreign agent will construct a binding update message which will be forwarded to the previous foreign agent. The previous foreign agent will authenticate the binding update message. If the authentication is correct, the previous foreign agent will remove the mobile node from the visiting list, update its binding cache with the mobile node, and immediately starts encapsulating data, destined to the mobile node, to the new foreign. The problem with previous scenario is that the previous foreign Agent starts to forward data immediately to the new foreign agent before the mobile node is authenticating the personality of the new Foreign agent. If we assume that the new foreign agent is impersonating a good foreign agent then it will have a chance to spy on the data destined to the mobile node without the mobile node permission. In the following section we will describe our approach to overcome this security problem 4. Foreign Agent Smooth Handoff The new extension will perform the following steps to allow a Khalil, Le Expires December 1999 [Page 3] Internet-Draft draft-khalil-mobileip-optim-sec-00.txt July 1999 smooth and secure handoff: - As soon as mobile node needs to change its sub-network point of attachment, it will send a registration request to its home agent. At the same time, the mobile node will also send a Binding Update message to the previous foreign agent. When the previous foreign agent receives the Binding Update message, it will authenticate the message with the security association between itself and the mobile node. If the message is authenticated, the visitor list entry for the mobile node will be deleted and a Binding Acknowledge message will be returned to the mobile node. The previous foreign agent will then create a binding cache entry for the mobile node using the new care-of address [1]. According to our new extension, the previous foreign agent will not forward any tunneled data to the new care-of address until the previous foreign agent receives a Start Forward Data message from the mobile node. The previous foreign agent, however, will continue to buffer the data destined for the mobile node during this period (i.e., before receiving the Start Forward Data message). - When the new foreign agent receives a registration reply destined for the mobile node from a home agent, it MUST add a FA-MN authentication extension. When the mobile node receives the registration reply, it will process it according to procedure in [2] and authenticate the new foreign agent. If the new foreign agent is authenticated the mobile node will then send a Start Forward Data message to the previous foreign agent. Upon receiving this message, the previous foreign agent will begin to tunnel data to the new mobile node's care-of address (i.e. the authenticated new foreign agent). The following messages are defined for this extension. 4.1. Start Forward Message The Start Forward Data Message is used by the mobile node to notify the previous foreign agent to start forwarding data. The Start Forward Data SHOULD be sent by the mobile node after the mobile node has authenticated the new foreign agent. Khalil, Le Expires December 1999 [Page 4] Internet-Draft draft-khalil-mobileip-optim-sec-00.txt July 1999 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |A| Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The mobile-foreign agent authentication extension +-+-+-+-+-+-+-+- The format of the Binding Update message is illustrated above, and contains the following fields: Type TBD A The 'A' (acknowledge) bit is set by the node sending the Binding Update message to request a Binding Acknowledge message be returned. Rsvd Reserved. Sent as 0, ignored on reception. Mobile Node Home Address The home address of the mobile node. Identification a 64-bit number, assigned by the node sending the Start Forward Data message, used to assist in matching requests with replies, and in protecting against replay attacks. 4.2. Binding Request Message As it is defined in [1]. 4.3. Binding Update Message As it is define in [1]. A new flag B will be added to indicate that data should be buffered. This flag is set in the Binding Update Khalil, Le Expires December 1999 [Page 5] Internet-Draft draft-khalil-mobileip-optim-sec-00.txt July 1999 message sent by the mobile node to the previous foreign agent. 4.4. Request Acknowledge Message A Request Acknowledge message is used to acknowledge receipt of a Binding Update message or Start Forward Data messages. It should be sent by a node receiving a Binding Update or Start Forward Data message if the acknowledge (A) bit is set in the Binding Update or Start Forward Data message. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |B|F| | Reserved | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Request Acknowledge message is illustrated above, and contains the following fields: Type TBD B the acknowledged message is for Binding Update message. F the acknowledged message is for Start Forward data message. Status Code If the Status is nonzero, this acknowledgment is negative. The error code field should be set to appropriate value which indicates the type of error. Mobile Node Home Address Copied from the Binding Update message being acknowledged. Identification Copied from the Binding Update message being acknowledged, if present there. Khalil, Le Expires December 1999 [Page 6] Internet-Draft draft-khalil-mobileip-optim-sec-00.txt July 1999 5. References [1] Charles Perkins. Route Optimization in Mobile IP. Draft-ietf- mobileip-optim-08.txt. 20 November 1997. [2] Charles Perkins. Special Tunnels for Mobile IP. Draft-ietf- mobileip-spectun-00.txt. 20 November 1997. [3] Carey B. Becker. IP Mobility Architecture Framework. draft- ietf-mobileip-ipm-arch-00.txt. September 1999. [4] Scott Bradner. Key words for use in RFCs to indicate requirement levels. RFC 2119, March 1997. Khalil, Le Expires December 1999 [Page 7] Internet-Draft draft-khalil-mobileip-optim-sec-00.txt July 1999 Authors' Addresses Mohamed M khalil 2221 Lakeside Blvd. Richardson TX 75082-4399 Phone: 972 685-0564 Fax : 972 685-3207 email: mkhalil@nortelnetworks.com Liem Le 2221 Lakeside Blvd. Richardson TX 75082-4399 Phone: 972 684-0689 Fax : 972 685-3207 email: liemle@nortelnetworks.com Khalil, Le Expires December 1999 [Page 8]