Mext Working Group X. Cui (Ed.) Internet Draft Huawei Intended status: Standards Track A. Makela Expires: May 2010 TKK November 9, 2009 Binding Revocation from correspondent node in Route Optimization Mode draft-cui-mext-cn-binding-revocation-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 May 8 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Cui Expires May 8, 2010 [Page 1] Internet-Draft CN Binding Revocation November 2009 Abstract This document specifies an extension to Binding Revocation mechanism; the correspondent node may also initiate the binding revocation in Route Optimization mode. This extension provides a method to change the Route Optimization mode to the Bidirectional Tunneling mode. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Cui Expires May 8, 2010 [Page 2] Internet-Draft CN Binding Revocation November 2009 Table of Contents 1. Introduction..................................................4 2. Terminology...................................................4 3. Protocol and Use Case Overview................................5 4. Correspondent Node Operation..................................6 5. Mobile Node Operation.........................................7 6. Messages and Options..........................................8 7. Security Considerations.......................................8 8. IANA Considerations...........................................8 9. Acknowledgments...............................................8 10. References...................................................8 10.1. Normative References....................................8 10.2. Informative References..................................9 Author's Addresses...............................................9 Cui Expires May 8, 2010 [Page 3] Internet-Draft CN Binding Revocation November 2009 1. Introduction Mobility Support in IPv6 [RFC3775] specifies two possible modes for communications between the Mobile Node (MN) and a Correspondent Node (CN), Bidirectional Tunneling mode and Route Optimization (RO) mode. As specified in [RFC3775], Route Optimization mode "requires the mobile node to register its current binding at the correspondent node." When the mobile node want to transmit a packet, it also need check whether there is a Binding Update List entry for the destination of the packet, as specified in section 11.3.1 of [RFC3775]. If the mobile node confirms that the correspondent node has a suitable Binding Cache entry, the mobile node may send the packet to the correspondent node in route optimization mode. For the mobile node, which mode to be used depends on whether the correspondent node Binding Update List entry exists or not. [mext-binding-revocation] specifies a binding revocation mechanism, which permit HA/LMA to send Binding Revocation Indication to the MN/MAG, to terminate the MN's mobility session and release the associated resources. The binding revocation mechanism specified in [mext-binding-revocation] is only applied for the binding in Home Agent or Local Mobility Anchor, but can not be applied for the binding in correspondent node. In some cases, the correspondent node also needs the capability to revoke the correspondent binding from the mobile node during a route optimized session. This document is used to introduce the mechanism used by correspondent node to terminate the correspondent node binding in the MN's Binding Update List. 2. Terminology All the general mobility related terminology and abbreviations are to be interpreted as defined in Mobile IPv6 [RFC3775] and [mext-binding- revocation]. Cui Expires May 8, 2010 [Page 4] Internet-Draft CN Binding Revocation November 2009 3. Protocol and Use Case Overview The overview of correspondent node binding revocation procedure is as below: MN HA CN | | | | HoTI | | (a) |--------------------->| HoTI | (b) | |--------------------->| | | HoT | (c) | HoT |<---------------------| (d) |<---------------------| | | | | CoTI | (e) |-------------------------------------------->| | CoT | (f) |<--------------------------------------------| | | | Binding Update | (g) |-------------------------------------------->| | Binding Ack | (h) |<--------------------------------------------| | | | Binding Revocation Indication | (i) |<--------------------------------------------| | Binding Revocation Acknowledgement | (j) |-------------------------------------------->| | | Figure 1 CN binding and revocation. The detailed descriptions are as follows: (a)~(f) Normal Return Routability procedure as specified in [RFC3775]. (g)~(h) Normal Route Optimization binding registration as specified in [RFC3775]. (i) The correspondent node sends the Binding Revocation Indication packet to the mobile node, including the Binding Authorization Data Option in the message. Cui Expires May 8, 2010 [Page 5] Internet-Draft CN Binding Revocation November 2009 (j) The mobile node deletes the correspondent node binding, releases related resource and replies the Binding Revocation Acknowledgement message to the correspondent node. After this step, the Route Optimization mode is released and the Bidirectional Tunneling mode is applied. 4. Correspondent Node Operation To terminate the correspondent node binding in the MN's Binding Update List, the correspondent node sends a packet to the mobile node containing a Binding Revocation Indication as specified in section 7 of [mext-binding-revocation], with the exception as following: o The source address of the packet MUST be set as the IP address of the correspondent node, if the correspondent node is a mobile node the home address of the node MUST be taken as the IP address. o The Binding Authorization Data option, which is specified in section 6.2.7 of [RFC3775], MUST be included in the Binding Revocation Indication packet. Since the communication between the mobile node and the correspondent node is not protected by security association, the sender of the BRI MUST provide the Authorization option. The Binding Management Key specified in [RFC3775], the calculation of the Kbm specified in the section 5.2.5 of [RFC3775] and the calculation of the Authenticator specified in the section 6.2.7 of [RFC3775] are reused in this document. o After the Binding Revocation Indication packet has been sent, the correspondent MUST set a flag in the correspondent Binding Cache entry to indicate the "Revocation Pending" state and stop transmitting any outgoing packets (except retransmitted BRI) destined directly for the mobile node. o In the "Revocation Pending" state the correspondent node MUST accept incoming route optimized packets until the Binding Cache entry is freed. o The correspondent node SHOULD maintain the "Revocation Pending" state until Binding Revocation Acknowledgement has been received or the maximum number of retransmissions have been conducted as specified in section 6.3 of [mext-binding-revocation]. Cui Expires May 8, 2010 [Page 6] Internet-Draft CN Binding Revocation November 2009 o The correspondent node MAY free all resources associated with this mobile node binding in the cases of receiving the Binding Revocation Acknowledgement or finishing the retransmission procedure. o If the correspondent node receives packet containing Home Address option after it has freed the Binding Cache entry and related resource, whether to accept the packet or not depends on the implementation of the correspondent node. This is out of the scope of this document. 5. Mobile Node Operation Upon receiving a packet carrying a Binding Revocation Indication, the mobile node MUST validate the packet according to Section 6.2 of [mext-binding-revocation], with the addition of following tests: o The mobile node MUST verify that the IP address in the Type 2 routing header is its Home Address. If the test fails, the mobile node SHOULD silently discard the received Binding Revocation Indication message. o The mobile node MUST verify the source address of the received Binding Revocation Indication packet. If the mobile node Binding Update List contains an entry for the IP address, the mobile node MUST check the Binding Authorization Data option contained in this packet. If the Authenticator is valid and other tests are verified, the mobile node MUST accept this Binding Revocation Indication. Otherwise the mobile node SHOULD silently discard the received Binding Revocation Indication message. The Binding Management Key specified in [RFC3775], the calculation of the Kbm specified in the section 5.2.5 of [RFC3775] and the calculation of the Authenticator specified in the section 6.2.7 of [RFC3775] are reused in this document. o If the mobile node accepts this Binding Revocation Indication, the mobile node MUST send a successful Binding Revocation Acknowledgement to the correspondent node. Otherwise the mobile node MUST send a rejected Binding Revocation Acknowledgement. o After the mobile node has accepted the Binding Revocation Indication message, the mobile node MAY free the resources related to the correspondent node Binding Update List entry. The mobile node MUST stop transmitting any outgoing packets destined directly for the correspondent node after acknowledgement has been sent. Cui Expires May 8, 2010 [Page 7] Internet-Draft CN Binding Revocation November 2009 o If the mobile node receives packet containing type 2 routing header after it has freed the correspondent node binding, whether to accept the packet or not depends on the implementation of the mobile node. This is out of the scope of this document. [[ Note: This case is also possible in basic MIP6 network. The mobile node maybe receives packet containing type 2 routing header before the Binding Acknowledgement message, because the BA message and route optimized packets are transported disorderly in the IP network.]] 6. Messages and Options TBD. 7. Security Considerations TBD. 8. IANA Considerations This document has no actions for IANA. 9. Acknowledgments The authors would like to thank Mext Working Group for the review, comment and discussion. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Cui Expires May 8, 2010 [Page 8] Internet-Draft CN Binding Revocation November 2009 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [mext-binding-revocation] Ahmad, M., Mohamed, K., Sri, G., Kuntal, C. and Parviz, Y., "Binding Revocation for IPv6 Mobility", October 2009. 10.2. Informative References Author's Addresses Xiangsong Cui Huawei Technologies KuiKe Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, P.R. China, 100085 Email: Xiangsong.Cui@huawei.com Antti Makela Helsinki University of Technology P.O. BOX 3000 FIN-02105 TKK FINLAND Phone: +358 9 451 5590 Email: antti.makela@tkk.fi Cui Expires May 8, 2010 [Page 9]