INTERNET DRAFT Rajesh Bhalla Category: Individual submission Kent Leung Title: draft-subbarao-mobileip-resource-00.txt Alpesh Patel Expires September 2001 Madhavi Subbarao Mobile IP Working Group Cisco Systems Releasing Resources in Mobile IP draft-subbarao-mobileip-resource-00.txt Status of this Memo This document is an Internet Draft and is in full compliance 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. Internet Drafts 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 Currently, in Mobile IP when an MN moves from one FA to another FA/CoA, relevant resources at the previous FA are consumed until its visitor entry for the MN expires. The Resource Release Message and Resource Management Extension described in this draft will facilitate the release of these valuable resources at the previous FA as the MN moves to a new location. The HA notifies the previous FA of any changes in the CoA for an MN, thereby allowing the FA to release its resources. Similary, when used in the opposite direction, valuable resources at an HA can be released for an MN if there is early termination on the FA side. Use of the Resource Release Messages and Resource Management Extension will lead to increased network efficiency and system capacity. 1. Introduction Currently, in Mobile IP when a Mobile Node (MN) moves from one Foreign Agent (FA) to another FA/Care-of-Address (CoA), relevant resources at the previous FA are consumed until its visitor entry for the MN expires. Similary, if there is early termination of an MN on the FA side relevant resources at the HA remained consumed until the mobility binding for the MN expires. This leads to inefficient use of network resources which directly affects the efficiency of a Mobile IP network deployment. For example, consider a cdma2000 network deployment using Mobile IP. The Wireless IP Network Standard (IS-835) defines FA/Packet Data Servicing Node (PDSN) procedures for managing the PPP session for a MN, i.e., when the Radio Network opens an R-P session for an MN, the FA/PDSN initiates establishment of a PPP session [1]. As an MN moves from one foreign domain serviced by an FA/PDSN (source PDSN) to another PDSN (target PDSN) during an inter-PDSN handoff, a Mobile IP registration is sent to the Home Agent (HA) and a new PPP session is established at the target PDSN. The PPP session at the source PDSN remains exhausted until the PPP inactivity timer expires. Maintaining these PPP sessions consumes valuable resources at the source PDSN that could otherwise be used to support additional MNs. Thus, it is desirable and more efficient to release the idle PPP session at the source PDSN as soon as possible. The Mobile IP infrastructure should allow for intelligent signaling which would trigger release of the resources at the PDSN/FA. A possible solution is to utilize the Previous Foreign Agent Notification extension offered by Route Optimization in Mobile IP [2]. This extension triggers the new FA to send a Binding Update (BU) to the previous FA to inform it that the MN has moved. As a result, if the previous FA supports resource management, it releases the resources that it was using for the MN. The Previous Foreign Agent Notification extension, however, must be initiated by the MN, i.e., the MN must include the extension in a Registration Request (RRQ) to the new FA to instruct the new FA to send a BU to the previous FA. Although this is possible, it may not be a practical or viable solution since it requires modification to all mobile devices to include the Previous Foreign Agent Notification extension. Moreover, the BU is sent by the new FA regardless of the resource management capabilities of the previous FA. If the previous FA cannot support resource management or understand the messaging, extra signaling and processing has unnecessarily occurred. Note that this solution is dependent on Route Optimization [2] being employed in the network and does not support releasing resources at the HA. Although intended for a different purpose, a Registration Revocation message as specified in [6] can be sent by the HA to the previous FA upon an MN's movement to a new FA/Care-of-Address (CoA). The result of this message is that resources at the previous FA will be released. Similary, an HA can be informed of termination of an MN on the FA side and thus, release its resources. Currently, the functionality in [6] is subject to denial-of-service attacks since the Registration Revocation beacon, i.e., agent advertisement with sequence number reset, is not authenticated and can be spoofed (communication to the MN). The Registration Revocation message is also sent to the previous FA or HA regardless of their resource management capabilities. This draft proposes a Mobile IP Resource Management Extension that may be appended to an RRQ by an FA that supports resource management, and appended to a Registration Reply (RPY) by an HA that supports resource management. When an HA receives an authenticated RRQ from an MN with a Resource Management Extension, it records the capability of the FA. The HA then uses the Resource Release Message defined in this draft to notify the FA regarding a change in the CoA for the MN . As a result, the FA deletes the visitor entry for the MN and releases the resources being used to support the MN. Similarly, when an FA receives an authenticated RPY from an HA with a Resource Management Extension, it records the capability of the HA. The FA uses the Resource Release Message to notify the HA if there is early termination of an MN on the FA side. The HA then deletes the mobility binding for the MN and releases relevant resources for the MN. Acknowledgement signaling may be used to ensure earnest effort to release resources. 2. Mobile IP Resource Management Extension The Mobile IP Resource Management extension MAY be attached to an RRQ by an FA or an RPY by an HA. It is based on the Short Extension Format given in [3] and is defined as follows: 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 | Length | Subtype |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Skippable (TBD) Length Length (in bytes). Does NOT include Type and Length. Subtype 1 (Resource Management Extension) 'A' Bit When this bit is set, the mobility agent is specifying that it will send an Acknowledgement in receipt of a Resource Release Message. If an Acknowledgement is not received, the Resource Release Message should be retransmitted. This will ensure an earnest attempt to release resources. Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on receiving. Mobile Node Home Address The home IP address of the Mobile Node to which the extension refers. The Mobile IP Resource Management Extension MUST be protected by a FA-HA Authentication Extension (FHAE) as defined in [4]. 3. Resource Release Message The Resource Release Message is used between mobility agents to notify one another that resources for an MN or group of MNs may be released. IP layer fields of the message: Source Address: IP address of the mobility agent initiating the message. If the HA is initiating the message, the address is the IP address of the HA. If the FA is initiating the message, the address is the IP address of the FA. Destination Address: IP address of the target mobility agent for the message. If the HA is initiating the message, the destination address is the IP address of the FA. If the FA is initiating the message, the destination address is the IP address of the HA. UDP fields of the message: Source Port 434 Destination Port 434 Mobile IP fields of the 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 | Subtype |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA/FA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Subtype 1 Enable release of resources 'A' bit This bit MUST be set if the target mobility agent set the 'A' bit in its Resource Management Extension. Reserved Reserved for future use. MUST be set to 0 on sending and ignored on receiving. Mobile Node Home Address The Home IP address of the MN whose resources should be released. MAY be set to zero to denote a group of MNs (see Sections 6 and 7). HA/FA Address The IP address of the mobility agent initiating the message. Identification A 64-bit number used for protecting against replay attacks as defined in [4]. Used in a similar manner as described in [4]. The Mobile IP Resource Release Message MUST be protected by the FHAE. 4. Resource Release Acknowledgement Message The Resource Release Acknowledgement Message is sent by a mobility agent that set the 'A' bit in its Resource Management Extension upon the receipt of a Resource Release Message. IP layer fields of the message: Source Address: IP address of the mobility agent initiating the acknowledgement message. If the HA is initiating the message, the address is the IP address of the HA. If the FA is initiating the message, the address is the IP address of the FA. Destination Address: IP address of the target mobility agent for the acknowledgement message. If the HA is initiating the message, the destination address is the IP address of the FA. If the FA is initiating the message, the destination address is the IP address of the HA. UDP fields of the message: Source Port 434 Destination Port 434 Mobile IP fields of the 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 | Reserved | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Reserved Reserved for future use. MUST be set to 0 on sending and ignored on receiving. Status If the Resource Release Message was received without error, this field is set to zero. However, if there is an error in reception, the field is nonzero with the following allowable codes defined in [4]: 128 reason unspecified 129 administratively prohibited 130 insufficient resources 131 sending node failed authentication 133 identification mismatch TBD poorly formed Resource Release Message (see Section 8) Mobile Node Home Address Copied from the Resource Release Message being acknowledged. Identification Copied from the Resource Release Message being acknowledged. The Resource Release Acknowledgement Message MUST be protected by the FHAE as defined in [4]. 5. Mobile Node Considerations There are no modifications in behavior required by the MN. 6. Foreign Agent Considerations If an FA is capable of resource management, understands the Resource Release Message, and shares a security association with the HA, it SHOULD append the Mobile IP Resource Management Extension to an RRQ received from an MN. The FA MAY set the 'A' bit in the extension to indicate that it will acknowledge the received Resource Release Messages. The FA MUST protect this extension with an FHAE. By appending this extension, the FA informs the HA that it is capable of managing network resources and should be notified of a change in this MN's CoA. Upon receipt of a Resource Release Message from an HA, the FA MUST check for proper authentication and identification of the message as defined in [4]. If the FHAE or Identification is not valid, the FA MUST silently discard the message. If the Resource Release Message is properly authenticated and the MN home address and HA address in the message match an entry in its visitor table, the FA SHOULD delete the visitor entry and release relevant resources for the MN. (For example, see [5] for resource releasing behavior of a PDSN in a cdma2000 network.) If the MN address field in the message is set to zero, the FA SHOULD delete all entries in its visitor table that match the HA address field in the message, i.e., all MNs that are serviced by the HA specified in the Resource Release Message. Furthermore, the FA SHOULD release all relevant resources for the MNs. If the 'A' bit is set in the Resource Release Message (which means that it was set in the Resource Management Extension sent by the FA), the FA MUST send a Resource Release Acknowledgement Message back to the HA. If the FA is releasing resources of MN(s) as a result of a received Resource Release Message from the HA, the FA MUST NOT send a Resource Release Messsage back to the HA. If the FA receives an authenticated RPY with a Resource Management Extension appended, the FA MUST ensure that the FHAE is valid. If the FA-HA authentication fails, the HA must proceed as outlined in [4] and reject the RPY. If the HA does not support the Resource Management Extension, it should simply ignore the extension. After authenticating the FHAE, the FA should record the capability of the HA, e.g., set a Resource Management Flag and an Acknowledgement Flag (if necessary) in the visitor entry information for the MN. If there is an early termination on the FA side for the MN, the FA SHOULD send a Resource Release Message to the HA. The FA should set the MN address field to the home IP address of the MN, the HA/FA address to its own IP address, and the Identification field and 'A' bit appropriately. The FA MUST include the FHAE. If the FA wishes to notify the HA that all MNs serviced by the FA should be released, the FA sends the Resource Release Message with the MN address set to zero, HA/FA address set to its own IP address, and Identification field and 'A' bit set appropriately. The FA MUST include the FHAE. Upon sending a Resource Release Message with the 'A' bit set, if the FA does not receive an Resource Release Acknowledgement Message from the HA, it SHOULD retransmit the message. 7. Home Agent Considerations If an HA shares a security association with an FA, understands the Resource Release Message, and supports resource management, the HA SHOULD append the Resource Management Extension to an RPY. The HA MAY set the 'A' bit in the extension to indicate that it will acknowledge the received Resource Release Message. The HA must protect the extension with the FHAE. By including this extension, the HA informs the FA that it wishes to be notified of termination of the visitor entry for the MN. Upon receipt of a Resource Release Message from an FA, the HA MUST check for proper authentication and identification of the message as defined in [4]. If the FHAE or Identification is not valid, the HA MUST silently discard the message. If the Resource Release Message is properly authenticated and the MN home address and FA address in the message match an entry in its mobility binding table, the HA SHOULD delete the mobility binding and release relevant resources for the MN. If the MN address field in the message is set to zero, the HA SHOULD delete all mobility bindings with CoA matching the FA address field in the message, i.e., all MNs that are serviced by the FA specified in the Resource Release Message. Furthermore, the HA SHOULD release all relevant resources for the MNs. If the 'A' bit is set in the Resource Release Message (which means that it was set in the Resource Management Extension sent by the HA), the HA MUST send a Resource Release Acknowledgement Message back to the FA. If the HA is releasing resources for MN(s) as a result of a received Resource Release Message from the FA, the HA MUST NOT send a Resource Release Messsage back to the FA. If an HA receives an RRQ from an MN with a valid MN-HA Authentication Extension and a Resource Management Extension, it MUST ensure that the FHAE is valid. If the FA-HA authentication fails, the HA must proceed as outlined in [4] and reject the RRQ. If the HA does not support the Resource Management Extension, it should simply ignore the extension. After authenticating the FHAE, the HA should record the capability of the FA, e.g., set a Resource Management Flag and Acknowledgement Flag (if necessary) in the mobility binding information for the MN. When the HA receives an RRQ from the MN via a new FA (or different CoA) or a deregistration, and if the HA is aware that the previous FA supports resource management, e.g., a Resource Management Flag in the mobility binding is set, the HA SHOULD send a Resource Release Message to the previous FA notifying the FA of the change in CoA. The HA sets the MN address field in the message to the home address of the MN, the HA/FA address field to its own IP address, the 'A' bit appropriately, and the Identification field similar to that specified in [4]. The HA MUST include the FHAE. If the HA wishes to notify an FA that supports resource management that all MNs serviced by the HA should be released, the HA sends the Resource Release Message with the MN address set to zero, HA/FA address set to its own IP address, and Identification field and 'A' bit set appropriately. The HA MUST include the FHAE. Upon sending a Resource Release Message with the 'A' bit set, if the HA does not receive an Resource Release Acknowledgement Message from the FA, it SHOULD retransmit the message. 8. Error Code The error code "poorly formed Resource Release Message" was introduced in Section 4 and may be returned in a Resource Release Acknowledgement Message. This error code conveys that the Resource Release Message was not properly formed and could not be parsed by the receiving mobility agent. 9. IANA Considerations The Mobile IP Resource Management Extension defined in Section 2 is a Mobile IP registration extension as defined in RFC 2002 [4]. IANA should assign a Type value consistent with this number space. The Mobile IP Resource Release Message defined in Section 3 and Resource Release Acknowledgement Message defined in Section 4 should be assigned Type values consistent with the number space defined in [4]. The Code value in Section 8 is an error code as defined in RFC 2002 [4]. IANA should assign a value to the code consistent with this number space. 10. Security Considerations Mobile IP registration messages are authenticated, and the authentication verified by the recipient. The Mobile IP Resource Management Extension, Resource Release Message, and Resource Release Acknowledgement Message are protected by the FHAE [4]. Appendix A: If Route Optimization [2] is used in the network, Binding Updates can be used for signaling between the HA and FA to notify the FA to release its resources. In order to support BU signaling from an FA to an HA, the Route Optimization draft [2] needs to be modified to allow for a BU to be sent from an FA to an HA, and for the HA to be able to process a BU. Note, however, that the generic feature of releasing a group of MNs (MN address of zero in the Resource Release Message) can not be achieved with Binding Updates. 11. References [1] TIA/EIA/IS-835, Wireless IP Network Standard, June 2000. [2] C. Perkins and D. Johnson, Route Optimization in Mobile IP, Internet Draft, Internet Engineering Task Force, draft-ietf-mobileip-optim-10.txt, Work in progress, November 2000. [3] M. Khalil, et. al., Mobile IP Extensions Rationalization (MIER), Internet Draft, Internet Engineering Task Force, draft-ietf-mobileip-mier-05.txt, Work in progress, May 2000. [4] C. Perkins, IP Mobility Support for IPv4, revised, Internet Draft, Internet Engineering Task Force, draft-ietf-mobileip-rfc2002-bis-01.txt, Work in progress, January 2000. [5] Rajesh Bhalla, "PPP Resource Management at the PDSN". 3Gpp2-P00-20010115-011, Cisco Systems, January 2001. [6] S. Glass, Registration Revocation for Mobile IP, Internet Draft, Internet Engineering Task Force. draft-glass-mobileip-reg-revok-00.txt, Work in progress, July 2000. Author's Addresses Questions about this memo can be directed to: Rajesh Bhalla Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA email: rabhalla@cisco.com phone: +1 408 853 9265 fax: +1 408 Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA email: kleung@cisco.com phone: +1 408 526 5030 fax: +1 408 526 4952 Alpesh Patel Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA email: alpesh@cisco.com phone: +1 408 853 9580 fax: +1 408 526 4952 Madhavi Subbarao Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 USA email: msubbara@cisco.com phone: +1 919 392 8387 Expires September 2001