Internet Engineering Task Force S. Glass INTERNET DRAFT Sun Microsystems M. Chandra Cisco Systems July 2001 Registration Revocation in Mobile IP draft-ietf-mobileip-reg-revok-01.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is a submission to the Mobile IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 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. Distribution of this memo is unlimited. Abstract During the original design of Mobile IP, the potential need for an administrative domain to be able to actively revoke a current Mobile IP registration was recognized. Due to the lack of a specific scenario requiring such a mechanism, it was decided that instead of designing a mechanism explicitly for the purpose of registration revocation, a passive mechanism, namely short registration lifetimes, and the denial of a subsequent registration of a Mobile Node, would be sufficient for this purpose. Investigations into requirements for a AAA protocol within the AAA working group have forced reconsideration of a more pro-active Mobile IP registration revocation feature. In the new model revocations must be possible from either home or foreign domains, so any registration revocation mechanism being defined must also allow signaling to the mobility agent providing Mobile IP functionality at the other end of S. Glass, M. Chandra Expires January, 2002 [page i] Internet Draft Registration Revocation in Mobile IP July 2001 the tunnel that the current registration has been released. Moreover, the Mobile Node whose registration has been terminated should also be informed that such a revocation is occurring, if only so it may understand it is not longer being provided mobile ip services, though the reasons for such a revocation need not necessarily be relayed. In some cases the current registration may be terminated to simply force the Mobile Node to renegotiate its registration, and in other cases the registration is terminated absolutely with no renegotiation allowed by the terminating side. In other cases, the message could be used to simply relay the information that the services are no longer being provided on one side, so they need not be provided on the other. This document defines such a general use registration revocation mechanism meeting these requirements. Table of Contents: 1. Introduction................................................. 1 2. Motivation................................................... 3 3. Registration Revocation Overview............................. 4 3.1 Mobile Node Notification.................................. 4 3.2 Registration Revocation Mechanism - Notification.......... 6 3.2.1 Home Domain Revoking a Registration................... 7 3.2.2 Foreign Domain Revoking a Registration................ 7 3.2.3 Mobile Node De-registering a Registration............. 8 3.3 The Use of Bits........................................... 8 3.3.1 The 'R' Bit in Use.................................... 9 3.3.2 The 'D' Bit in Use....................................10 4. Revocation Messages Formats...................................10 4.1 Revocation Support Extension..............................11 4.2 Revocation Message........................................11 4.2.1 Revocation Mask.......................................15 4.2.2 Replay Protection.....................................16 4.3 Revocation Acknowledgment Message.........................18 5. No New Error Codes...........................................19 6. Multiple Binding Support.....................................19 6.1 Other Random Protocol Details.............................20 7. Security Considerations......................................20 Appendix A: Registration Revocation in 'R' and 'D' Bit Worlds....21 Appendix B: Disparate Address, and Receiver Considerations.......22 Acknowledgments..................................................24 Where to Direct Comments.........................................24 References.......................................................25 Full Copyright Statement.........................................26 S. Glass, M. Chandra Expires January, 2002 [page 1] Internet Draft Registration Revocation in Mobile IP July 2001 1. Introduction During the original design of Mobile IP, the need for either home or foreign administrative domain to potentially be able to revoke a current Mobile IP registration was recognized. Due to the lack of specific need for such a mechanism, however, it was decided that a passive mechanism, namely the denial of a subsequent registration from a Mobile Node, in conjunction with the recommendation for short registration lifetimes could be used, and was sufficient for this purpose. Recently, requirements for a AAA protocol [A] have forced a requirement for a more pro-active Mobile IP feature to revoke a Mobile Node's current registration, thereby informing the mobility agent performing the Mobile IP services at the other end of the tunnel that a current registration has been released, and also informing the Mobile Node that it's current registration has been terminated. A mobility agent who receives notification that a mobile node is no longer being provided mobility services by the 'mobility agent peer' no longer has to provide services to that mobile node itself. This means resources being directed to supporting that mobile node can be used some where else in a more timely fashion than if the mobility agent had to wait for the binding to expire. This is useful in notifying a foreign agent that a a mobile node has roamed away, and is therefore no longer in need of its services. A general registration revocation mechanism is defined to handle these situations. The protocol is broken into two disjoint pieces. First, a mechanism to inform the Mobile Node of the revocation of it's current binding is described using a mechanism which already exists in the base Mobile IP protocol [1]. This means any Mobile Node which is designed to comply with [1] will understand it's registration has been revoked. Next, a signaling mechanism between Home and Foreign Agents is described which allows either the home or foreign domain to inform the agent at the other end of the tunnel, or mipagent-peer, it has torn down the current tunnel, allowing both to free up the resources associated with the indicated Mobile IP binding. In addition, Revocation Messages pass information between the mobility agents as to whether the registration is revoked conditionally, or absolutely. A conditional revocation means the Mobile Node's current registration is terminated, but may be renegotiated in subsequent re-registration attempts. Such revocations serve the purpose of forcing the Mobile Node to renegotiate its Mobile IP registration, thereby either incorporating more, or waiving some or all of the service characteristics of its mobility binding. For example: forcing multicast services to be setup as soon as they are needed from the home domain, or forcing a reverse tunnel to be torn-down as soon as the foreign domain decides it no longer wishes to support it. An absolute revocation, as the name implies, means the Mobile Node's current registration is terminated and no renegotiation through the current Foreign Agent, or potentially the entire foreign domain, will be allowed. S. Glass, M. Chandra Expires January, 2002 [page 2] Internet Draft Registration Revocation in Mobile IP July 2001 The mechanism described in this document differs from the methods described in [1] for De-registrations, which apply to situations where the Mobile Node is playing the active role in informing the Home Agent of its location and maintaining its Care-of address(es), in that the mechanism described here is relayed between the mobility agents. Revocation/release messages are also a logical addition to the messages defined in [1] for the generic Mobile IP registration process, and apply to situations where mobility agents need to play an active role in administering Mobile IP registrations. This document therefore describes methods to be used only when mobility agents are initiating the releasing of individual bindings for specific Mobile Nodes, and the methods defined by this document are NOT to be applied by co-located Mobile Nodes that are terminating their registration as De-Registration Requests for such a [co-located] Care-of addresses is already sufficient for this purpose. A co-located Mobile Node, however, may wish to process received Revocation Messages as it is a useful mechanism to trigger the establishment of a new registration, renegotiating required services from the home domain. This reader is assumed to be familiar with the concepts and terminology used in [1] and [6]. Knowledge of the concepts of [2] and [3] is also be beneficial. 2. Motivation Mobile IP [1], [3] defines registration of a Mobile Node's location to provide connectivity between the Mobile Node and its home domain, facilitating communication between the Mobile Node and any Correspondent Node. At any time either Home or Foreign Agent may wish to stop servicing a Mobile Node, or for administrative reasons may no longer be required to service a mobile node, but no mechanism has been described to inform the mobility agent providing Mobile IP services at the other end of the tunnel that such services have been terminated. A more common scenario also occurs when a mobile node roams away from a foreign agent, which now no longer needs to provide mobile ip services to it. Moreover, a Mobile Node may be informed that a Foreign Agent has lost its binding if that agent has reset, and is advertising with reset sequence numbers, but there is currently no way for a Mobile Node to know when a Home Agent has done the same thing. If the Home Agent shuts down the tunnel, the Foreign Agent will simply stop seeing tunnel packets for the Mobile Node, just as if a route stopped functioning, or if there is simply no traffic for the Mobile Node. If, before shutting down, a Home Agent sends a (conditional) Revocation Message to the Foreign Agent (or Mobile Node), it may get earlier indication of the need to renegotiate another binding. If the Foreign Agent shuts down the tunnel, the Home Agent will continue sending tunnel packets, which will likely be received, then silently discarded. An aware Mobile Node may notice the lack of response to packets it is generating, eventually guessing it's binding S. Glass, M. Chandra Expires January, 2002 [page 3] Internet Draft Registration Revocation in Mobile IP July 2001 may have vanished, and may attempt to re-register. Only at that time will the Mobile Node get a registration denied error with some hint as to why it service was stopped, by whom. Clearly a more active mechanism needs to be provided allowing more timely communication between the three Mobile IP entities in the various administrative domains. 3. Registration Revocation Overview Registration revocation consists of two disjoint pieces, a signaling mechanism between the tunnel endpoints, and a signaling mechanism between the Foreign Agent and Mobile Node. A co-located Mobile Node, i.e., a Mobile Node which is decapsulating its own tunnel traffic, MAY implement the tunnel endpoint-signaling portion of this protocol in order to understand revocation/release notices from its Home Agent. A Mobile Node that is co-located, however, does not have to implement sending Revocation Messages as deregistration messages defined in [1] are sufficient for this purpose. This doesn't exclude a (co-located) Mobile Node from implementing this protocol should there be a need. 'The following are introduced for the necessary communication for the revocation mechanism: - Revocation Support Extension: An extension appended to a Registration Request or Registration Reply by a mobility agent indicating its support of registration revocation, and also indicating whether it will acknowledge receipt of a revocation message. - Revocation Message: A message sent by a mobility agent to inform another mobility agent, or colocated mobile node, that it is revoking/releasing the binding of a Mobile Node(s). - Revocation Acknowledgment Message: A message to indicate successful receipt of a Revocation Message. 3.1 Mobile Node Notification A mechanism which provides a Foreign Agent a way to actively notify a Mobile Node that its binding has been reset already exists in [1], though it has been overlooked for this purpose. When a Foreign Agent begins sending agent advertisements, it starts with a sequence number of 0, and [monotonically] increments the sequence number with each subsequent agent advertisement. In order for a Mobile Node to be able to distinguish between a Foreign Agent which has been reset, and thereby lost the mobile node's binding information, from one which has simply exhausted its sequence number space, when a foreign agent is about to roll it's sequence space to 0, S. Glass, M. Chandra Expires January, 2002 [page 4] Internet Draft Registration Revocation in Mobile IP July 2001 it instead sets the sequence number of the next agent advertisement to 256. In this way, a Mobile Node would have to miss 255 advertisements in a row. Moreover, the lifetimes contained within an agent advertisement should be set in such a way that when a mobile node misses 3 beacons, the entry for this foreign agent should time out, and if the mobile node is registered there, it should send a solicit. If, however, an agent is somehow reset, it will begin advertising with a sequence number of 0, and the mobile node will understand it is very likely this foreign agent has lost its binding, and the mobile node SHOULD reregister to make sure it is still obtaining mobile ip services through this agent. Leveraging this mechanism, a Foreign Agent may consciously notify all Mobile Node's currently bound to it that it has "reset" all their bindings, even if the agent itself has not been reset, by simply [re]setting the sequence number of an agent advertisement to 0. Moreover, a Foreign Agent may inform all Mobile Nodes currently bound to it they should re-register with a different Foreign Agent by also setting the 'B' bit to 1, indicating it is busy and is not accepting new registrations. In these situations, any Mobile Node in compliance with [1] understands the Foreign Agent has lost its binding, and must re-register if they wish to reestablish tunnels, and Mobile IP functionality with their Home Agent. By using this mechanism, a Foreign Agent may also notify a single Mobile Node that it's binding has been reset by unicasting to it, as described by [1] and [5] an agent advertisement with the sequence number set to 0. If such a Foreign Agent wishes to indicate to the Mobile Node that its binding has been unconditionally revoked, and should not attempt to renew it's registration with it, the Foreign Agent may also set the 'B' bit to 1 in these agent advertisements, indicating it is busy, and is not accepting new registrations. All Mobile Nodes compliant with [1] will understand this means the agent is busy, and MAY either immediately attempt to re-register with another agent in their foreign-agent cache, or MAY solicit for additional agents. In the latter case, a Foreign Agent can remember the Mobile Node's binding was unconditionally revoked, and respond to the solicit in the same way, namely with the 'B' bet set to 1, or MAY choose to simply ignore the solicitation. It should be noted, though, that since the Foreign Agent is likely to not be advertising with the 'B' bit set to 1 in its agent advertisements sent to the entire link, the revoked Mobile Node, upon hearing the multicast agent advertisement may attempt to [re]register with it. If this should happen, the Foreign Agent can simply deny the Mobile Node with an appropriate error code (e.g. "administratively prohibited"). At this time, any Mobile Node may use Foreign Agent fallback to attempt to register with a different agent as described in [1]. Mobile Nodes which understand this revocation mechanism MAY understand that a unicast agent advertisement with the 'B' bit set in this scenario could indicate a revocation, and MAY attempt to register, or co-locate in another domain (e.g. if the Mobile Node is in multiple coverage areas with a single, or multiple interfaces). In any case, Mobile Nodes must be able to continue to operate as described by [1], even if their S. Glass, M. Chandra Expires January, 2002 [page 5] Internet Draft Registration Revocation in Mobile IP July 2001 registration has been revoked since many Mobile Nodes may not understand the concept of revocation. Agent Advertisements unicast to a Mobile Node must be sent as described in [1], in addition to any methods currently in use on the link to make them secure or authenticatable by the Mobile Node, which are highly desirable to protect from denial-of-service attacks [7]. 3.2 Registration Revocation Mechanism - Notification Any active mechanism designed to be useful to both home and foreign domains must contain a way to securely revoke the current binding. This means the registration process must supply both home and foreign domains with enough information to be able to inform the other side of a revocation. As in [1], any information the Foreign Agent appends to the Registration Request MUST therefore be protected by a Foreign-Home authenticator, as MUST any information outside the Home-Mobile authenticator in the corresponding Registration Reply. Due to the nature of domain wishing to participate in registration revocation, it is likely the authenticators would be required by policy between the home and foreign domain anyway. In the case of a co-located Mobile Node where a Foreign Agent is not involved in the registration process, a Home Agent MAY inform the co-located Mobile Node its binding is revoked by sending it a Revocation Message protected by a Home-Mobile authenticator. Moreover, a Revocation Message MUST NOT be sent for a registration that has simply expired, and MAY only be sent prior to the expiration of a Mobile Node's registration. A Mobile Node that is terminating (one of) its own bindings, however, SHOULD NOT send a Revocation Message to its home agent, as the method described in [1], namely deregistering a Care-of address, is sufficient; the mechanism detailed in this document is not meant to replace it. During the registraion process, if the foreign agent wishes to participate in revocation messages with the home domain, it MUST share a security association with the home agent indicated in the registration request sent by the mobile node (or the home domain). The foreign agent MUST append a Revocation extension (defined in section 4.1 below) to the registration request. If the registration reply from this home agent does not contain a Revocation extension, the foreign agent MAY assume the home agent/domain does not understand registration revocation. Upon receiving a registration request containing a Revocation extension, if the home agent wishes to participate in revocation messages with the foreign domain, the home agent MUST share a security relationship with the foreign agent, and MUST append a Revocation extension to the registration reply. If the registration request from a home agent does not contain a Revocation extension, the home agent S. Glass, M. Chandra Expires January, 2002 [page 6] Internet Draft Registration Revocation in Mobile IP July 2001 MAY assume the foreign agent/domain does not understand registration revocation. 3.2.1 Home Domain Revoking/Releasing a Registration In the case where the Home Agent is revoking/releasing a Mobile Node's binding, the Home Agent MUST notify the Care-of address it is terminating the tunnel entry point. If the Home Agent is revoking the registration of a Mobile Node that is not co-located (that is the 'D' bit is NOT set in its most recent Registration Request) a Home-Foreign security association must exist, and a Home-Foreign authenticator MUST be included in the registration Revocation Message. Upon receiving such a notification, the Foreign Agent MUST check the Home-Foreign authenticator, and if the packet passes the authentication, the Foreign Agent SHOULD notify the Mobile Node that its binding has been reset by using the method described in section 3.1 above, and MAY free up any resources being used by the former binding, and discontinue all Mobile IP services for this Mobile Node. The Foreign Agent MUST respond with a revocation confirmation if the 'A' bit was set in the revocation message. This confirmation which MUST contain a foreign-home authenticator to be verified by the home agent. If a Foreign Agent receives a registration Revocation Message that does not contain, or contains a bad a Home-Foreign authenticator, it MUST be ignored, and silently discarded. If the Home Agent is revoking the registration of a Mobile Node which is co-located (as indicated to the Home Agent by the setting of the 'D' bit in its Registration Request) , a Home-Mobile authenticator MUST be used. If the Mobile Node understands registration revocations, upon receiving such a notification, the Mobile Node MUST check the Mobile-Home authenticator, and if the packet passes authentication, the Mobile Node SHOULD terminate any reverse tunnel encapsulation it is using to the Home Agent. The Mobile Node MAY also free up any other resources associated with the former binding. Upon sending a Revocation Message with the 'A' bit set, if the HA does not receive an Revocation Acknowledgment Message from the FA, it SHOULD retransmit the message. How may times the message is retransmitted is implementation specific, though a mobility agent MUST NOT retransmit a revocation/release message more than once/second, and a maximum of 3 retransmitions is recommended. 3.2.2 Foreign Domain Revoking/Releasing a Registration In the case where the foreign domain is revoking/releasing a Mobile Node's binding, the Foreign Agent SHOULD notify the Mobile Node as described in section 3.1 above. In addition, a Foreign Agent which is terminating the binding of a Mobile Node MUST inform the Home Agent the Mobile Node is registered with that it is shutting-down the tunnel exit point (and reverse tunnel entry point). This will allow the Home Agent to stop generating tunnel packets from datagrams destined for S. Glass, M. Chandra Expires January, 2002 [page 7] Internet Draft Registration Revocation in Mobile IP July 2001 the Mobile Node, and also allow it to free resources it is currently reserving for the Mobile Node. In this case, if the most recent Registration Request indicated the Mobile Node is using a co-located care-of address (the 'D' bit is set), and hence the registration request doesn't contain any information about the foreign agent, the Foreign Agent MUST include an NAI extension for identification by the Home Agent in the revocation message. A Foreign-Home authenticator MUST be included at all times in the registration Revocation Message. Upon receiving a registration Revocation Message, the Home Agent MUST check the Foreign-Home authenticator, and if the packet passes the authentication, MAY free up any resources associated with the former binding and discontinue all Mobile IP services for this Mobile Node. If the 'A' bit was set in the revocation message, the home agent MUST at that time send a revocation confirmation to the address identified as the Care-of address in the registration revocation message. If a Home Agent receives a registration Revocation Message that does not contain a Foreign-Home authenticator, or a bad Foreign-Home authenticator, it MUST be ignored, and silently discarded. If a Foreign Agent shares a security association with an Home Agent and understands the Revocation Message, the Foreign Agent SHOULD append the Revocation Support Extension defined in Section 4.1 to a Registration Request. The Foreign Agent MAY set the 'A' bit in the extension to indicate that it will acknowledge the received Revocation Message. The Foreign Agent must protect the extension with the FHAE. By including this extension, the Foreign Agent informs the Home Agent that it wishes to be notified of a revocation of this Mobile Node's binding or of a change in this Mobile Node's CoA. Upon sending a Revocation Message with the 'A' bit set, if the FA does not receive an Revocation Acknowledgment Message from the HA, it SHOULD retransmit the message. 3.2.3 Mobile Node Deregistering a Registration The cases where a Mobile Node is registered with it's Home Agent, whether it is registered directly with its Home Agent (as in the case of co-location), or registered via a Foreign Agent (if it is co-located or not), and wishes to terminate it's own binding, the Mobile Node SHOULD simply deregister its Care-of Address with its Home Agent as described by [1] or [3]. If a co-located Mobile Node receives an authenticated registration revocation from its Home Hgent, a Mobile Node MAY generate a Revocation Acknowledgment Message in response. In this scenario, the Mobile Node MUST include a Mobile-Home authenticator. 3.3 The Use of Bits Several of the bits used in the registration process play an important role in the topology of the binding, and therefore the revocation. S. Glass, M. Chandra Expires January, 2002 [page 8] Internet Draft Registration Revocation in Mobile IP July 2001 The 'R' bit in the agent advertisement is an effective way to assure the foreign domain is provided with the binding information necessary to revoke it, especially important in the case of a co-located Mobile Node whose Registration Request may otherwise by-pass it (how the foreign domain enforces this policy is beyond the scope of this document, but it is believed to be enforced through either access to topologically correct addresses with which to co-locate, or some form of access control lists on the routers). The 'D' bit in the Registration Request is a sign to a home domain that a Foreign Agent address does NOT appear in the registration request, and so the Home Agent may be missing the necessary information to be able to notify the foreign domain in the event of a registration revocation. A Home Agent that receives a Registration Request in which the 'D' bit is set SHOULD look for a Foreign Agent NAI extension appearing AFTER the Mobile-Home authenticator indicating the Foreign Agent to which any Revocation Messages are to be sent. More information, and an example, is provided in "Appendix A: Registration Revocation in 'R' and 'D' Bit Worlds." 3.3.1 The 'R' Bit in Use If the Foreign Agent wishes to be able to revoke a[ny] Mobile Node's registration, it MUST set the 'R' bit in its agent advertisements. A Foreign Agent advertising the 'R' bit requests every Mobile Node, even one that is co-located, to register [it's co-located address as its Care-of address] with the Foreign Agent, making the Foreign Agent then capable of revoking the Mobile Node's registration as it is now privy to the information in the Registration Request, namely it's home (and link) address, and the address of the Mobile Node's Home Agent. The Foreign Agent will then be able to unicast an agent advertisement to the Mobile Node, and send a Registration Revocation Message to the Home Agent, as described in section 3.1, and 3.2.2 above. This makes advertising the 'R' bit attractive in domains that wish to have control over registered Mobile Nodes, and moreover, sending revocation notification to the home domain may be a contractual necessity. Enforcement of the 'R' bit is beyond the scope of this document, and when the foreign domain wishes to be able force the revocation, and/or to notify the home domain of revoked registrations, such an enforcement mechanism is crucial. A co-located Mobile Node sets the 'D' bit in its Registration Request, and since by definition the co-located address is topologically significant for the link the Mobile Node is visiting, the Registration Request may be sent directly to the Home Agent even in the presence of agent advertisements in which the 'R' bit is set (though this is considered "bad form", and the 'R' bit is a "hint" to the Mobile Node that such direct contact is policed in some way). In the event a foreign domain wishes to immediately revoke the registration of a co-located Mobile Node (which is not the same as denying subsequent registrations from this Mobile Node), the foreign domain MUST be able to control the flow of S. Glass, M. Chandra Expires January, 2002 [page 9] Internet Draft Registration Revocation in Mobile IP July 2001 datagrams to, and/or from, the Mobile Node. The easiest way to do this is to not accept Registration Requests from co-located Mobile Nodes, though there are other mechanisms available. A Foreign Agent that wishes to deny a Registration Request from a Mobile Node because it is co-located SHOULD return error 77 "invalid Care-of address" whenever a Mobile Node specifies a Care-of address other than that of the Foreign Agent and/or sets the 'D' bit in its Registration Requests [1]. 3.3.2 The 'D' bit in Use If the Mobile Node has set the 'D' bit in the Registration Request, and the Foreign Agent determines it will accept the registration from the Mobile Node, if the Foreign Agent wants to be notified of registration revocations for this Mobile Node, the foreign agent MUST append its NAI extension to the Registration Request, and MAY also append the prefix length extension (type 19) that appears in the agent advertisements on the link the Mobile Node is registering. The inclusion of the prefix length extension is so the Home Agent understands the topology of the link the Mobile Node is visiting in the event it wants to issue a single registration revocation for multiple Mobile Nodes visiting the same link. The Foreign Agent MUST then append a Foreign-Home authenticator. If the Home Agent accepts the Registration Request, registration Revocation Messages for this binding SHOULD be first sent to the Mobile Node's co-located Care-of address, and MUST be sent to the Foreign Agent. It is presumed that the security association between the Home and Foreign Agents contains (among other things) the NAI and IP addresses of the 'agent-peers'. Home agents which receive a Registration Request with the 'D' bit set, in which a Foreign Agent NAI appears but no Foreign-Home authenticator is appended, SHOULD deny the Registration Request with error 132 "Foreign Agent failed authentication". A Home Agent that receives a Registration Request with the 'D' bit set, and no Foreign Agent NAI, nor a Foreign-Home authenticator MUST assume the Registration Request came directly from a co-located Mobile Node, and therefore MUST send the Registration Reply, and any registration Revocation Message to the co-located Care-of address. In response to a valid Registration Request that has the 'D' bit set, and also includes a Foreign Agent NAI extension, and Revocation Support Extension, the Home Agent MUST append a Revocation Support Extension to the Registration Reply AFTER the Home-Mobile authenticator. The Home Agent MUST also include a Home-Foreign authentication extension for validation by the Foreign Agent. 4. Revocation Message Formats This section details the format of the signaling protocol between Home and Foreign Agents, or from a Home Agent to a co-located Mobile Node. S. Glass, M. Chandra Expires January, 2002 [page 10] Internet Draft Registration Revocation in Mobile IP July 2001 4.1 Revocation Support Extension The Mobile IP Revocation Support extension MUST be attached to a Registration Request forwarded by a Foreign Agent, or co-located Mobile Node, or to a Registration Reply sent by a Home Agent if the mobility agent wishes to be notified of the termination of this mobile node's binding. It MAY also be attached to an agent advertisement to indicate to the Mobile Node it supports revocations in the event knowledge of this support is critical to the Mobile Node's choice of Foreign Agents. It is NOT necessary that all Foreign Agents on a link support registration revocation. The format of the Revocation Support Extension is based on the Short Extension Format given in [4] 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 |A| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Skippable (TBD) Length Length (in bytes). Does NOT include Type and Length. 'A' Bit When this bit is set, the mobility agent is specifying that it will send an Revocation Acknowledgment in receipt of a Registration Revocation Message. Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on receiving. When appearing in a Registration Request, or Registration Reply, the Mobile IP Registration Revocation extension MUST be protected ether by a Foreign-Home Authentication Extension, or Mobile-Home authentication extension, or any other equivalent mechanism, e.g. AAA [A], [B]. If the extension appearing in either of the above registration messages is NOT protected, it MUST be silently discarded. 4.2 Revocation Message The format of Revocation Message is nearly identical to Registration Request and Registration Reply messages. S. Glass, M. Chandra Expires January, 2002 [page 11] Internet Draft Registration Revocation in Mobile IP July 2001 IP fields: Source Address In the case of the Home Agent issuing the Registration Revocation, the address registered with the Care-of address (and therefore registered with the Foreign Agent if one was privy to the registration) as that of the Home Agent. In the case of the Foreign Agent issuing the registration revocation, if the registration being revoked is NOT for a co-located Mobile Node, the address registered with the Home Agent as the Care-of address. In the case of the revocation of a co-located Mobile Node, any of the addresses of the Foreign Agent associated with the Foreign Agent NAI included in the most recent Registration Request to the Home Agent. Destination Address In the case of the Home Agent issuing the registration revocation, if the 'D' bit was set in the most recent registration, the address associated with the Foreign Agent NAI, if one was present. If no NAI was present, or if the 'D' bit was NOT set, then the address registered as the Care-of address of the Mobile Node whose registration is being revoked (note: this will either be the Mobile Node's co-located Care-of address, or the address specified as the Care-of address by the Foreign Agent). In the case of the Foreign Agent issuing the registration revocation, the address registered as that of the Home Agent by the Mobile Node whose registration is being revoked. UDP fields: Source Port 434 Destination Port 434 S. Glass, M. Chandra Expires January, 2002 [page 12] Internet Draft Registration Revocation in Mobile IP July 2001 The UDP header is followed by the Mobile IP fields shown below 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 | Code |P|A| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Domain Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other Extensions ... +-+-+-+-+-+-+-+-+-+- | Authenticator ... +-+-+-+-+-+-+-+-+-+- Type 7 (Registration Revocation) (T.B.A.) Code A set of flags indicating the applicability of the Registration Revocation. See below for definitions. P Permanent bit. Set to '0' to indicate conditional revocation: the revocation applies to the current registration only, and re-registration attempts will be accepted Set to '1' to indicate unconditional revocation: this revocation applies permanently, and no re-registrations will be accepted. A Acknowledge bit. Set to '0' when the revoking agent does NOT need an acknowledgment of the Revocation Message, or in any revocation response message. Set to '1' when the revoking agent would like acknowledgment the agent-peer received the Revocation Message. Agents SHOULD follow-up with however the A bit was set in the revocation extension messages passed in the registration process. reserved MUST be sent as 0, ignored when received. S. Glass, M. Chandra Expires January, 2002 [page 13] Internet Draft Registration Revocation in Mobile IP July 2001 Home Address The IP address of the Mobile Node whose registration is being revoked, or the subnet address indicating that all Mobile Nodes belonging to this subnet are having their registration revoked, or the zero address if all Mobile Nodes who are registered using this Home Agent and this Care-of address are being revoked. Foreign-domain Address The address identified as being in the foreign domain. This is either the foreign agent's IP address, the care-of address, or the subnet address indicating that all Mobile Nodes using a Care-of address on the identified subnet are having their bindings revoked, or the zero address if all mobile node bindings using the identified Home Agent address are being revoked. Home Agent The IP address identified as that of the Home Agent of this binding, or the subnet address indicating that all Mobile Nodes using a Home Agent on the identified subnet are having their bindings revoked, or the zero address if all Mobile Node bindings using the identified Care-of address are being revoked. Identification Fields A 32-bit number used for protecting against replay attacks. See section 4.2.2 (below). Other Extensions Any relevent extensions for this registration revocation. e.g. NAI extensions. Authenticator An authenticator as defined in [1] MUST be present. This is usually in the form of an Home-Foreign authenticator, or a Home-Mobile authenticator when the Home Agent is revoking the registration of a Mobile Node which is using a co-located Care-of address. For example: if a Foreign Agent wishes to revoke a single registration, and wishes the Home Agent to acknowledge it has received the Revocation Message, it sets the "A" bit to 1 to indicate it wants acknowledgment, the address of the Mobile Node whose registration it wishes to revoke in the home address field, the address that mobile node registered as the Care-of address in the foreign domain field, and the address the Mobile Node registered as the Home Agent address in the Home Agent address field. It also chooses a previously unused with this home agent identifier for the ID field. If the last approved registration request of the Mobile Node indicated it was using a co-located Care-of address, the Foreign Agent includes its NAI to provide context for the foreign-home authenticator, which it appends to the entire message. Upon receiving the above Revocation S. Glass, M. Chandra Expires January, 2002 [page 14] Internet Draft Registration Revocation in Mobile IP July 2001 Message, the Home Agent assures the revocation is protected with a Foreign-Home authenticator. If not, the message is silently discarded. If so, it uses the Foreign Agent NAI (if present) to identify the security association it will need to use to validate the Foreign-Home authenticator. If no Foreign Agent NAI is present, it uses the address in the foreign domain address field to find the security association, and verifies the Foreign-Home authenticator. If the authenticator is good, it uses the home address, and foreign domain address (as the Care-of address) to locate the Mobile Node whose registration is being revoked. The Home Agent then builds an Acknowledgment (since the "A" bit was set), copies the addresses, and the ID field into the reply, and protects it with a Home-Foreign authenticator. 4.2.1 Revocation Mask The use of the revocation mask is optional. If it is not used, it MUST be set to zero. The registration Revocation Message MAY use this to indicate the "extent" of the revocation. In all cases, the Revocation Message indicates the current binding has been lost. The following codes are defined: Value Meaning ----- ----------------------------------------------------------- 0x01 Applies to all bindings where the Mobile Node home address belongs to the same subnet as the address appearing in the home address field. The issuing agent MUST include a prefix-length extension. Note: the address in the home address field MUST either be that of a Mobile Node, or MAY simply be a subnet address (e.g. 10.1.1.0). 0x02 Applies to all bindings where the Care-of address belongs to the same subnet as the address appearing in the foreign domain address field. The issuing agent MUST include a prefix-length extension. Note: the address in the foreign domain address field MUST either be the co-located address belonging to a Mobile Node, or MAY simply be a subnet address (e.g. 10.1.1.0). 0x04 Applies to all bindings where the registration is using the same foreign address appearing in the foreign domain address field. 0x08 Applies to all bindings where the registration is using the same Home Agent address appearing in the Home Agent address field. 0x10 Applies to all bindings with the same administrative domain as the Mobile Node. The issuing agent MUST include the Mobile Node NAI extension. 0x20 Applies to all bindings with the same administrative domain as the Care-of address. (CoA-NAI present!?!) S. Glass, M. Chandra Expires January, 2002 [page 15] Internet Draft Registration Revocation in Mobile IP July 2001 0x40 Applies to all bindings with the same administrative domain as the Foreign Agent. The issuing agent MUST include the Foreign Agent NAI extension. 0x80 Applies to all bindings with the same administrative domain as the home agent. The issuing agent MUST include the Home Agent NAI extension. When multiple flags are set, the corresponding prefix-length extensions appear in the same order, "left-to-right" as the flags. e.g. if the 0x02 and 0x01 bits are set, the first prefix length extension is for the subnet of the Care-of address, and the second prefix length extension is for the subnet of the home address. In all cases, when the revocation mask is non-zero, and the revoking agent is indicating the Revocation Message applies to subnets on its side of the registration, the revoking agent MUST include a prefix length extension in the Revocation Message. For example, if the Home Agent is revoking bindings for all Mobile Nodes belonging to a particular home domain (and registered with the same Foreign Agent), the Home Agent sets the 0x01 bit to 1, includes the prefix length extension for that subnet. When the Foreign Agent receives an authenticated message in which the the 0x01 bit is set, it understands that all Mobile Nodes whose home addresses fall in the subnet range indicated by the home address field and the prefix length extension (using the Home Agent whose address appears in the home agent address field) have been revoked. For authentication where domain bindings are being revoked, the appropriate NAI MUST be included in the Revocation Message. As always, Revocation Messages MUST be authenticated, and the scope of the revocation MUST only apply to the subset of bindings between the revoking agent, and the agent receiving the Revocation Message. E.g. Foreign Agent x.y.z.t sends a Revocation Message to Home Agent a.b.c.d for Mobile Node a.b.c.x, sets the revocation mask to 0x01 The Home Agent MUST NOT revoke all of its bindings for Mobile Nodes on the same home link as the revoked Mobile Node, but only those Mobile Nodes that are also visiting this Foreign Agent. Note: the distinction between bindings in the same subnet as the CoA (0x02), and bindings in the same subnet as the Foreign Agent (0x04) is to be able to discern bindings which may be on different virtual links, that is a Foreign Agent may be servicing different CIDR subnets, or it may be multihomed though using the same CoA for all these subnets. See the appendix on disparate address support in [2] for a related discussion. 4.2.2 Replay Protection As Registration Revocation Messages are designed to terminate service for a Mobile Node, replay protection is crucial to prevent S. Glass, M. Chandra Expires January, 2002 [page 16] Internet Draft Registration Revocation in Mobile IP July 2001 denial of service attacks by "malicious repeaters" - those who store datagrams with the intent of replaying them at a later time (a form of "man-in-the-middle" attack). Such a packet, presuming it passed authentication the first time, would pass subsequent times without a replay protection mechanism to identify the datagram as a repeat, would trick the receiving mobility agent to suspend its Mobile IP services for the Mobile Node identified by the replayed packet. Moreover, though it is rare, since datagrams are not guaranteed to arrive unduplicated (that is datagrams may be duplicated in flight so the receiver sees multiples of the same datagram), this may happen by "design". The same caveat applies to reflected packets (indistinguishable from "malicious repeaters"). Replay protection is handled in direct analogy with the mechanism defined by [1], through two 32-bit identification fields in the registration Revocation Message. If the Home Agent is revoking a registration, it sets the Home Agent Identification field to a valid timestamp, and sets the Care-of Identification field to 0. Upon receipt of the Revocation Message, the Home Agent Identification field is checked against other Revocation Messages received from the same home agent. If the Home Agent Identification field matches that of any previous Revocation Messages for the binding specified, the current Revocation Message MUST be silently discarded. When building the Revocation Acknowledgment message (when the "A" bit is set in the Revocation Message), the Home Agent Identification field is copied into the reply packet, and the Care-of Identification field is set to a valid timestamp. Upon receiving the response, the Home Agent checks the Home Agent Identification field to match it with the revocation it sent, and also checks Care-of Identification field, which MUST be non-zero. (Note: the "A" bit is also checked, and in the revocation response, the "A" bit MUST NOT be set). Note: as it is possible for a Mobile Node to register at different times with different Home Agents, and at different times with different Foreign Agents, it is crucial that it not be required that this ID field be unique in messages from different agents as there is no method for this information to be communicated between agents. For example, if a Mobile Node has simultaneous bindings with multiple Foreign Agents, and these are being revoked, it is possible the Revocation Message from one of the Foreign Agents may contain an ID field that happens to match that of the other registered Foreign Agent's registration revocation received before it. This MUST NOT result in the latter Revocation Message being ignored. It is expected that an agent may simply use a timestamp for replay protection, and increment it whenever it revokes a binding to any other agent. In this case, the agent is limited to a number of revocations equal to the length of the ID field. A better approach is to have a unique value for each agent, thereby greatly increasing the "sequence-space" of this feature. The reader should note that the ID field used in replay protection of Registration Requests (technically) suffers from the same limitations. If timestamps are used, this means only one revocation attempt per second may be made for any registration, or set of registrations. S. Glass, M. Chandra Expires January, 2002 [page 17] Internet Draft Registration Revocation in Mobile IP July 2001 4.3 Registration Revocation Acknowledgment Message The format of Revocation Acknowledgment Message is nearly identical to Registration Request and Registration Reply messages. IP fields: Source Address The destination address of the received Registration Revocation message for which this Registration Revocation Acknowledgment message is being generated. Destination Address The source address of the received Registration Revocation message for which this Registration Revocation Acknowledgment message is being generated. UDP fields: Source Port 434 Destination Port 434 The UDP header is followed by the Mobile IP fields shown below 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 | Code |P| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other Extensions ... +-+-+-+-+-+-+-+-+-+- | Authenticator ... +-+-+-+-+-+-+-+-+-+- Type 9 (Registration Revocation) (T.B.A.) Code A set of flags indicating the applicability of the Registration Revocation. See below for definitions. P Permanent bit. MUST be identical to the P bit in the Registration Revocation Message. reserved MUST be sent as 0, ignored when received. Identification Fields A 32-bit number used for protecting against replay attacks. See section 4.2.2 (below). S. Glass, M. Chandra Expires January, 2002 [page 18] Internet Draft Registration Revocation in Mobile IP July 2001 Other Extensions Any relevent extensions for this registration revocation. e.g. NAI extensions. Authenticator An authenticator as defined in [1] MUST be present. This is usually in the form of an Home-Foreign authenticator, or a Home-Mobile authenticator when the Home Agent is revoking the registration of a Mobile Node which is using a co-located Care-of address. Registration Revocation Acknowledgment message MUST only be sent in response to to Registration Revocation messages in which the 'A' bit was set to 1. 5. No New Error Codes As the intent of a registration Revocation Message is not a request, but essentially a notification that Mobile IP services are discontinued, there are no new error codes. If any registration revocation fails authentication, or replay protection (as described in section 4 above), it MUST be silently discarded, and Mobile IP services are therefore not suspended. Registration Revocation Messages which are authenticated MUST be checked to make sure the information they contain accurately identifies a current session. If so, the registration Revocation Message indicates the mobility agent that sent the message has already terminated, or is about to terminate, its Mobile IP services for this/these registrations. The receiving agent SHOULD free any resources currently being used for the registrations being revoked. 6. Multiple Binding Support [1] allows a Mobile Node to register multiple Care-of addresses with its Home Agent. Each one of these bindings is it's own discrete tunnel, and hence can be treated as a separate case for registration revocation. Consider the situation where a Mobile Node has multiple Care-of addresses registered with a single Foreign Agent (either because the Mobile Node has multiple co-located Care-of addresses and the Foreign Agent has the 'R' bit set, or because the Foreign Agent is multi-homed). Either agent can indicate the revocation of all these bindings by setting the Care-of address field to 0 (and their addresses in the correct places), indicating all Care-of addresses being used by the indicated Mobile Node that are bound to the agent identifying itself by this Revocation Message. If a Foreign Agent revokes a particular Mobile Node's binding(s) with it, the Home Agent MAY or MAY NOT revoke any of the Mobile Node's other bindings (with other Foreign Agents). If a Home Agent is S. Glass, M. Chandra Expires January, 2002 [page 19] Internet Draft Registration Revocation in Mobile IP July 2001 revoking one of a Mobile Node's bindings, it MAY revoke none, or all of the Mobile Node's other bindings as it sees fit. If a Home Agent decides to revoke a single binding for a Mobile Node, the Foreign Agent MAY decide to revoke other bindings for the same Mobile Node as it sees fit. The revocation mask is designed to make revoking multiple bindings easier to specify, and in situations where network topologies make revoking multiple Mobile Node bindings difficult. 6.1 Other Random Protocol Details If a Foreign Agent is revoking a specific registration for a Mobile Node, it MUST include the registered Care-of address, the home address of the Mobile Node whose registration is being revoked, and the Home Agent address of the current binding. If a Foreign Agent is revoking the bindings of all Mobile Nodes using a particular Home Agent, it MAY set the home address field to the zero address, and set the corresponding code. If a Foreign Agent is revoking multiple Care-of address bindings for the same Mobile Node, it MAY set the Care-of address to the zero address. However, if a Home Agent receives a registration revocation from a Foreign Agent indicating the registration for a co-located Mobile Node has been revoked, the Home Agent MUST verify this message is coming from the same Foreign Agent that relayed the Registration Request for this binding. If this can not be verified, or it can be determined that the Foreign Agent issuing this registration revocation is not the Foreign Agent which relayed the Registration Request for the current binding, the Home Agent MUST silently ignore this Revocation Message. This means if a Mobile Node has one or more bindings with different co-located Care-of addresses, and in addition has one or more bindings using Foreign Agent provided Care-of addresses (as in the case of multi-homed Foreign Agent), each set of bindings must be revoked separately. A revocation protocol is also useful in scenarios where a timely release of resources is desireable, regardless of whether the Mobile Node's binding was administratively revoked or terminated for another reason. 7. Security Considerations [1] defines a security mechanism that MUST be used by Home Agents and Mobile Nodes, and optionally Foreign Agents. All messages defined in this document MUST use the security mechanisms defined in [1], and are therefore as secure as those in the core Mobile IP protocol. As registration revocation, when performed, terminates Mobile IP services being provided to the Mobile Node, it is crucial that all security and replay protections mechanisms be verified before a mobility agent recognizes that the other agent has revoked a Mobile Node's binding, and frees up the resources it has reserved for this service. Messages S. Glass, M. Chandra Expires January, 2002 [page 20] Internet Draft Registration Revocation in Mobile IP July 2001 which are sent link-local (e.g. between Mobile Node and Foreign Agent) MAY also be secured by methods outlined in [1], but have no relation to the enhancement described by this document. [6] describes the use of the Network Access Identifier in Mobile IP. It's use here is for the agent to identify each other in a Revocation Message. In the cases where the foreign and home domains are going to approve registrations from a co-located Mobile Node ('D' bit), and in topologies where the Foreign Agent is going to set the 'R' bit in its agent advertisements, the security association the Home Agent shares with the Foreign Agent MUST somehow include the address the Home Agent should send registration Revocation Messages to (e.g. the source address of the relayed Registration Request [1], or a more authoritative address), or the Foreign Agent that will be relaying such Registration Requests MUST be able to authenticate the HA-NAI. Note that Registration Request setting the 'D' bit, and which are relayed through a Foreign Agent due to the advertising of the 'R' bit contain the Foreign Agent address as the source address of the Registration Request as received by the Home Agent. See Appendix A below. It has been recognized that agent advertisements as defined in [1] provide a denial-of-service potential [7]. This is because the agent advertisements as defined in [1] may be spoofed by other machines residing on the link. This may make it possible for such nodes to trick the Mobile Node into believing its registration has been revoked either by unicasting such an advertisement to the link-local address of the Mobile Node, or by broadcasting it to the subnet, thereby tricking all Mobile Nodes registered with a particular Foreign Agent into believing all their registrations have been lost. There has been some work in this working group and others (e.g. IPSec) to secure such router advertisements, though at the time of this publication, no solutions have become common practice. Appendix A: Registration Revocation in 'R' and 'D' Bit Worlds. Two things influence the registration of a Mobile Node on a foreign subnet. First is the Mobile Node's desire to co-locate (use of the 'D' bit). Second is whether the foreign domain is requiring registration through Foreign Agents (the infamous 'R' bit). This leads to several different registration topologies in Mobile IP (note: cases where the Mobile Node is using a private address are considered in Appendix B): - The most generic is the Mobile Node that doesn't co-locate, and registers using a Foreign Agent's Care-of address (regardless of the state of the 'R' bit in the Foreign Agent advertisements) to its Home Agent. In this case, both mobility agents have the necessary information to revoke a Mobile Node's registration. The security association between the agents can be based on IP address, or NAI. S. Glass, M. Chandra Expires January, 2002 [page 21] Internet Draft Registration Revocation in Mobile IP July 2001 - Second is a Mobile Node that co-locates, then registers directly to its Home Agent without registering through a Foreign Agent (FAs ignored, 'R' bit irrelevant). In this case, Home Agent, depending on the implementation at the Mobile Node, MAY notify the Mobile Node that its registration is being revoked, but it isn't possible through Mobile IP for the foreign domain to revoke a Mobile Node registered in this way, nor is it possible for a foreign domain to suspend Mobile IP services being provided to a co-located Mobile Node registered in this way as the Mobile Node is doing its own tunnel decapsulations. - Lastly is a Mobile Node that co-locates setting the 'D' bit, then due to the presence of the 'R' bit in the agent advertisement(s), registers through a Foreign Agent with its home agent. In this case, the Mobile Node has set MNaddr in the Registration Request to it's home address, HAaddr to that of its Home Agent, and COaddr to its co-located address. Note that nowhere in this Registration Request appears the IP address of any Foreign Agent. Upon sending the Registration Request to a Foreign Agent, that Foreign Agent processes the registration, remembering the information it contains. If the Foreign Agent shares a security association with the identified Home Agent, it SHOULD append its NAI, and a Foreign-Home authenticator. The Foreign Agent then sends the Registration Request to the identified Home Agent using its IP address as the source address of the datagram. Upon receiving the Registration Request, the Home Agent MUST check the Foreign-Home authenticator, if present. It does so by using the NAI if present, or the source address of the request. The Registration Reply the Home Agent sends MAY contain the Home Agent's NAI, but it MUST contain an Home-Foreign authenticator if a Foreign-Home authenticator was present in the Registration Request, and the Home Agent MUST send the Registration Reply to the source address of the Registration Request [1], in this case the IP address of the Foreign Agent. In this way the Foreign Agent receives the Registration Reply, and can confirm the validity of the information contained in the Registration Request. Furthermore, it is expected that such a Foreign Agent has the power to control the revocation of a the Mobile Nodes registration although tunnel datagrams are being delivered directly to the co-located Care-of address identified by the Registration Request the same as it is assumed such a Foreign Agent can enforce the mobile node from sending the Registration Request directly to the home agent. Appendix B: Disparate Address, and Receiver Considerations Since the registration Revocation Message comes from a source address that is topologically routable from the interface receiving S. Glass, M. Chandra Expires January, 2002 [page 22] Internet Draft Registration Revocation in Mobile IP July 2001 the datagram, the agents, by definition, are topologically connected (if this were not the case, the initial registration mechanism would have failed). If either are connecting this topologically connected region to one or more disparate address spaces no problems are foreseen. In order for the Mobile Node to have successfully registered with its Home Agent, it MUST have provided to the network to which it is currently attached a routable address of its Home Agent. Conversely, the Care-of address being used by the Mobile Node must also be topologically significant to the Home Agent in order for the Registration Reply to have been received, and the tunnel initiated. By definition, then, the Home Agent address and the Care-of address must each be significant, and either address, when combined with the Mobile Node's home address, must for a unique pair to the entity on the other end of the tunnel. Another way of understanding this is that the tunnel endpoint are in some way connected, and hence are unique as far as the other end is concerned. The address at the other end of the tunnel, in combination with the address of the Mobile Node, must form a unique pair that can be identified by the agent receiving the registration Revocation Message. As an example, consider a Mobile Node who's home address lies in disparate address space A behind it's Home Agent. MN[a]-----[c]FA[b]-----((()))-----[b]HA[a]-----[a]CN Address Some topologically Address Space C connected network Space A If we assume there must be a tunnel in existence at the time of the registration revocation, namely between FA[b] and HA[b], then the pair {FA[b],MN[a]} is guaranteed to be unique in the Home Agent bindings, and the pair {HA[b],MN[a]} is guaranteed to be unique in the Foreign Agent's visitor list. As a result of this, a Home Agent receiving a registration Revocation Message and foreign-home authenticator for MN[a] from (IP source address) FA[b] is able to determine the unique Mobile Node address being deregistered (if one is provided). Conversely a Foreign Agent receiving a registration Revocation Message and Home-Foreign authenticator for MN[a] from HA[b] is able to determine the unique Mobile Node address being deregistered (if one is provided). If a Foreign Agent receives a registration Revocation Message with the Home Agent field set to the zero address it MUST be silently ignored. This is to prevent confusion in the case of overlapping private addresses; when multiple Mobile Nodes are registered via the same Care-of address using the same (disparate/private) home address, the Home Agent address is the only way a Foreign Agent can discern these Mobile Nodes. S. Glass, M. Chandra Expires January, 2002 [page 23] Internet Draft Registration Revocation in Mobile IP July 2001 Acknowledgments The authors would like to thank Rajesh Bhalla, Kent Leung, and Alpesh Patel for their work on draft-subbarao-mobileip-resource-00.txt "Releasing Resources in Mobile IP" of which the revocation support extension, and the acknowledgment mechanism are contained in this document. Where to Direct Comments Questions and comments about this draft should be directed at the Mobile IP working group: mobile-ip@sunroof.eng.sun.com Questions and comments about this draft may also be directed to the authors: Steven M. Glass Madhavi W. Chandra Internet Engineering IOS Technologies Division Sun Microsystems Cisco Systems 1 Network Drive 7025 Kit Creek Road Burlington, MA. 01801 Research Triangle Park, NC 27709 Phone: 1.781.442.0504 Phone: 1.919.392.8387 Fax: 1.781.442.1706 E-mail: Steven.Glass@Sun.COM E-mail: mchandra@cisco.com The working group may also be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Megisto Systems, Inc. 6000 Connection Drive 20251 Century Blvd M/S M8-540 Suite 120 Irving, Texas 75039 Germantown, MD 20874 USA USA Phone: +1 972-894-6709 Phone: +1 301-444-1700 Fax : +1 972-894-5349 Fax: +1 301-515-3675 E-Mail: Basavaraj.Patil@nokia.com E-Mail: proberts@megisto.com S. Glass, M. Chandra Expires January, 2002 [page 24] Internet Draft Registration Revocation in Mobile IP July 2001 References [A] Mobile IP Authentication, Authorization, and Accounting Requirements RFC 2977, October 2000 S. Glass, T. Hiller, S. Jacobs, C. Perkins. [B] Criteria for Evaluating AAA Protocols for Network Access RFC 2989, November 2000 B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, P. Walsh, G. Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. Beadles, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, B. Lim, B. Hirschman, R. Hsu, H. Koo, M. Lipford, E. Campbell, Y. Xu, S. Baba, E. Jaques [1] IPv4 Mobility Support RFC 2002, October 1996 C. Perkins, Editor. [2] Reverse Tunneling for Mobile IP, revisited RFC 3024, January 2001 G. Montenegro, Editor. [3] Mobility Support in IPv6 work in progress, revision 13, November 2000 D. Johnson and C. Perkins. [4] 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. [5] ICMP Router Discovery Messages RFC 1256, September 1991 S. Deering, Editor. [6] Mobile IP Network Access Identifier Extension for IPv4, RFC 2794, March 2000 P. Calhoun, C. Perkins. [7] Security Issues in Mobile IP, work in progress S. Glass. S. Glass, M. Chandra Expires January, 2002 [page 25] Internet Draft Registration Revocation in Mobile IP July 2001 Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. S. Glass, M. Chandra Expires January, 2002 [page 26]