Network Working Group A. Muhanna Internet-Draft M. Khalil Intended status: Standards Track Nortel Expires: September 25, 2009 S. Gundavelli Cisco Systems K. Chowdhury Starent Networks P. Yegani Juniper Networks March 24, 2009 Binding Revocation for IPv6 Mobility draft-ietf-mext-binding-revocation-04.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 September 25, 2009. 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Muhanna, et al. Expires September 25, 2009 [Page 1] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 to this document. Abstract This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2.1. Conventions used in this document . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 6 3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding Revocation . . . . . . . . . . . . . . . . . . . . . . 8 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 9 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Binding Revocation Messages over IPv4 Transport Network . . . 10 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 10 6.1. Binding Revocation Indication Message . . . . . . . . . . 11 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 14 7. Binding Revocation Process Considerations . . . . . . . . . . 17 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 17 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 18 7.3. Retransmission of Binding Revocation Indication . . . . . 19 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 19 8.1. Sending Binding Revocation Indication . . . . . . . . . . 19 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 20 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 21 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 21 9.1.1. Sending Binding Revocation Indication . . . . . . . . 21 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 23 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 24 9.2.1. Receiving Binding Revocation Indication . . . . . . . 24 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 25 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 26 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 26 Muhanna, et al. Expires September 25, 2009 [Page 2] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 10.1.1. Receiving Binding Revocation Indication . . . . . . . 26 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 28 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 29 10.2.1. Sending Binding Revocation Indication . . . . . . . . 29 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 29 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 30 11.1. Receiving Binding Revocation Indication . . . . . . . . . 30 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 32 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 32 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 16.2. Informative References . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Muhanna, et al. Expires September 25, 2009 [Page 3] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 1. Introduction In the case of Mobile IPv6 and for administrative reason, sometimes it becomes necessary to inform the mobile node that its registration has been revoked and the mobile node is no longer able to receive IP mobility service using its Home Address. A similar Mobile IPv4 registration revocation mechanism [RFC3543] has been specified by IETF for providing a revocation mechanism for sessions that were established using Mobile IPv4 registration [RFC3344]. This document specifies a binding revocation mechanism that can be used to revoke a mobile node's mobility session(s). The same mechanism can be used to revoke bindings created using Mobile IPv6 [RFC3775] or any of its extensions, e.g. Proxy Mobile IPv6 [RFC5213]. The proposed revocation mechanism uses a new MH type for revocation signaling which is applicable to Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used by any two IP mobility entities. As an example, this mechanism allows a local mobility anchor, involved in providing IP mobility services to a mobile node, to notify the mobile access gateway of the termination of a mobile node binding registration. In another example, a mobile access gateway can use this mechanism to notify its local mobility anchor peer with a bulk termination of all or a subset of Proxy Mobile IPv6 bindings that are registered with the local mobility anchor and currently being served by the mobile access gateway. 2. Conventions & Terminology 2.1. 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]. 2.2. Terminology All the general mobility related terminology and abbreviations are to be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] specifications. 3. Binding Revocation Protocol and Use Cases Overview This specification specifies a binding revocation mechanism where a mobility node can communicate to the mobile node or another mobility node the termination of the mobile node registration binding. The following subsections describe the protocol overview and applicable Muhanna, et al. Expires September 25, 2009 [Page 4] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 use cases. 3.1. Binding Revocation Protocol In the case of Mobile IPv6, if the home network decides to terminate the service of the mobile node, the home agent sends a Binding Revocation Indication (BRI) message to the mobile node. The home agent includes the HoA in the Type 2 routing header as specified in [RFC3775] to indicate the impacted mobile node binding. In the case of DSMIPv6 [ID-DSMIP6], the home agent may include the IPv4 Home Address Option with the mobile node assigned home IPv4 address. Additionally, if the mobile node registered multiple care-of addresses [ID-MCoA], the home agent includes the Binding ID option(s) in the Binding Revocation Indication message to identify which binding is being revoked. When the mobile node receives a BRI message with its HoA included in the Type 2 routing header and the Acknowledge (A) bit is set, the mobile node responds by sending a Binding Revocation Acknowledgement (BRA) message. Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation procedure can be initiated by the local mobility anchor by sending a BRI message to communicate the termination of a mobile node registration binding to the mobility access gateway. In this case, the local mobility anchor includes the mobile node Home Network Prefix option [RFC5213] and the MN-ID option [RFC4283] to indicate to the mobility access gateway the identity of the PMIPv6 binding that needs to be terminated. When the mobility access gateway receives the BRI message with the (A) bit set, the mobility access gateway responds to the local mobility anchor by sending a BRA message. On the other hand, the MAG usually sends a de-registration message by sending a Proxy BU with a lifetime of zero to indicate to the LMA of the termination of the PMIPv6 mobile node binding registration. In this case, the MAG includes the MN HNP option, the MN-ID option and all other required mobility options as per [RFC5213] in order for the LMA to identify the mobile node PMIPv6 binding. Additionally, in the case when the mobility access gateway communicates a bulk termination of PMIPv6 sessions, the MAG sends a BRI message with the (G) and (A) bits set and includes the MAG identity in the MN-ID option. When the LMA receives such BRI message, it ensures that the mobility access gateway is authorized to send such bulk termination message and then process the BRI message accordingly. If the local mobility anchor processes the BRI message successfully, the LMA responds to the mobile access gateway by sending the BRA message. In any of the above cases, the initiator of the binding revocation procedure, e.g., HA, LMA, MAG, uses the Revocation Trigger field in the Binding Revocation Indication message to indicate to the Muhanna, et al. Expires September 25, 2009 [Page 5] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 receiving node the reason for initiating the revocation procedure. 3.2. MIPv6 and DSMIP6 Use Case Binding revocation mechanism is applicable to Mobile IPv6 and DSMIPv6 session(s) when the home agent needs to inform the mobile node that its binding registration has been revoked, e.g. for an administrative reason. This mechanism enables the home domain to dynamically allow the user to act upon the revocation message in order to recover its interrupted mobile IPv6 services. In this case, the home agent sends a BRI message to indicate to the mobile node that its current mobile IPv6 binding has been revoked and it no longer can receive IP mobility service. The home agent includes the mobile node home address in Type 2 routing header as used in [RFC3775] and sets the Revocation Trigger field to a proper value, e.g. Administrative Reason. In the case of DSMIPv6 session, the home agent may additionally include the mobile node assigned IPv4 Home Address in the IPv4 Home Address Option. When the mobile node receives the BRI message, it sends a BRA message as described in Section 11.2 to the home agent. Figure 1 illustrates the message sequencing when home agent revokes a mobile node binding registration. MN HA | | | HoA in Type 2 Hdr | |<<<------------... + ...-----------------| | BRI [seq.#, A bit, Revocation Trigger] | | | | | | BRA (HoA in Dest. Option)[seq.#, Status] | |---------------------------------------->>>| | | | | Figure 1: Home Agent Revokes a Mobile Node Binding Registration Muhanna, et al. Expires September 25, 2009 [Page 6] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 3.3. Multi-Care of Addresses (Monami6) Use Case In the case of multiple care-of addresses registration [ID-MCoA], the home agent maintains different binding for each pair of care-of address and home address. These bindings are also indexed and identified during the mobile node registration using a Binding ID mobility option. The HA may revoke one or multiple bindings for the same mobile node home address. If the home agent revokes a single binding for a mobile node with multiple care-of addresses registration, the home agent sends a BRI message to the mobile node with the corresponding BID option included. If more than one of the mobile node registered care-of addresses need to be revoked, the home agent includes all the corresponding Binding ID options in the same BRI message. Figure 2 illustrates the message flow when the HA revokes two registered Care-of addresses for the same MN in a single BRI message. HA Binding Cache ================ MN-BID1 [CoA1+HoA] MN HA MN-BID2 [CoA2+HoA] | | MN-BID3 [CoA3+HoA] | | MN-BID4 [CoA4+HoA] | HoA in Type 2 Hdr | |<----------------- + --------------------| | BRI [seq.#, A bit, BID1, BID4] | | | | | | BRA (HoA in Dest. Option) [seq.#, Status] | |------------------------------------------>| | | | | Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings Additionally, the home agent may revoke all of the mobile node registered bindings, by sending a BRI message without including any BID options while the HoA is included in the Type 2 routing header. Figure 1 illustrates the message flow when the home agent revokes all registered Care-of addresses bindings for a MN in a single BRI message. Muhanna, et al. Expires September 25, 2009 [Page 7] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 3.4. Proxy MIPv6 Use Case Since the Mobile node does not participate in the mobility mechanism in the case of PMIPv6, there are many scenarios where Binding Revocation mechanism is needed to clean resources and make sure that the mobility entities, e.g. MAG and LMA, are always synchronized with respect to the status of the existing proxy mobile IPv6 bindings. The binding revocation mechanism is generic enough that can be used for all Proxy Mobile IPv6 scenarios that follow [RFC5213] and [ID-PMIP6-IPv4] specifications. When the MAG receives a BRI message as in Section 10.1.1, the MAG sends a BRA message to the LMA following the rules described in Section 10.1.2. Similarly, if the LMA receives a BRI message with the (A) bit is set, the LMA responds to the MAG by sending a BRA message. 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding Revocation The local mobility anchor may send a BRI message to the mobile access gateway, hosting a specific proxy mobile IPv6 binding, with the appropriate value in the revocation trigger field to indicate that the mobile node binding has been terminated and the MAG can clean up the applicable resources. When the MAG receives a BRI message, the MAG identifies the respected binding and if the (A) bit was set in the received BRI message, the MAG sends a BRA message to the LMA. In this case, the MAG could send a Router Advertisement message to the MN with the home network prefix lifetime set to zero. As an example, Figure 3, illustrates the message sequence for revoking a mobile node binding at the source MAG during the MN inter- MAG handoff. During the inter-MAG handoff, the mobile node moves from the source MAG to the target MAG. The target MAG sends a PBU with the new care-of-address to the LMA to update the mobile node point of attachment. Since the MN binding at the LMA points to the source MAG and upon receiving the PBU from the target MAG, LMA updates the MN BCE and send a PBA to the target MAG. LMA can send a BRI message with the appropriate revocation trigger value, e.g. inter-MAG handoff - same Access Types, to the source MAG in order to clean up the applicable resources reserved for the specified MN binding. The MAG acknowledges the BRI message by sending a BRA message to indicate the success or failure of the termination of the mobile node binding. The process identified above can also be used by the LMA in scenarios other than the inter-MAG handoff with the proper revocation trigger value to indicate to the peer MAG that a specific proxy mobile IPv6 binding or bindings have been revoked. Muhanna, et al. Expires September 25, 2009 [Page 8] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 oldMAG newMAG LMA | | | | | PBU | | |--------------------------->| | | PBU triggers | | BRI Msg to oldMAG | | | | | PBA | | |<---------------------------| | | | | | | | BRI [seq.#, R. Trigger, P, A bits, NAI] | |<-----------------------------------------| | | | | | | | | | | | | | BRA [seq.#, Status, P bit] | |----------------------------------------->| | | | | | | Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff In addition, the LMA can send a BRI message to indicate that all bindings which are hosted by the peer MAG and registered with the LMA are being revoked by setting the (G) bit as described in Section 9.1.1. 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings The mobile access gateway sends a BRI message with the (G) bit is set to indicate that all mobility bindings which are registered at the LMA and attached to the MAG are being revoked as in Section 10.2.1. When the LMA receives a BRI message with the (G) bit is set from a specified MAG, the LMA checks if the MAG is authorized to use global revocations and responds with the appropriate status code by sending a BRA message as in Section 9.2.2. 4. Security Model The binding revocation protocol described here uses the same security association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and Muhanna, et al. Expires September 25, 2009 [Page 9] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 BA when the mobile node binding was created. If IPsec is used, the traffic selectors associated with the SPD entry protecting BU and BA MUST be extended to include Binding Revocation Signaling MH type . Extending the traffic selectors of the SPD entry in order to reuse the SA protecting BU and BA (instead of creating new ones) ensures that those SA will be up and running when the revoking entity needs to send a binding revocation signaling message. Additionally, in the case when the LMA receives a BRI which indicates a bulk termination where the (G) bit is set and the Revocation Trigger field is set to "Per-Peer Policy", the LMA MUST verify that the MAG sending the binding revocation indication message is authorized to invoke Global revocation. 5. Binding Revocation Messages over IPv4 Transport Network In some deployments, the network between the MAG and the LMA may only support IPv4 transport. In this case, the Binding Revocation messages (BRI and BRA) are tunneled over IPv4. If the Proxy Binding Update and Proxy Binding Acknowledgment messages are sent using UDP encapsulation to traverse NATs, then the Binding Revocation messages are sent using the same UDP encapsulation. The same UDP port that was used for exchanging the Proxy Binding Update and Proxy Binding Acknowledgement messages will also be used when transporting Binding Revocation messages over IPv4 using UDP encapsulation. In other words, the destination UDP port of the BRI message MUST be set to the source UDP port of the latest successfully processed Proxy Binding Update message which is already saved in the mobile node BCE. For more details on tunneling Proxy Mobile IPv6 signaling messages over IPv4, see [ID-PMIP6-IPv4]. 6. Binding Revocation Message This section defines the Binding Revocation Message format using a MH Type as illustrated in Figure 4. The value in the Binding Revocation Type field defines whether the Binding Revocation message is a BRI or BRA. If the Binding Revocation type field is set to 1, the Binding Revocation Message is a Binding Revocation Indication as in Section 6.1. However, if the value is 2, it is a Binding Revocation Acknowledgement message as in Section 6.2. Muhanna, et al. Expires September 25, 2009 [Page 10] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | B.R. Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . Binding Revocation Message Data . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Binding Revocation Message Binding Revocation Type 8-bit unsigned integer. It defines the type of Binding Revocation Message. It can be assigned one of the following values: 0 Reserved 1 Binding Revocation Indication Message 2 Binding Revocation Acknowledgement Message All other values are reserved Binding Revocation Message Data The Binding Revocation Message Data follows the Binding Revocation Message format that is defined in this document for the specified value in the Binding Revocation Type field. It is either a BRI as in Section 6.1 or BRA as in Section 6.2. 6.1. Binding Revocation Indication Message The Binding Revocation Indication (BRI) message is a Binding Revocation Message which has a MH type and a Binding Revocation Type value of 1. It is used by the revoking mobility node to inform the receiving mobility entity that the IP mobility service of a specific binding or bindings have been revoked. Binding Revocation Indication message is sent as described in Section 8.1, Section 9.1.1, and Section 10.2.1. When the value 1 is indicated in the B. R. type field of the Binding Revocation Message, the format of the Binding Revocation Message Data follows the Binding Revocation Indication message as in Figure 5 Muhanna, et al. Expires September 25, 2009 [Page 11] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B.R. Type = 1 | R. Trigger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # |A|P|V|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Binding Revocation Indication Message Revocation Trigger 8-bit unsigned integer indicating the event which triggered the revoking node to send the BRI message. The Reserved and Per-MN Revocation Triggers value are less than 128. The per-MN revocation triggers is used when the BRI message intends to revoke one or more bindings for the same mobile node. The Global Revocation Trigger values are greater than 128 and used in the BRI message with the (G) bit is set for for global revocation. The following Revocation Trigger values are currently defined: Reserved and Per-MN Revocation Trigger: 0 Reserved 1 Unspecified 2 Administrative Reason 3 Inter-MAG Handoff - same Access Types 4 Inter-MAG Handoff - different Access Types 5 Inter-MAG - Unknown Handoff 6 User Initiated Session(s) Termination 7 Access Network Session(s) Termination 8 IPv4 HoA Lease Expires 9 Possible Out-of Sync BCE State 250-255 Reserved For Testing Purposes only All other values are Reserved Global Revocation Trigger: Muhanna, et al. Expires September 25, 2009 [Page 12] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 128 Per-Peer Policy 129 Revoking Mobility Node Local Policy Sequence # A 16-bit unsigned integer used by the sending mobility node to match a returned Binding Revocation Acknowledgement with this Binding Revocation Indication. It could be a random number. Acknowledge (A) The Acknowledge (A) bit is set by the sending mobility node, e.g. LMA, HA, or MAG, to request a Binding Revocation Acknowledgement be returned upon receipt of the Binding Revocation Indication as in Section 8.1, Section 9.1.1, and Section 10.2.1. Proxy Binding (P) The Proxy Binding (P) bit is set by the sending mobility node to indicate that the revoked binding(s) is a proxy MIPv6 binding. IPv4 HoA Binding Only (V) The IPv4 HoA Binding Only (V) bit is set by the sending mobility node, HA or LMA, to request the receiving mobility entity the termination of the IPv4 Home Address binding only as in Section 8.1, and Section 9.1.1. Global (G) The Global (G) bit is set by the sending mobility node, LMA or MAG, to request the termination of all Per-Peer mobility Bindings or Multiple Bindings which share a common identifier that are served by the sending and receiving mobility entities as in Section 9.1.1 and Section 10.2.1. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. This document does not define any new mobility option. The receiver MUST ignore and skip any options which it does not understand. These mobility Muhanna, et al. Expires September 25, 2009 [Page 13] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 option(s) are used by the receiving mobility entity to identify the specific binding or bindings that the sending mobility entity requesting to be revoked. The following options are valid in a Binding Revocation Indication: o Home Network Prefix option [RFC5213]. This option MAY be used when the (P) bit is set. This option MUST be present when the BRI is used to revoke a single PMIP binding cache entry. o Mobile Node Identifier Option [RFC4283]. This option is mandatory when the (P) bit is set. Additionally, if the (G) bit is set by the mobile access gateway, this option carries the MAG identity. o Binding ID mobility option [ID-MCoA]. This option is mandatory if the sending mobility entity request to terminate one binding of a multi care-of addresses bindings for the same mobile node. The sending mobility entity may include more than one of the Binding ID mobility options. o IPv4 Home Address option which contains the mobile node home IPv4 address [ID-DSMIP6]. This option is included only when the IPv4 HoA Binding only (V) bit is set. o Alternate Care-of Address mobility option [RFC3775]. This option MAY be included to indicate the Care-of Address of the mobile node's binding that is being revoked. In the case when the Global (G) bit set, this option identifies all the mobility bindings that share the same care-of address. Additionally, if the Global (G) bit set, more than one Alternate Care-of Address mobility options MAY be present in the BRI message. If no options are present in this message, 4 octets of padding are necessary and the Header Len field of the Binding Revocation Message will be set to 1. 6.2. Binding Revocation Acknowledgement Message The Binding Revocation Acknowledgement (BRA) message is a Binding Revocation Message which has a MH type and a Binding Revocation Type value of 2. It is used to acknowledge the receipt of a Binding Revocation Indication message described in Section 6.1. This packet is sent as described in Section 9.2.2, Section 10.1.2, and Section 11.2. When the value 2 is indicated in the Binding Revocation type field of the Binding Revocation Message, the format of the Binding Revocation Message Data follows the Binding Revocation Acknowledgement message Muhanna, et al. Expires September 25, 2009 [Page 14] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 as in Figure 6 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B.R. Type = 2 | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # |P|V|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Binding Revocation Acknowledgement Message Status 8-bit unsigned integer indicating the result of processing the Binding Revocation Indication message by the receiving mobility entity. Values of the Status field less than 128 indicate that the Binding Revocation Indication was processed successfully by the receiving node. Values greater than or equal to 128 indicate that the Binding Revocation Indication was rejected by the receiving node. The following status values are currently defined: 0 success 1 partial success 128 Binding Does NOT Exist 129 IPv4 HoA Binding Does NOT Exist 130 IPv4 Home Address Option Required 131 Global Revocation NOT Authorized 132 CAN NOT Identify Binding 133 Revocation Failed - MN is Attached 134 Revocation Trigger NOT Supported 135 Revocation Function NOT Supported Muhanna, et al. Expires September 25, 2009 [Page 15] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 Sequence # The sequence number in the Binding Revocation Acknowledgement is copied from the Sequence Number field in the Binding Revocation Indication. It is used by the revoking mobility entity, e.g. HA, LMA, MAG, in matching this Binding Revocation Acknowledgement with the outstanding BRI. Proxy Binding (P) The Proxy Binding (P) bit is set if the (P) bit is set in the corresponding Binding Revocation Indication message. IPv4 HoA Binding Only (V) The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in the corresponding BRI message. Global (G) The Global (G) bit is set if the (G) bit is set in the corresponding BRI message. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. In the case when the Status field is set to success, no mobility option is required. The mobility option(s) is usually used to communicate information of the bindings that failed the revocation procedure. The following mobility options are valid in a Binding Revocation Acknowledgement: o Home Network Prefix option [RFC5213]. This option MAY be included when the (P) bit is set. o Mobile Node Identifier Option [RFC4283]. This option MAY be included when the (P) bit is set. This option SHOULD be included if the Home Network Prefix option is included. Muhanna, et al. Expires September 25, 2009 [Page 16] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 o Binding ID mobility option [ID-MCoA]. This option MAY be included to indicate the specific Binding ID that the receiving node failed to revoke. If no options are present in this message, 4 octets of padding are necessary and the Header Len field of the Binding Revocation Message will be set to 1. 7. Binding Revocation Process Considerations The following subsections describe the details of the binding revocation generic process by the different mobility entities. 7.1. Sending Binding Revocation Messages When sending a Binding Revocation message, the sending mobility node, initiator, constructs the packet as it would any other Mobility Header with the exception of setting the MH Type field to . The mobility entity which initiates the revocation process MUST use the underlying security association, e.g., IPsec SA, that has been used to secure the mobile node binding registration signaling in securing the BRI and BRA messages transmission with the responding mobility entity. When a mobility entity initiate the binding revocation process by sending a Binding Revocation Indication message, the initiator MUST construct the BRI message as described in Section 6.1. In the BRI message, the initiator MUST set the Sequence Number field to the next sequence number available for Binding Revocation. Since sending BRI messages is not done on a regular basis, a 16 bit sequence number field is large enough to allow the initiator to match the BRA to the outstanding BRI with (A) bit set using the sequence number field only. However, when the responder acknowledges the BRI message by sending a BRA, the responder MUST construct the Binding Revocation Acknowledgement as described in Section 6.2. In this case, the responder MUST set the Sequence Number field by copying the value from the Sequence Number field of the received Binding Revocation Indication. Additionally, it MUST set the status field to a valid value that reflects the processing of the received Binding Revocation Indication. Muhanna, et al. Expires September 25, 2009 [Page 17] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 7.2. Receiving Binding Revocation Messages When receiving a Binding Revocation message, the receiving mobility node MUST verify the Mobility Header as described in section 9.2. of [RFC3775]. If the packet is dropped due to failing any of the Mobility Headers test check, the receiving node MUST follow the processing rules as in Section 9.2 of [RFC3775]. If the receiving node does not support the Binding Revocation Indication message and does not recognize the new MH type, it sends a Binding Error message with the Status field set to 2 as described in [RFC3775]. Since some mobility entities, e.g., LMA and MAG, are allowed to receive and possibly send a BRI or BRA for different cases, therefore, if IPsec is used to secure signaling between the MAG and the LMA, it prevents any possible man in the middle reflection attack. Upon receiving a packet carrying a Binding Revocation Indication, the receiving mobility entity, responder, validates that the packet was received protected with the security association that already has been established with the mobility entity, initiator, and used during the registration signaling phase, e.g., IPsec SA. Upon receiving a packet carrying a Binding Revocation Acknowledgement, the receiving mobility entity, initiator, MUST validate that Sequence Number field matches the Sequence Number of an outstanding Binding Revocation Indication that was sent by the initiator. If the Sequence Number does not match any sequence number of any of the outstanding BRI, the receiving node MUST silently discard the message but MAY log the event. If a mobility node receives a Binding Revocation Indication message with the Revocation Trigger field is set to a value that NOT supported, the receiving mobility node SHOULD reject the BRI message by sending a BRA message with the status field set to "Revocation Trigger NOT Supported". If a mobility node receives a Binding Revocation Indication message with a Revocation Trigger value that is NOT in line with the BRI message intent, e.g., the Global Revocation (G) bit set and the Revocation Trigger field vale is a per-MN specific, the receiving mobility node SHOULD reject the BRI message by sending a BRA message with the status field set to "Revocation Function NOT Supported". Muhanna, et al. Expires September 25, 2009 [Page 18] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 7.3. Retransmission of Binding Revocation Indication If the sending mobility entity does not receive a Binding Revocation Acknowledgement in response to the outstanding Binding Revocation Indication before the MINDelayBRIs timer expires, the mobility entity, e.g. LMA, may retransmit the same BRI message up to the BRIMaxRetriesNumber as defined in Section 12. If the revoking mobility entity does not receive a BRA message after the maximum number of retransmits have been sent, the revoking mobility entity can clean the mobile node binding cache and all resources associated with this binding. The revoking mobility entity may log the event. 8. Home Agent Operation 8.1. Sending Binding Revocation Indication To terminate a mobile node registration and its current binding with the home agent, the home agent sends a packet to the mobile node containing a Binding Revocation Indication, with the packet constructed as follows: o The Acknowledge (A) bit MAY be set in the BRI to request the mobile node to send a Binding Revocation Acknowledgement upon receipt of the BRI. o The Revocation Trigger field MUST be set in the Binding Revocation Indication to indicate to the mobile node the reason for revoking its IP mobility binding with the home agent. The Revocation Trigger may be used by the mobile node to take further steps if necessary. o The Binding Revocation Indication MUST be sent using a Type 2 routing header which contains the mobile node's registered IPv6 home address for the binding being revoked. o The care-of address for the binding MUST be used as the destination address in the packet's IPv6 header, unless an Alternate Care-of Address mobility option is included in the Binding Revocation Indication. o If the home agent needs to only revoke the mobile node's IPv4 home address binding, the home agent MUST set the IPv4 HoA Binding Only (V) bit and MUST include the mobile node's registered IPv4 home address that is being revoked in the IPv4 Home Address option. The Acknowledge (A) bit in the Binding Revocation Indication requests Muhanna, et al. Expires September 25, 2009 [Page 19] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 the mobile node to return a Binding Revocation Acknowledgement in response to this Binding Revocation Indication. As described in Section 7.3, the home agent SHOULD retransmit this Binding Revocation Indication to the mobile node before terminating its IP connection until it receives a matching Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber has been reached. When the home agent sends a BRI to the mobile node with the (A) bit set, the home agent sets a flag in the mobile node BCE to indicate that revocation is in progress and starts the MINDelayBRIs timer. The home agent maintains the mobile node BCE in this state until it receives a Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is reached. In a race condition case, the home agent may receive a BU from the mobile node while the mobile node's BCE has the revocation in progress flag set, the home agent SHOULD handle this case based on the reason for sending the Binding Revocation Indication message and its local policy. In this case, if the home agent accepts the BU, it needs to update the mobile node BCE accordingly, e.g. removing the revocation in progress flag. When the home agent needs to revoke one or more of a mobile node bindings that were created using Multi Care-of address registration as in [ID-MCoA], the home agent MUST include all the related Binding ID options that identify these bindings in the Binding Revocation Indication message. In the case when the home agent needs to revoke all of the mobile node bindings, the home agent MUST NOT include any of the Binding ID options. 8.2. Receiving Binding Revocation Acknowledgement When the home agent receives a packet carrying a valid BRA that was successfully processed as in Section 7.2, the home agent SHOULD examine the Status field as follows: o If the Status field indicates that the Binding Revocation Indication was processed successfully, the home agent deletes the MINDelayBRIs timer and the mobile node bindings and all related resources. o If the Status field indicates any value other than success, the home agent SHOULD examine any mobility options included in the Binding Revocation Acknowledgement. The home agent MAY log the appropriate event to reflect the status of the received BRA. Muhanna, et al. Expires September 25, 2009 [Page 20] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 9. Local Mobility Anchor Operation 9.1. Binding Revocation Initiator 9.1.1. Sending Binding Revocation Indication To terminate a mobile node proxy mobile IPv6 registration and its current PMIPv6 binding with the local mobility agent, the LMA sends a packet to the MAG containing a BRI message following the procedure in Section 7.1 and the following rules: o The Acknowledge (A) bit MAY be set in the Binding Revocation Indication to request the mobile access gateway to send a Binding Revocation Acknowledgement upon receipt of the BRI. o The Proxy Mobile IP (P) bit MUST be set in the BRI message to indicate that the binding being revoked is a proxy Mobile IPv6 binding. o The Revocation Trigger field MUST be set in the Binding Revocation Indication to indicate to the mobile access gateway the reason for removing the specified mobile node proxy mobile IPv6 binding at the LMA. The Revocation Trigger may be used by the mobile access gateway to learn the mobile node's latest movement. o In case of revoking all Per-Peer bindings, the Global (G) bit MUST be set and the Revocation Trigger MUST contain a value of "Per- Peer Policy" in the Binding Revocation Indication to request the mobile access gateway to remove all Per-Peer bindings that are registered with the LMA and hosted at this MAG. o Whenever the Global (G) bit is set in the BRI, the Acknowledge (A) bit MUST be set to request the mobile access gateway to send a Binding Revocation Acknowledgement upon receipt of the BRI. o The packet MUST contain the Mobile Node Identifier, MN-ID, option which contains the mobile node's NAI that was used in the proxy Binding Update during the mobile node registration. o If the Mobile Node Identifier, MN-ID, is registered in more than one of the mobile node's BCE and the LMA does NOT need to revoke all of the mobile node's bindings, the packet MUST contain another identifier to uniquely identify the mobile node binding(s) that is being revoked, e.g., at least one Home Network Prefix option which contains the mobile node's registered HNP for the binding being revoked. Muhanna, et al. Expires September 25, 2009 [Page 21] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 o The care-of address for the binding MAY be used as the destination address in the packet's IPv6 header, unless an Alternate Care-of Address mobility option is included in the Binding Revocation Indication message. The Acknowledge (A) bit in the Binding Revocation Indication requests the mobile access gateway to return a Binding Revocation Acknowledgement in response to this Binding Revocation Indication. As described in Section 7.3, the LMA SHOULD retransmit this BRI to the MAG before deleting the mobile node IP tunnel to the mobile access gateway until it receives a matching Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is reached. The local mobility anchor MAY delete the mobile node(s) IP tunnel immediately after sending the Binding Revocation Indication and before receiving the BRA message. When the local mobility anchor sends a Binding Revocation Indication to the mobile access gateway to remove a specific binding and the Acknowledge (A) bit is set in the BRI, the local mobility anchor sets a flag in the mobile node proxy BCE to indicate that revocation is in progress and starts the MINDelayBRIs timer. The local mobility anchor SHOULD maintain the mobile node proxy BCE in this state until it receives a Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is reached. In the case when the local mobility anchor sets the Revocation Trigger field to a value which indicate inter-MAG handover, the local mobility anchor MAY switch the mobile node IP tunnel to the target mobile access gateway before sending a Binding Revocation Indication to the sources mobile access gateway. In a race condition case, the local mobility anchor may receive a PBU from the mobile access gateway while the mobile node's proxy BCE has the revocation in progress flag set, the LMA should handle this case based on the reason for sending the Binding Revocation Indication message and its local policy. In this case, if the LMA accepts the PBU, it needs to update the mobile node proxy BCE accordingly, e.g. removing the revocation in progress flag. When the local mobility anchor needs to revoke all mobile nodes proxy BCE that are registered with the local mobility anchor and hosted at the mobile access gateway, the LMA MUST set the Global (G) bit and the value of the Revocation Trigger field to "Per-Peer Policy". In this case, the LMA MUST NOT include any mobility options in the BRI. When the LMA needs to revoke all mobile nodes proxy BCE that belong to a specific realm, e.g. @companyabc.com, and are registered with the LMA and hosted at the MAG, the local mobility anchor MUST set the Muhanna, et al. Expires September 25, 2009 [Page 22] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 Global (G) bit and the value of the Revocation Trigger field to "Revoking Mobility Node Local Policy". In this case, the local mobility anchor MUST include a mobility option to identify the impacted bindings, e.g. MN-ID option with a wildcard NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs that need to be removed. When the mobile node is registered with multiple Home Network Prefixes for the same proxy care-of address, the local mobility anchor SHOULD include a HNP option for each registered HNP in the BRI. Alternatively, the LMA MAY include only the mobile node identifier, MN-ID, option in the BRI to indicate to the mobile access gateway to remove all bindings of the specified mobile node NAI in the MN-ID option. When the mobile node is registered with an IPv4 proxy home address in addition to the Home Network Prefix where both of the IPv4 pHoA and HNP are bound to the same proxy CoA, the local mobility anchor MAY revoke the mobile node IPv4 proxy HoA binding to the current mobile node proxy CoA while maintaining the mobile node binding of the HNP to its current pCoA as part of the mobile node BCE. In this case, if the LMA decides to revoke the mobile node IPv4 proxy HoA ONLY, the LMA MUST send a BRI message following the procedure in Section 7.1 and the following rules: o The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to indicate that only the IPv4 home address binding is being revoked. o The Acknowledge (A) bit MUST be set in the BRI to request the MAG to send a BRA message. o The IPv4 Home Address option MUST be included with the mobile node's registered IPv4 home address that is being released in addition to the MN-ID option. o The mobile node Home Network Prefix option MUST NOT be included. o The Revocation Trigger field MUST be set to an appropriate value, e.g. "IPv4 Address Lease Expired". 9.1.2. Receiving Binding Revocation Acknowledgement When the local mobility anchor receives a packet carrying a valid Binding Revocation Acknowledgement that was successfully processed as in Section 7.2 and if the mobile node BCE is in the state of Revocation in progress, the local mobility anchor SHOULD examine the Status field before clearing the mobile node related resources as Muhanna, et al. Expires September 25, 2009 [Page 23] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 follows: o If the Status field indicates that the BRI was processed successfully, the local mobility anchor delete the MINDelayBRIs timer and the mobile node proxy bindings and all associated resources. o If the Status field indicates partial success value or MN binding does not exist, the local mobility anchor SHOULD examine mobility options that are included in the Binding Revocation Acknowledgement, if any, before deleting the MINDelayBRIs timer and the mobile node associated proxy bindings and all related resources. It is based on the LMA local policy how to handle the mobile node BCE(s) that the mobile access gateway indicated it failed the revocation procedure, however, the LMA MAY log the event. 9.2. Binding Revocation Responder 9.2.1. Receiving Binding Revocation Indication When the local mobility anchor receives a packet carrying a Binding Revocation Indication that was successfully processed as in Section 7.2, the local mobility anchor SHOULD in addition process the message as follows: o Binding Revocation Indication is formatted as in Section 6.1 and if the (P) bit is set, the local mobility anchor MUST validate that all impacted binding(s) have the proxy binding flag set. o If the Global (G) bit is set and the Revocation Trigger value is "Per-Peer Policy", the Proxy (P) bit MUST be set and the BRI SHOULD contain the mobile access gateway ID in the MN-ID option. The local mobility anchor MUST verify that the identified mobile access gateway as per the value in the MN-ID option is authorized to use the Global revocation. The mechanism the LMA uses to verify the MAG authorization is out of scope of this document. o If the Global (G) bit is set and the Revocation Trigger value is "Per-Peer Policy", and only the mobile node identifier, MN-ID, option is included, the local mobility anchor MUST revoke all mobile nodes bindings which proxy CoA is the one used as the source of the IPv6 packet that carried the BRI. However, if one or more Alternate Care-of Address options are included in addition to the mobile node identifier option in the BRI message, the local mobility anchor MUST revoke all mobile nodes bindings which proxy Care-of Address matches one of the Care-of address(es) in the Muhanna, et al. Expires September 25, 2009 [Page 24] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 Alternate Care-of Address option(s). o If the Global (G) bit is set and the Revocation Trigger value is "Per-Peer Policy", and the mobile node identifier, MN-ID, option is NOT included, the local mobility anchor MUST reject the BRI message by sending a BRA message with the status field is set to "Global Revocation Authorization Required". o The LMA identifies all impacted mobile nodes bindings and if the Acknowledgement (A) bit is set, the local mobility anchor MUST send a Binding Revocation Acknowledgement following Section 9.2.2 using the appropriate status code. o If the Global (G) bit is NOT set, the local mobility anchor SHOULD use the included mobility options to identify the impacted mobile node binding as follows: 1. If only the mobile node identifier, MN-ID, option is included, the local mobility anchor MUST revoke all bindings for this mobile node which use the specified mobile node NAI. 2. If the mobile node identifier, MN-ID, and the Home Network Prefix option are included, the local mobility anchor MUST only remove the specified proxy binding. 3. If the mobile node identifier, MN-ID, option and more than one Home Network Prefix options are included, the local mobility anchor MUST remove all bindings which are referenced by these multiple Home Network Prefixes for the specified mobile node NAI. The Revocation Trigger field value in the received Binding Revocation Indication could be used by the local mobility anchor to log an event or update some local parameters which tracks the state of the peer mobile access gateway. 9.2.2. Sending Binding Revocation Acknowledgement When the local mobility anchor receive a valid Binding Revocation Indication with the (A) bit set and after processing the BRI message, the local mobility anchor sends a packet to the mobile access gateway containing a Binding Revocation Acknowledgement following the process in Section 7.1 and the following: o If the (P) bit was set in the received Binding Revocation Indication, the local mobility anchor MUST set the (P) bit in the BRA. Muhanna, et al. Expires September 25, 2009 [Page 25] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 o If the Global (G) bit was set in the received BRI, the local mobility anchor MUST set the (G) bit in the Binding Revocation Acknowledgement. o If the IPv4 HoA Binding Only (V) bit was set in the received BRI, the local mobility anchor MUST set the (V) bit in the Binding Revocation Acknowledgement. o The local mobility anchor MUST set the status field to a valid code that reflects the processing of the received Binding Revocation Indication. If the mobile access gateway is not authorized to use the Per-Peer Global revocation feature, the LMA MUST set the status field to (Global Revocation NOT Authorized). o In the case that one of the bindings identified in the received BRI message has already been released before receiving the BRI, the LMA MAY set the status field to partial success and in this case it MAY include the mobile node identifier or the Home Network Prefix option to identify the binding(s) that failed revocation. o The destination IP address of the IPv6 packet of the Binding Revocation Acknowledgement is set to the source IP address of the received BRI. 10. Mobile Access Gateway Operation 10.1. Binding Revocation Responder 10.1.1. Receiving Binding Revocation Indication Upon receiving a packet carrying a Binding Revocation Indication, the mobile access gateway MUST validate the packet according to Section 7.2 and the following: o BRI MUST be formatted as in Section 6.1 and the (P) bit is set. o If the Acknowledgement (A) bit in the received BRI is set, the mobile access gateway MUST send a Binding Revocation Acknowledgement following Section 10.1.2 using the appropriate status value. o If the Global (G) bit is set and the Revocation Trigger field is set to "Per-Peer policy", the mobile access gateway identifies all bindings that are registered at the LMA and hosted at the MAG. This Binding Revocation Indication does not include any other mobility options. In this case, the MAG MUST send a BRA with the appropriate status code to the LMA. Muhanna, et al. Expires September 25, 2009 [Page 26] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 o If the Global (G) bit is set and the Revocation Trigger field is set to "Revoking Mobility Node Local Policy", the MAG MUST identify all bindings that are registered at the LMA and hosted at the MAG using the mobility option(s) included in the BRI. This Binding Revocation Indication SHOULD include at least the MN-ID option, e.g. with a wild card NAI. In this case, the MAG MUST send a BRA with the appropriate status code to the LMA. o If the Global (G) bit is set and the Revocation Trigger field is set to "Revoking Mobility Node Local Policy", and no mobility options are included in the Binding Revocation Indication message or the MAG is not able to identify the impacted mobile nodes bindings based on the included mobility options, the MAG MUST treat this as an error scenario. In this case, the MAG SHOULD send a Binding Revocation Acknowledgement message with status "CAN NOT Identify Binding". o If the Revocation Trigger field value in the received Binding Revocation Indication message indicates an inter-MAG handover and the (A) bit is set, the MAG use the mobility option(s) included in the BRI message to identify the mobile node binding. The mobile access gateway MAY validate that the mobile node is no longer attached to the mobile access gateway before sending a successful Binding Revocation Acknowledgement message to the LMA. However, if the Revocation Trigger field is set to "Inter-MAG - Unknown Handoff" or "Possible Out-of Sync BCE State" and the (A) bit is set, the MAG MUST validate that the mobile node is no longer attached to the MAG before sending a successful BRA message and deleting the resources associated with the mobile node binding. Otherwise, if the MAG verified that the MN is still attached, the MAG MUST set the status field in the BRA to "Revocation failed - MN is attached". o If the IPv4 HoA Binding Only (V) bit in the received BRI message is set, the MAG uses the MN-ID option to identify the mobile node binding entry in the BUL. The MAG MUST verify that the IPv4 address included in the IPv4 Home Address option in the received BRI is the same as the IPv4 proxy HoA that is assigned to the mobile node. After the MAG successfully validates the received IPv4 home address as the mobile node IPv4 HoA, the MAG MUST consider this as an indication to release the mobile node IPv4 proxy HoA binding to the mobile node current proxy CoA ONLY. Consequently, the MAG MUST continue to maintain the mobile node IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA as part of the mobile node binding in the BUL entry and release all resources associated with the MN IPv4 proxy HoA binding to the MN pCoA. In this case, the MAG MUST send a BRA message with the status field is set to success. On the other hand, if the MAG is Muhanna, et al. Expires September 25, 2009 [Page 27] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 able to identify the mobile node binding using the MN-ID but failed to identify the received IPv4 proxy HoA, the MAG MUST send a BRA with status field is set to "IPv4 HoA Binding Does NOT Exist". The Revocation Trigger field value in the received BRI could be used by the mobile access gateway to define what actions the MAG could do to inform the mobile node that its IP connectivity to the current HNP has been terminated, e.g., if the Revocation Trigger field is set to "Administrative Reason", the mobile access gateway may send a RA message after setting the Home Network Prefix lifetime to zero. 10.1.2. Sending Binding Revocation Acknowledgement When the mobile access gateway receive a valid Binding Revocation Indication with the (A) bit set and after processing the BRI message, the mobile access gateway sends a packet to the local mobility anchor containing a Binding Revocation Acknowledgement according to the procedure in Section 7.1 and the following: o The mobile access gateway MUST set the (P) bit in the Binding Revocation Acknowledgement if it is set in the received BRI. o If the Global (G) bit was set in the received BRI, the mobile access gateway MUST set the (G) bit in the Binding Revocation Acknowledgement. o If the IPv4 HoA Binding Only (V) bit was set in the received BRI, the mobile access gateway MUST set the (V) bit in the Binding Revocation Acknowledgement. o The mobile access gateway MUST set the status field to a valid code that reflects the processing of the received Binding Revocation Indication. o In the case that one or more of the bindings identified in the received BRI message has already been released before receiving the BRI, the mobile access gateway MAY set the status field to partial success and in this case it MAY include the mobile node identifier, MN-ID, or the Home Network Prefix option to identify the binding(s) that failed to be removed as part of the revocation procedure. o The destination IP address of the IPv6 packet of the Binding Revocation Acknowledgement is set to the source IP address of the received Binding Revocation Indication. Muhanna, et al. Expires September 25, 2009 [Page 28] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 10.2. Binding Revocation Initiator 10.2.1. Sending Binding Revocation Indication The mobile access gateway could send a Binding Revocation Indication message to indicate the termination of multiple mobile node bindings, e.g., when using the global revocation with the Global (G) bit set. In this case when an event occurs which requires the mobile access gateway to inform the LMA to terminate all mobile nodes bindings that are registered at the local mobility anchor and the mobile access gateway, the mobile access gateway sends a Binding Revocation Indication message following Section 7.1 and the following: o The Acknowledge (A) bit MUST be set in the Binding Revocation Indication to request the local mobility anchor to send a Binding Revocation Acknowledgement upon receipt of the BRI. o The Proxy Mobile IP (P) bit MUST be set in the Binding Revocation Indication to indicate that bindings that being revoked is a proxy Mobile IPv6 binding. o The Global (G) bit MUST be set and the Revocation Trigger contains a value of "Per-Peer Policy" in the Binding Revocation Indication to request the LMA to remove all Per-Peer bindings that are registered with the LMA and hosted at this MAG. In this case, the MN-ID option MUST be included in the BRI and contains the mobile access gateway identity. In this case the mobile access gateway MAY include one or more Alternate Care-of Address option(s). The Alternate Care-of Address option(s) include the proxy Care-of address(es) which their bindings are being impacted by this BRI message. o The mobile access gateway address MAY be used as the Source Address in the packet's IPv6 header. The Acknowledge (A) bit in the Binding Revocation Indication requests the local mobility anchor to return a BRA in response to this Binding Revocation Indication. As described in Section 7.3, the mobile access gateway SHOULD retransmit this BRI to the local mobility anchor until it receives a matching BRA or the BRIMaxRetransmitNumber is reached. The mobile access gateway MAY delete the mobile nodes IP tunnels immediately after sending the Binding Revocation Indication before receiving a BRA message from the LMA. 10.2.2. Receiving Binding Revocation Acknowledgement When the mobile access gateway receives a packet carrying a valid Binding Revocation Acknowledgement that was successfully processed Muhanna, et al. Expires September 25, 2009 [Page 29] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 according to Section 7.2, the mobile access gateway MUST process the BRA as per the followings: o When the mobile access gateway receives a packet carrying a valid Binding Revocation Acknowledgement and the Global (G) and Proxy MIPv6 (P) bits are set and the mobile nodes BCEs are in the state of Revocation in Progress, the mobile access gateway SHOULD examine the Status field as follows: o If the Status field indicates that the Binding Revocation Indication was processed successfully, the mobile access gateway delete the MINDelayBRIs timer and the mobile nodes proxy bindings and all associated resources. o If the Status field indicates (Global Revocation NOT Authorized), the mobile access gateway is not authorized to participate in a Per-Peer Global Revocation. The mobile access gateway SHOULD NOT retry sending a Binding Revocation Indication with the Global (G) bit is set to the same local mobility agent. The mobile access gateway should raise an alarm or log an event to indicate this rejection. 11. Mobile Node Operation 11.1. Receiving Binding Revocation Indication Upon receiving a packet carrying a Binding Revocation Indication, the mobile node MUST validate the packet according to Section 7.2 and the following tests: o The mobile node MUST verify that the IP address in the type 2 routing header is its Home Address and that its Binding Update List contains an entry for that Home Address. If one of the tests, fails the mobile node SHOULD silently discard the received BRI message. o If the Acknowledgement (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the (A) bit is set in the BRI, the mobile node SHOULD send a Binding Revocation Acknowledgement. In all cases, the mobile node MUST follow Section 11.2 and send a BRA using the appropriate status code. Muhanna, et al. Expires September 25, 2009 [Page 30] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 o If the IPv4 HoA Binding Only (V) bit is set in the received BRI message, the MN MUST verify that there is an IPv4 Home Address option in the received BRI and the IPv4 address included in the IPv4 Home Address option is the same as its IPv4 HoA that is assigned to the mobile node. If this verification is successful, the MN MUST consider this BRI as an indication to release the mobile node IPv4 HoA binding ONLY to its current Care-of Address. Consequently, the MN MUST continue to maintain its IPv6 HoA binding to the current CoA as part of the mobile node binding in the BUL entry and release all resources associated with the MN IPv4 HoA binding. In this case, the MN MUST send a BRA message with the status field is set to success. On the other hand, if the IPv4 Home Address Option was NOT included in the received BRI with the (V) bit set, the MN SHOULD send a BRA message with the status field set to "IPv4 Home Address Option Required". Additionally, if the IPv4 HoA received in the IPv4 Home Address Option is NOT the one assigned to the MN, the MN SHOULD send a BRA with the status field set to "IPv4 HoA Binding Does NOT Exist". o The mobile node MUST verify that the (P) bit in the Binding Revocation Indication is NOT set. If the (P) bit is set, the mobile node MUST silently discard the Binding Revocation Indication message. o If the mobile node has registered multiple care-of addresses with its home agent, the mobile node MUST verify which binding is being revoked by examining the content of the BRI message. If the mobile node received a Binding Revocation Indication with a single or more than one Binding ID options and its home address is included in the type 2 routing header, the mobile node MUST consider all of the care-of address(es) binding(s), identified in the Binding ID options, with this home address are being revoked. o If the mobile node has multi Care-of Addresses bindings with its home agent and received a Binding Revocation Indication, without any Binding ID option included and its home address was included in the type 2 routing header, the mobile node MUST consider all of its registered care-of addresses bindings with this home address are being revoked. The Revocation Trigger field value in the received Binding Revocation Indication could be used by the mobile node to define what action the mobile node could do to be able to register again and receive its IP mobility service, e.g. contacting its home operator. Muhanna, et al. Expires September 25, 2009 [Page 31] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 11.2. Sending Binding Revocation Acknowledgement When the mobile node receives a Binding Revocation Indication from its home agent, the mobile node processes the received BRI as in Section 11.1. If the mobile node is required to send a BRA message in response to the received BRI, the mobile node sends a packet to its home agent containing a Binding Revocation Acknowledgement according to the procedure in Section 7.1 and the following: o The mobile node MUST set the status field to an appropriate value. The mobile node sets the status field to success to reflect that it has received the Binding Revocation Indication and acknowledge that its IP connectivity with its home agent has been revoked. o The destination IP address of the IPv6 packet of the Binding Revocation Acknowledgement is set to the source IP address of the received IPv6 packet of the Binding Revocation Indication. The Mobile Node MUST include its home address in the Home Address Destination Option. 12. Protocol Configuration Variables Any mobility entity which is allowed to invoke the binding revocation procedure by sending a Binding Revocation Indication message SHOULD allow the following variables to be configured. BRI Maximum Number of Retries (BRIMaxRetriesNumber) This variable specifies the maximum Number of times a mobility entity can retransmit a Binding Revocation Indication message before receiving a Binding Revocation Acknowledgement message. The default value for this parameter is 1. Minimum Delay Between BRI messages (MINDelayBRIs) This variable specifies the delay time in seconds before the revoking mobility entity retransmits a BRI message. The default is 1 second but not less than 0.5 seconds. 13. IANA Considerations This document defines a new Binding Revocation Message using a new Mobility Header Type , as described in Section 6. The new Mobility Header type value needs to be assigned from the same numbering space as allocated for the other Mobility Header types. Muhanna, et al. Expires September 25, 2009 [Page 32] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 This document also creates a new name space "Binding Revocation Type" which indicates the type of the binding revocation message. The current binding revocation message types are described in Section 6.1 and Section 6.2, and are the following: 0 Reserved 1 Binding Revocation Indication 2 Binding Revocation Acknowledgement All other values are reserved Future values of the Binding Revocation Type can be allocated using Standards Action or IESG Approval [RFC2434]. In addition, this document also creates a second new namespace for the Binding Revocation Trigger which indicates the reason behind sending the Binding Revocation Indication message. The current Binding Revocation Trigger values are described in Section 6.1, and are the following: Reserved and Per-MN Revocation Trigger Values: 0 Reserved 1 Unspecified 2 Administrative Reason 3 Inter-MAG Handoff - same Access Types 4 Inter-MAG Handoff - different Access Types 5 Inter-MAG - Unknown Handoff 6 User Initiated Session(s) Termination 7 Access Network Session(s) Termination 8 IPv4 HoA Lease Expires 9 Possible Out-of Sync BCE State 250-255 Reserved For Testing Purposes only All other values are Reserved Global Revocation Trigger Values: 128 Per-Peer Policy 129 Revoking Mobility Node Local Policy Future values of the Binding Revocation Trigger can be allocated using Standards Action or IESG Approval [RFC2434]. Furthermore, this document creates a third new name space "Status Code" for the Status field in the Binding Revocation Acknowledgement message. The current values are described in Section 6.2, and are the following: Muhanna, et al. Expires September 25, 2009 [Page 33] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 0 success 1 partial success 128 Binding Does NOT Exist 129 IPv4 HoA Binding Does NOT Exist 130 IPv4 Home Address Option Required 131 Global Revocation NOT Authorized 132 CAN NOT Identify Binding 133 Revocation Failed - MN is Attached Future values of the Status field can be allocated using Standards Action or IESG Approval [RFC2434]. All fields labeled "Reserved" are only to be assigned through Standards Action or IESG Approval. 14. Security Considerations The protocol described here uses the same security association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the session was established. If IPsec is used, the SPD of this IPsec SA MUST allow the MH type for the Binding Revocation Message defined in this document. However, in the case when the MAG sends a BRI message with the Global (G) bit is set and the Revocation Trigger field is set to "Per-Peer policy", the LMA MUST verify that the MAG is authorized to use Per- Peer Global Revocation. 15. Acknowledgements The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay Devarapalli, and Joel Hortelius for their review and comments of this draft and all colleagues who have supported the advancement of this draft effort. 16. References 16.1. Normative References [ID-DSMIP6] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-07 (work in progress), December 2008. Muhanna, et al. Expires September 25, 2009 [Page 34] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-11 (work in progress), January 2009. [ID-PMIP6-IPv4] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09 (work in progress), January 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 16.2. Informative References [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003. Authors' Addresses Ahmad Muhanna Nortel 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: amuhanna@nortel.com Muhanna, et al. Expires September 25, 2009 [Page 35] Internet-Draft Binding Revocation for IPv6 Mobility March 2009 Mohamed Khalil Nortel 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: mkhalil@nortel.com Sri Gundavelli Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 USA Email: kchowdhury@starentnetworks.com Parviz Yegani Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA Email: pyegani@juniper.net Muhanna, et al. Expires September 25, 2009 [Page 36]