Internet Engineering Task Force S. Glass INTERNET DRAFT Sun Microsystems March 2001 Registration Revocation in Mobile IP draft-ietf-mobileip-reg-revok-00.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 purpos of registration revocation, a passive mechanism, namely short registration lifetimes, and the denial of a subsequent registration of a MN, 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. Revocation MUST be possible from either home or foriegn 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 the tunnel that the current registration has been revoked. Moreover, the MN whose registration is S. Glass Expires September, 2001 [page i] Internet Draft Registration Revocation in Mobile IP March, 2001 being revoked MUST also be informed that such a revocation is occuring, though the reasons for such a revocation should not necessarily be relayed. In some cases the current registration may be terminated to simply force the MN to renegotiate its registration, and in other cases the registration is terminated absolutely with no renegotiation allowed by the terminating side. 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 Details.............................. 3 3.1 Mobie Node Notification................................... 3 3.2 Registration Revocation Mechanism - Agent Notificiation... 5 3.2.1 Home Domain Revoking a Registration................... 5 3.2.2 Foreign Domain Revoking a Registration................ 6 3.2.3 The Use of Bits....................................... 6 3.2.3.1 The 'R' Bit in Use................................ 7 3.2.3.2 The 'D' Bit in Use................................ 7 3.3 Revocation Message Format................................. 8 3.3.1 Revocation Mask...................................... 11 4. Replay Protection........................................... 12 5. No New Error Codes.......................................... 13 6. Multiple Binding Support.................................... 13 6.1 Other Random Protocol Details............................ 14 7. Security Considerations..................................... 14 Appendix A: Registration Revocation in 'R' and 'D' Bit Worlds... 15 Appendix B: Disparate Address, and Receiver Considerations...... 16 Where to Direct Comments........................................ 18 References...................................................... 19 Full Copyright Statement........................................ 20 1. Introduction During the original design of Mobile IP, the potential need for either home or foreign administrative domain to be able to cancel 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 MN, in conjunction with the recommendation for short registration lifetimes could be used, and was sufficient for this purpose. Recently, requirements for a AAA protocol have forced a requirement for a more pro-active Mobile IP feature to revoke a mobile node's current S. Glass Expires September, 2001 [page 1] Internet Draft Registration Revocation in Mobile IP March, 2001 registration [9], thereby informing the mobilty agent performing the mobile ip services at the other end of the tunnel that a current registration has been revoked, and also informing the mobile node that it's current registration has been revoked. 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 the agent at the other end of the tunnel it has torn down the current tunnel, allowing it 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 MN's current registration is terminated, but may be renegotiated in subsequent reregistration attempts. Such revocations serve the purpose of forcing the mobile node to renegotiate its mobile ip registration, thereby either incorporating, or waiving some or all of the service characteristics of its mobility binding (e.g. forcing multicast services to be setup as soon as they are needed, or a 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] will be allowed (note that this may be desireable from either home or foreign administrative domains). The methods described in [1] for deregistrations apply to situations where the mobile node is playing the active roll in informing the home agent of its location, and maintaining its care-of address(es). Revocation messages are a logical addition to the messages defined in [1] for generic mobile ip registration processing, and apply to situations where mobility agent's need to play an active roll in administering mobile ip registrations. This document therefore describes methods to be used only when mobility agents are initiating the revocation of individual bindings for specific mobile nodes, and the methods defined by this document are NOT to be applied to co-located mobile nodes that are terminating their registration as deregistration requests for such a [co-located] care of addresses is already sufficient for this purpose. This reader is assumed to be familiar with the concepts and terminology used in [1] and [5]. Knowledge of the concepts of [2] and [3] is also be beneficial. S. Glass Expires September, 2001 [page 2] Internet Draft Registration Revocation in Mobile IP March, 2001 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 a mobile node and any correspondant node. At any time either home or foreign agent MAY stop servicing 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. 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 MN, just as if a route stopped functioning, or if there is simply no traffic for the mobile node. If the foreign agent shuts down the tunnel, the home agent will continue sending tunnel packets, which will likely be silently discarded. An aware mobile node may notice the lack of response to packets it is generating, eventually guessing it's binding may have vanished, and may attempt to reregister. Only at the time when the mobile node attempts to reregister will it get a registration denied error with some hint as to why it service was stopped, and by whom. Clearly a more active mechanism needs to be provided allowing more timely communication between the three mobile ip entites in the administrative domains. 3. Registration Revocation Details Registration revocation consists of two disjoint pieces, a signalling mechanism between the tunnel endpoints, and a signalling mechanism between the foreign agent and mobile node. A colocated mobile node, that is one which is decapsulating it's own tunnel traffic, MAY implement the tunnel endpoint-signaling portion of this protocol in order for its home agent to notify it if it's binding is being terminated. A mobile node that is colocated, however, SHOULD NOT implement the tunnel endpoint signaling portion of this protocol as deregistration messages as defined in [1] are sufficient for this purpose. 3.1 Mobile Node Notification A mechanism providing a foreign agent a way to activly 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 this sequence number with each subsequent agent advertisement. In order for a mobile node to be able to distinguish between a foreign agent which has reset its state from one which has simply exhaused it sequence number space, when the S. Glass Expires September, 2001 [page 3] Internet Draft Registration Revocation in Mobile IP March, 2001 sequence number reaches the maximum allowed by the size of the sequence number field, instead of being allowed to roll over to 0, the foreign agent instead sets it to 256, and then continues to increase it [monotonically]. In this way, for a mobile node to become confused into believing its state was lost by the foreign agent, the mobile node would have to believe it missed 256 agent advertisements from the foreign agent it registered with. The lifetimes advertised in an agent advertisement should be configured in such a way that when a mobile node hasn't seen one for the period of 3 agent advertisements beacon periods, it should be soliciting, e.g. agent advertisement beacon rate is every 5 seconds, the lifetime of each advertisement is (at least, but not significantly more than) 15 seconds. In this way the mobile node will be soliciting this foreign agent long before it could have missed 256 of its agent advertisements. 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 (technically anywhere in the range 0 - 253 inclusive, allowing room for a mobile node to miss one or two beacons after the "reset"). Moreover, a foreign agent may inform all mobile nodes currently bound to it they should reregister with a different foreign agent by simultaneously setting the 'B' bit to 1 in these agent advertisement in which the sequence number has been [re]set to 0 (or again anywhere in the range 0 - 253 inclusive), indicating it is busy and is not accepting new registrations. In these situations, any mobile node in compliance with [1] understands the FA has lost its binding, and must reregister 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 [4] an agent advertisement with the sequence number set to 0 (0 - 253 inclusive). If such a foreign agent wishes to indicate to the mobile node that it 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. Note that such a foreign agent is likely to not be advertising with the 'B' bit set to 1 in its multicast/broadcast agent advertisements, so other mobile node's will still register with it. If upon hearing the multicast agent advertisement, should a mobile node that has recently had it's registration revoked by this FA attempt to [re]register with it, the agent can simply deny the MN with an appropriate error code (e.g. "administratively prohibited"). At this time, the mobile node SHOULD use foreign agent fallback to attempt to register with a different agent as described in [1]. If the mobile node decides to send an agent solicitation, this foreign agent MAY ignore the mobile nodes' solicitation, or MAY again unicast its agent advertisement to the mobile node with the 'B' bit set to 1. S. Glass Expires September, 2001 [page 4] Internet Draft Registration Revocation in Mobile IP March, 2001 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. 3.2 Registration Revocation Mechanism - Agent Notification Any active mechanism designed to be useful to both home and foreign domains must contain a way for either side to securely revoke the current binding. This means the registration process must supply the both home and foreign domains with enough information to be able to inform the other side of a revocation. Any information the foreign agent appends to the registration request MUST therefore be protected by a FA-HA authenticator, and therefore the registration reply MUST contain a HA-FA authenticator. Due to the nature of revoking a registration, it is likely the authenticators would be required by policy between the home and foreign domain anyway. If a mobile node is colocated, and a foreign agent is not involved in the registration process, then a home agent MAY inform the colocated mobile node its binding is revoked by sending it a revocation message protected by a HA-MN authenticator. A mobile node that is terminating (one of) its own bindings, however, does not have to send a revocation message to its home agent. The method described in [1], namely deregistering a care-of address, is sufficent, and the mechanism detailed in this document is not meant to replace it. 3.2.1 Home Domain Revoking a Registration In the case where the home agent is revoking a mobile node's binding, the home agent SHOULD notify the care-of address it is terminating the tunnel entry point. If the mobile node is not colocated (as indicated to the HA by the setting of the 'D' bit in its registration request) a home-foreign security association must exist, and 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 MAY respond with a revocation 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 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 colocated, a mobile-home autenticator MUST be used. 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 S. Glass Expires September, 2001 [page5i] Internet Draft Registration Revocation in Mobile IP March, 2001 is using to the home agent. The mobile node MAY also free up any other resources associated with the former binding. 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 colocated or not), and wishes to terminate it's own binding, the mobile node SHOULD simply deregsiter its Care-of Address with its home agent as described by [1] or [3]. If a colocated mobile nodes receives an authenticated registration revocation from its home agent, a mobile node MAY generate a revocation confirmation in response. In this scenario, the mobile node MUST include a mobile-home authenticator. 3.2.2 Foreign Domain Revoking a Registration In the case where the foreign domain is revoking a mobile node's binding, the foreign agent SHOULD notify the mobile node as described in section 3.1 above. In addtion, an foreign agent which is terminating the binding of a mobile node SHOULD 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 the mobile node, and also allow it to free resourses it is currently reserving for the mobile node. In this case, if the most recent registraint request indicated the mobile node is using a colocated care-of address, the foreign agent MUST include its NAI for identification by the home agent. 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. It MAY 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, it MUST be ignored, and silently discarded. 3.2.3 The Use of Bits Several of the bits used in the registration process play an important roll in the topology of the binding. The 'R' bit in the agent advertisement is an effective way to assure the foreign domain is provided with the binding information neccessary to revoke it, especially important in the case of a colocated mobile node. In addition, the 'D' bit in the registration request is a sign to a home domain that the foreign agent's address doesn't appear in the registration request, and so the home agent may be missing the necessary information to be able to notify the foreign agent in the even of a registration revocation. More information, and an example, is provided in Appendix A: Registration Revocation in 'R' and 'D' Bit Worlds. S. Glass Expires September, 2001 [page 6] Internet Draft Registration Revocation in Mobile IP March, 2001 3.2.3.1 The 'R' Bit in Use If the foreign agent wishes to be able to revoke a mobile node's registration, it MUST set the 'R' bit in its agent advertisements to be privy to the registration information of the mobile node. A foreign agent advertising the 'R' bit requests a mobile node, even one that is colocated, to register [it's colocated address as its care-of address] with a foreign agent, making the foreign agent then capable of revoking the mobile node's registration as it is privy to the information in the registration request, namely the mobile node's home address, and the address of the mobile node's home agent, by sending a Registration Revocation to the home agent, and unicasting an agent advertisement to the mobile node as described in section 3.2.2, and 3.1 above. This makes advertising the 'R' bit attractive in domains that wish to have control over registered mobile nodes, and moreover, revocation notification to the home domain may be a contractual necessity. Enforcment 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 mechnism is crucial. A colocated mobile node sets the 'D' bit in its registration request, and since by definition the colocated address is topologically significant for the link the mobile node is visiting, the registration request may be sent directly to the home agent (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 revok the registration of a colocated 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 datagrams to, and/or from, the mobile node. The easiest way to do this is to not accept registration requests from colocated 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 colocated 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.2.3.2 The 'D' bit in Use If the mobile node has set the 'D' bit in the registration request, and the foreign agent determins it will accept the registration from the mobile node, if the foreign domain 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 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 S. Glass Expires September, 2001 [page 7] Internet Draft Registration Revocation in Mobile IP March, 2001 then append a FA-HA authenticator. If the home agent accepts the registration request, registration revocation messages for this binding MUST be sent to the foreign agent, and MAY also be sent the mobile node's colocated care-of address. Home agents which receive a registration request with the 'D' bit set, in which an NAI appears but no FA-HA authenticator is appended, SHOULD deny the registration request with error 132 "foreign agent failed authentication". Moreover, if an FA-HA authenticator is present, but no foreign agent NAI appears, the home agent SHOULD reply with error 97, "Missing NAI" (note: the mobile node will be able to tell this was returned by the home agent since it will be protected by the HA-MN authenticator; if it was the mobile node's NAI that was missing, the foreign agent would likely be returning this error, but certainly the registration reply would not contain a HA-MN authenticator). A home agent that receives a registration request with the 'D' bit set, and no foreign agent NAI, nor a FA-HA authenticator SHOULD assume the registration request came directly from a colocated mobile node, and therefore MUST send the registration reply, and any registration revocation message to the colocated care-of address. 3.3 Revocation Message Format This section details the format of the signalling protocol between home and foreign agents, or from a home agent to a colocated mobile node. The format of revocation message(s) is nearly identical to registration request and registration request messages. 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 colocated mobile node, the address registered with the home agent as the care-of address. In the case of the revocation of a colocated mobile node, any of the addresses of the foreign agent associated with the NAI included in the most recent registration request to the home agent. S. Glass Expires September, 2001 [page 8] Internet Draft Registration Revocation in Mobile IP March, 2001 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 NAI of the foreign agent, 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 colocated care-of address, or the address specified as the care-of address by the foreign agent respectively). In the case of the foreign agent issuing the registration revocation, the home agent address registered by the mobile node whose registration is being revoked. UDP fields: Source Port 434 Destination Port 434 The UDP header is followed by the Mobile IP fields shown below (the format of which is identical to registration requests in [1]): 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 | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. S. Glass Expires September, 2001 [page 9] Internet Draft Registration Revocation in Mobile IP March, 2001 Lifetime The lifetime of the registration revocation, that is the amount of time the mobile node is to be denied reregistration. A value of zero indicates the mobile node's current registration is terminated, but may be allowed reregistration attempts immediately. A value of 0xffff indicates the current registration is revoked for an infinite time, and no further reregistration attempts will be accepted. 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. 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. Care-of Address The IP address identified as that of the care-of address of this binding, 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. Identification A 32-bit number used for protecting against replay attacks. See section 6 (below). Extensions Any relavent extensions for this registration revocation. e.g. Vendor-specific extensions. Authenticator An authenticator as defined in [1] MUST be present. This is usually in the form of an HA-FA authenticator, or a HA-MN authenticator when the HA is revoking the registration of a mobile node which is using a colocated care-of address. S. Glass Expires September, 2001 [page 10] Internet Draft Registration Revocation in Mobile IP March, 2001 3.3.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 Apply to all bindings with the same subnet as the MN. Issuing agent inlcudes prefix-length extension. 0x02 Applies to all bindings with the same subnet as the CoA. Issuing agent inlcudes prefix-length extension. 0x04 Applies to all bindings with the same subnet as the FA Issuing agent inlcudes prefix-length extension. 0x08 Applies to all bindings with the same subnet as the HA. Issuing agent includes prefix-length extension. 0x10 Applies to all bindings with the same administrative domain as the mobile node. (MN-NAI MUST be present) 0x20 Applies to all bindings with the same administrative domain as the care-of address. (CoA-NAI present!?!) 0x40 Applies to all bindings with the same administrative domain as the foreign agent. (FA-NAI MUST be present) 0x80 Applies to all bindings with the same administrative domain as the home agent. (HA-NAI MUST be present) In all cases, when the revocation mask is non-zero, the revoking agent SHOULD include a prefix length extension in the revocation message. 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 revok 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 FA (0x04) is to be able to discern bindings which may be on different virtual links, that is an FA 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. The code should be interpreted in conjunction with the lifetime. For example, a code of 0 with a lifetime of 0 indicates the current binding is revoked, and future registrations will be accepted immediately. A code of 0 with a lifetime of 10 indicates the current registration is revoked, and future registrations will be accepted after 10 seconds have passed. S. Glass Expires September, 2001 [page 11] Internet Draft Registration Revocation in Mobile IP March, 2001 If a mobile node attempts to reregister before the revocation lifetime has expired, the foreign agent MAY simply reply with error 65, "Administratively prohibited" saving it from tying up resources while the registration would otherwise be pending approval by the home agent. 4. Replay Protection As Registration Revocation messages are designed to terminate service for a mobile node, replay protection is crucial to prevent 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 itentified 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". Replay protection is handled through a 32-bit identification field in the registration revocation message. After a registration revocation message has been authenticated, the ID field MUST NOT match that in any other authenticated registration revocation message from the same mobility agent (foreign agent care-of address/home agent address), and for the same mobile node home address. If the ID field is not unique, message MUST be silently discarded. 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 bindingings 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 foreign agent's registratoin 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 single number 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 lifetime of this feature. The reader should note that the ID field used in replay protection of registration requests (technically) suffers from the same limitations. S. Glass Expires September, 2001 [page 12] Internet Draft Registration Revocation in Mobile IP March, 2001 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 mobile node. The receiving agent SHOULD free any resources currently being used for the binding being revoked. Upon processing a registration revocation, a mobility agent MAY repsond with its own Revocation message to indicate it has received and processed the message, but is not required to do so. A mobility agent that sent a registration revocation messages MAY wait for a revocation confirmation to discontinue mobile ip services to the mobile node. 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 colocated 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 -1, 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 revoks a particular mobile node's binding(s) with it, the home agent MAY or MAY NOT revok any of the mobile node's other bindings (with other foreign agents). If a home agent is 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 revok a single binding for a mobile node, the foreign agent MAY decide to revok 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 where network topologies make revoiking multiple mobile node bindings dificult. S. Glass Expires September, 2001 [page 13] Internet Draft Registration Revocation in Mobile IP March, 2001 6.1 Other Random Protocol Details If a foreign agent is revocing 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. 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 colocated mobile node has been revoked, the home agent MUST verify this message is comming 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 colocated 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. 7. Security Considerations [1] defines a security mechanism that MUST bused 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 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. [5] 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 colocated 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 S. Glass Expires September, 2001 [page 14] Internet Draft Registration Revocation in Mobile IP March, 2001 HA-NAI. Note that registration request setting the 'D' bit, and which are relayted 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 [6]. 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 colocate (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 colocate, 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. - Second is a mobile node that colocates, then registers directly to its home agent without registering through a foreign agent (FAs ignored, 'R' bit irrelavent). 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 colocated mobile node registered in this way as the mobile node is doing its own tunnel decapsulations. S. Glass Expires September, 2001 [page 15] Internet Draft Registration Revocation in Mobile IP March, 2001 - Lastly is a mobile node that colocates 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 colocated 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 FA-HA 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 FA-HA 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 HA-FA authenticator if a FA-HA autenticator 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 colocated 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 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 forseen. In order for the mobile node to have sucessfully registered with its home agent, it MUST have provided to the network to which it is currently attached a routeable 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 S. Glass Expires September, 2001 [page 16] Internet Draft Registration Revocation in Mobile IP March, 2001 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 conected 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 regstration revocation message and FA-HA 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 feceiving a registration revocation message and HA-FA 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 Expires September, 2001 [page 17] Internet Draft Registration Revocation in Mobile IP March, 2001 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 author: Steven M. Glass Internet Engineering Sun Microsystems 1 Network Drive Burlington, MA. 01801 Phone: 1.781.442.0504 Fax: 1.781.442.1706 E-mail: Steven.Glass@Sun.COM The working group may also be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 eMail: Basavaraj.Patil@nokia.com eMail: phil.roberts@motorola.com S. Glass Expires September, 2001 [page 18] Internet Draft Registration Revocation in Mobile IP March, 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] ICMP Router Discovery Messages RFC 1256, September 1991 S. Deering, Editor. [5] Mobile IP Network Access Identifier Extension for IPv4, RFC 2794, March 2000 P. Calhoun, C. Perkins. [6] Security Issues in Mobile IP, work in progress S. Glass. S. Glass Expires September, 2001 [page 19] Internet Draft Registration Revocation in Mobile IP March, 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 Expires September, 2001 [page 20]