Internet Engineering Task Force S. Glass Mobile IP Working Group Sun Microsystems Internet Draft M. Chandra Cisco Systems August 2002 Registration Revocation in Mobile IPv4 draft-ietf-mobileip-reg-revok-04.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@SUNROOF.ENG.SUN.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 This document defines a Mobile IPv4 Registration Revocation mechanism whereby either mobility agent participating in providing Mobile IP services to the same mobile node can notify the other mobility agent (or co-located mobile node) of the termination of either a single, or multiple mobility bindings, and for this notification to be acknowledged. Furthermore, if desired, a signaling mechanism already defined by the base Mobile IP protocol [1] is leveraged as a way to inform the mobile node of the revocation of this binding. S. Glass, M. Chandra Expires February 2003 [page i] Internet Draft Registration Revocation in Mobile IPv4 August 2002 Table of Contents 1. Introduction..................................................... 1 2. Motivation....................................................... 2 3. Revocation Message Formats....................................... 3 3.1 Revocation Support Extension................................... 4 3.1.1 Use in Agent Advertisements................................. 4 3.1.2 Use in Registration Messages................................ 5 3.1.3 Revocation Message Extension Format......................... 5 3.2 Revocation Message............................................. 7 3.2.1 Revocation Mask.............................................11 3.3 Revocation Acknowledgment Message..............................13 3.4 Replay Protection..............................................15 4. Registration Revocation Overview.................................17 4.1 Mobile Node Notification.......................................17 4.2 Registration Revocation Mechanism - Notification...............19 4.2.1 Home Domain Revoking a Registration.........................20 4.2.1.1 Home Agent Responsibilities..............................20 4.2.1.2 Foreign Agent Responsibilities...........................21 4.2.1.3 Co-located Mobile Node Responsibilities..................22 4.2.2 Foreign Domain Revoking a Registration......................22 4.2.2.1 Foreign Agent Responsibilities...........................22 4.2.2.2 Home Agent Responsibilities..............................23 4.2.3 Mobile Node Deregistering a Registration....................24 4.3 The Use of Bits................................................25 4.3.1 The 'R' Bit in Use..........................................25 4.3.2 The 'D' Bit in Use..........................................26 5. Error Codes......................................................27 6. Multiple Binding Support.........................................28 7. Security Considerations..........................................28 7.1 Agent Advertisements...........................................28 7.2 Revocation Messages............................................29 Appendix A Registration Revocation in 'R' and 'D' Bit Worlds........31 Appendix B Disparate Address, and Receiver Considerations...........33 Appendix C Using Registration Revocation to Help Release Resources..35 Appendix D An Example of the New Messages in Use....................36 D.1 The Registration Phase.................................36 D.2 The Revocation Phase...................................37 Acknowledgments......................................................39 Where to Direct Comments.............................................39 References...........................................................40 Full Copyright Statement.............................................41 S. Glass, M. Chandra Expires February 2003 [page ii] Internet Draft Registration Revocation in Mobile IPv4 August 2002 1. Introduction A general registration revocation mechanism is defined for Mobile IPv4, whereby a mobility agent can notify another mobility agent (or co-located mobile node) of termination of a mobility binding. A mobility agent which receives a revocation notification no longer has to provide services to the mobile node whose registration has been revoked. This means resources being consumed to provide Mobile IP services for a mobile node that has stopped receiving Mobile IP services by one agent, can be reclaimed by the other agent in a more timely fashion than if it had to wait for the binding to expire. (Note that Mobile IP 'services' refers to the various responsibilities of the mobility agents as defined in [1]. Mobile IP 'resources' refers to the different functional elements allocated by the mobility agents to support the mobility binding, e.g., memory.) Should foreign domain policy allow for it, informing the mobile node that it is no longer being provided Mobile IP services enables that mobile node to react faster than if it had to discover this for itself (e.g. by waiting to have its attempt to re-register denied). This is crucial as revocation messages are also useful when it is desirable to prompt a mobile node to reregister. For example, if reverse tunnels are now required by home domain policy, revoking registrations that don't use reverse tunnelings prompt reregistration, which can be denied with error 138: "reverse tunnel is mandatory, and 'T' bit not set" [2]. The registration revocation protocol is broken into two disjoint pieces. First, a signaling mechanism between home and foreign agents is described which allows either the home or foreign domain to inform the other it has torn down the current tunnel, allowing both to free up the resources associated with the identified Mobile IP binding, and to acknowledge this understanding. Second, a mechanism to inform the mobile node of the revocation of its 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. The mechanism described in this document is intended for mobility agents playing the active role in ending a mobile node's service, and is relayed between them. The revocation messages defined here are 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, and/or coordinating the release of Mobile IP services. S. Glass, M. Chandra Expires February 2003 [page 1] Internet Draft Registration Revocation in Mobile IPv4 August 2002 The mechanism described in this document do not replace the methods described in [1] for deregistration messages as those apply to situations where the mobile node is playing the active role in informing the home agent of its location when it has roamed e.g., back to its home subnet. This is to say the revocation message defined by this document is NOT for use by co-located mobile nodes that are terminating their registration as deregistration requests are already sufficient for this purpose. A co-located mobile node, however, may wish to process the messages defined in this document as it is a useful mechanism to trigger the renegotiation of required services from the home domain. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [6]. 2. Motivation Mobile IP [1] defines registration of a mobile node's location to provide connectivity between the mobile node and its home domain, facilitating communication between mobile nodes and any correspondent node. During the original design of Mobile IP, a passive mechanism, namely the denial of a subsequent registration from a mobile node, in conjunction with the recommendation for short registration lifetimes, was considered sufficient for this purpose. Investigations into the requirements for a AAA protocol specific to Mobile IP have forced reconsideration of a more pro-active Mobile IP registration revocation feature whereby if either domain wishes to revoke a current registration, this can be communicated to the other domain providing Mobile IP services for the mobile node whose binding is being revoked, and potentially also have the mobile node informed that it is no longer receiving Mobile IP services. 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. If the home agent stops providing Mobile IP services (for a mobile node), the foreign agent will simply stop seeing tunnel packets whose inner-destination address is that of the mobile node, just as if e.g. a route stopped functioning, or if there is simply no traffic for the mobile node. If, before prematurely shutting down a binding, the home agent is capable of sending a revocation message to the foreign agent, both the foreign agent (and the mobile node) get earlier indication. S. Glass, M. Chandra Expires February 2003 [page 2] Internet Draft Registration Revocation in Mobile IPv4 August 2002 If the foreign agent shuts down the tunnel, the home agent will continue encapsulating packets destined for the mobile node, which will likely be silently discarded by the foreign agent. An aware mobile node may notice the lack of response to packets it is generating, eventually guessing its binding may have vanished, then attempt to re-register. Only at that time will the mobile node get a registration denied error with some hint as to why its service was stopped, and by which agent (based on the error code). Another, more common scenario occurs when a mobile node roams away from a foreign agent, which now no longer needs to provide Mobile IP services to it. Notification to the previous foreign agent of this state-change by a home agent could be useful to it (see Appendix C). Another scenario occurs when either the home or foreign domain change their policy with regards to services offered/required of Mobile IP binding. For example, the home domain now requires reverse tunnels, yet there are existing bindings that do not use them. Without a revocation mechanism, new services can only be put in place or removed as bindings are re-registered. A revocation protocol is also useful in scenarios where a timely release of resources is desirable, regardless of whether the mobile node's binding was administratively revoked or terminated for another reason. This has a favorable impact on resolving accounting issues with respect to mobility binding in both domains as the actual end of the registration is relayed. In any of these scenarios, a mobile node must be able to continue to operate as described by [1], even if its registration has been revoked since many mobile nodes may not understand the concept of revocation. Clearly, a more active yet unobtrusive mechanism needs to be provided allowing more timely communication between the three Mobile IP entities in the various administrative domains. Until now, no such mechanism has been defined. 3. 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. The following message-types are introduced by this document for relaying revocation information: S. Glass, M. Chandra Expires February 2003 [page 3] Internet Draft Registration Revocation in Mobile IPv4 August 2002 - Revocation Support Extension (Section 3.1): o An extension appended to an agent advertisement by a foreign agent to indicate its support of registration revocation. o The revocation support extension may also be included in a registration request or registration reply by a mobility agent indicating its support of registration revocation to the receiving agent. o This extension may also be appended to a registration request by a co-located mobile node to indicate its understanding of revocation messages. - Revocation Message (Section 3.2): o A message sent by a mobility agent to inform another mobility agent, or co-located mobile node, that it is revoking the binding of a[t least one] mobile node. These messages are not sent by mobile nodes, but may be received by co-located mobile nodes. o This message MUST NOT be sent by a co-located mobile node. - Revocation Acknowledgment Message (Section 3.3): o A message to indicate the successful receipt of a revocation message. o These messages are sent by mobility agents, or co-located mobile nodes. 3.1 Revocation Support Extension This section describes the use of the Revocation Support Extension by foreign agents in their agent advertisements, and by home and foreign agents in the registration process. 3.1.1 Used in Agent Advertisements A foreign agent MAY include a Revocation Support Extension in its agent advertisements to advertise to any of its links that it supports the registration revocation mechanism on that link. This information may be useful to a mobile node when deciding which foreign agent to register through e.g. should the home domain require a binding with such support. It is NOT required that all foreign agents advertising on any link support registration revocation (unlike support of the 'R' S. Glass, M. Chandra Expires February 2003 [page 4] Internet Draft Registration Revocation in Mobile IPv4 August 2002 bit as described by [1]), nor that registration revocation is supported by any particular foreign agent on all of its links. Security issues the reader should be aware of with agent advertisements are covered in Section 7 and [5]. 3.1.2 Used in the Registration Process The Mobile IP revocation support extension MUST be attached to a registration message by any entity that wants to receive registration revocation messages. Normally, this is either a foreign agent, or a home agent, however a co-located mobile node MAY also include a revocation support extension in its registration request. When appearing in a registration request, or registration reply, the Mobile IP registration support extension MUST be protected either by a foreign-home Authentication Extension, a mobile-home authentication extension, or any other equivalent mechanism [1], e.g. via AAA [A], [B]. If the extension appearing in either of these registration messages is NOT protected, the appropriate action as described by [1] MUST be taken. This is due to the security risks as described by Section 7. 3.1.3 Revocation Support Extension Format The format of the revocation support extension is based on the Type-Length-Value Extension Format given in [1] 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|I| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Skippable. To be assigned by IANA. Length Length (in bytes). Does NOT include Type and Length (in accordance with [1]). 'A' Bit When this bit is set to '1', the mobility agent is specifying that it will send a revocation acknowledgment in receipt of a registration revocation message for this registration (if the other side agrees to do the same). See Sections 3.2 and 4.2. S. Glass, M. Chandra Expires February 2003 [page 5] Internet Draft Registration Revocation in Mobile IPv4 August 2002 'I' Bit This bit is set to '1' by a mobility agent to indicate it supports the use of the 'I' bit in revocation messages. See Sections 3.2 and 4.2. Note that in all revocation scenarios the use of the 'I' bit requires acknowledgment, so if the 'I' bit is set to 1 in a revocation extension, the 'A' bit MUST also be set to '1'. When sent by a foreign agent in a registration request: If set to 1, indicates to the home agent that the foreign agent is willing to have the 'I' bit as set by the home agent in the revocation process determine whether the mobile node is informed of the revocation, or not. If set to 0, indicates to the home agent that the foreign agent will follow its own policy with regards to informing the mobile node in the event of a revocation. When sent by a home agent in response to a revocation extension in which the 'I' bit was set to 1: If set to 1, the home agent agrees to use the 'I' bit in the revocation process to indicate to the foreign agent if the mobile node should be informed. If set to 0, the home agent will not use the 'I' bit in the revocation process, thereby yielding to the foreign agent's default behavior with regard to informing the mobile node. Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on receiving. Support of the 'A' bit and 'I' bit are OPTIONAL. If a mobility agent does not support the specified behavior, it MUST set the respective bit(s) to zero. It is important to note that this extension is of the skippable variety, that is if the receiving mobility agent doesn't understand this extension, it MUST skip it, and continue processing the remainder of the registration request. This is so a home agent will continue to process the registration request which has been forwarded to it, and send a registration reply even though the home agent doesn't support S. Glass, M. Chandra Expires February 2003 [page 6] Internet Draft Registration Revocation in Mobile IPv4 August 2002 registration revocation. In this way, if local policy in the foreign domain requires registrations to be made only with home agents which support this feature, the foreign agent may actively deny the registration with this home agent, and indicate this to the mobile node (e.g. via 65 "administratively prohibited"). In contrast, if this extension were not skippable, a home agent which doesn't understand the revocation extension would silently discard the registration, and there would be no feedback to either the foreign agent, or the mobile node as to why this was occuring. In this way, use of registration revocation can be negotiated for each registration, and each domain has a clear understanding of what is expected. 3.2 Revocation Message The format of revocation message is analogous to registration request and registration reply messages from [1]. IP fields: Source Address In the case of the home agent issuing the registration revocation, the address registered with the care-of address 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 which MUST have been included in the most recent registration request to the home agent. Destination Address In the case of the home agent issuing the registration revocation: In the case where the revocation is not for a co-located mobile node, the address identified as the care-of address of the mobile node, S. Glass, M. Chandra Expires February 2003 [page 7] Internet Draft Registration Revocation in Mobile IPv4 August 2002 In the case where the home agent is notifying the foreign agent servicing a co-located mobile node, any of the addresses associated with the NAI of the foreign agent included in the most recent approved registration request. 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 variable 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 | Mask |A|I| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Domain Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Domain Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Domain Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Domain Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA. (Registration Revocation) Mask A set of flags indicating the applicability of the registration revocation. See Section 3.2.1 for definitions. A Acknowledge bit. This bit MUST NOT be set to '1' unless acknowledgment support was negotiated in the last successful registration of at least one of the mobile nodes whose registration is being revoked, otherwise the results S. Glass, M. Chandra Expires February 2003 [page 8] Internet Draft Registration Revocation in Mobile IPv4 August 2002 can be unpredictable. Set to '0' when the revoking agent does NOT want an acknowledgment for this revocation message, or when the 'A' bit was not negotiated. Set to '1' when the revoking agent is expecting an acknowledgment of this revocation message. I Inform bit. This bit MUST NOT be set to '1' unless 'I' bit support was negotiated in the revocation extension messages passed in the registration process, otherwise the results can be unpredictable. When sent by the home agent to a foreign agent: Set to '0' when the mobile node should NOT be informed of the revocation or because the use of the 'I' bit was not agreed upon. Set to '1' to request that the mobile node be informed of the revocation. In either case, if the home agent wants the foreign agent to acknowlege whether the mobile node was informed or not, it MUST also set the 'A' bit to '1'. Note that when sending a revocation message to a co-located mobile node, this bit is irrelevant. When sent by the foreign agent: Set to '0' when the home agent doesn't have say in whether the mobile node is to be informed of the revocation, or because 'I' bit support was not agreed upon. Set to '1' to ask the home agent if the mobile node should be informed of the revocation. Note that in this case the foreign agent MUST also set the 'A' bit to indicate to the home agent that it needs to acknowledge this revocation message. reserved MUST be sent as 0, ignored when received. S. Glass, M. Chandra Expires February 2003 [page 9] Internet Draft Registration Revocation in Mobile IPv4 August 2002 Home Address The IP address of the mobile node whose registration is being revoked, or the subnet address to indicate all mobile node registrations belonging to this subnet are being revoked, or the zero address to indicate all mobile nodes registered using this home agent and this care-of address are being revoked. See Section 3.2.1. Foreign Domain Address The relevant IP address in the foreign domain to identify which bindings are being revoked. This is one of the following: (i) the foreign agent's IP address, (ii) the co-located care-of address, (iii) the subnet address of either (i) or (ii) indicating all mobile nodes using a care-of address on the identified subnet are having their bindings revoked, or (iv) the zero address if all mobile node bindings using the identified Home Domain Address(es) are being revoked. See Section 3.2.1. Home Domain Address The IP address in the home domain to identify which bindings are being revoked. This can be one of the following: (i) the home agent's IP address, (ii) the subnet address indicating that all mobile nodes using a home agent on the identified subnet are having their bindings revoked. See Section 3.2.1. The zero address MUST NOT be used, as discussed in Appendix B. Foreign Domain Identifier Protects against replay and reflection attacks. When used by the foreign domain, a 32-bit timestamp. When used by the home domain, extends the timestamp in the Home Domain Identifier field to uniquely identify a specific binding. See Section 3.4. Home Domain Identifier Protects against replay and reflection attacks. When used by the home domain, a 32-bit timestamp. When used by the foreign domain, extends the timestamp in the Foreign Domain Identifier field to uniquely identify a specific binding. See Section 3.4. A registration revocation message MUST be protected by a valid authenticator, namely a home-foreign authenticator if the communication is between home and foreign agents, or a mobile-home authenticator if the communication is being sent from a home agent to a co-located mobile node. S. Glass, M. Chandra Expires February 2003 [page 10] Internet Draft Registration Revocation in Mobile IPv4 August 2002 An example of the use of revocation messages is given in Appendix D. 3.2.1 Revocation Mask The use of the revocation mask in the revocation message is OPTIONAL. If it is not used, it MUST be set to all zeros. The registration revocation message MAY use this to indicate the "extent" of the revocation, and is used in combination with the address fields defined above. The following bit-values are defined. Note the low-order bits apply to addresses, and the high-order bits apply to NAIs. 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 address appearing in the home address field MUST either be that of a registered mobile node, or a subnet address. The issuing agent MUST include a prefix-length extension defined by [1] appearing after the revocation message to indicate the bits of address being effected (e.g. revoke: 10.1.1.128, prefixLen: 25). 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 address appearing in the foreign domain address field MUST either be the co-located address belonging to a mobile node, or a subnet address. The issuing agent MUST include a prefix-length extension as defined by [1] appearing after the revocation message to indicate the bits of address being effected (e.g. revok: 10.1.1.192, prefixLen: 26). 0x04 Applies to all bindings where the registration is using the same foreign address appearing in the foreign domain address field. The address appearing in the foreign domain address filed MUST either the address registered as the foreign agent address, or a subnet address in which case the issuing agent MUST include a prefix-length extension as defined by [1] appearing after the revocation message to indicate the bits of address being effected (e.g. revoke: 10.1.1.224, prefixLen: 27). S. Glass, M. Chandra Expires February 2003 [page 11] Internet Draft Registration Revocation in Mobile IPv4 August 2002 0x08 Applies to all bindings where the registration is using the same home agent address appearing in the Home Domain Address field. The address appearing in the Home Domain Address field MUST either be the address registered as the home agent address, or a subnet address. The issuing agent MUST include a prefix-length extension as defined by [1] appearing after the revocation message to indicate the bits of address being effected (e.g. revoke: 10.1.1.240, prefixLen: 28). Note that this address MUST NOT be the zero address, see Appendix B. 0x10 Applies to all bindings within the same administrative domain as the mobile node. The issuing agent MUST include the NAI of [one of] the mobile nodes whose registration is being revoked in an NAI extension, appearing after the revocation message. 0x20 Applies to all bindings with the same administrative domain as the care-of address. The issuing agent MUST include the NAI from the care-of domain in an NAI extension, appearing after the revocation message. 0x40 Applies to all bindings with the same administrative domain as the foreign agent. The issuing agent MUST include the foreign agent NAI in an NAI extension appearing after the revocation message. 0x80 Applies to all bindings with the same administrative domain as the home agent. The issuing agent MUST include the home agent NAI in an NAI extension appearing after the revocation message. When multiple flags are set, the corresponding prefix-length and NAI extensions MUST appear in the same order as the flags appearing in the mask field of the revocation message. 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. For example, if the home agent is revoking bindings for all mobile nodes belonging to a particular home subnet, the home agent sets the mask to 0x01, and includes the prefix length extension for that subnet. When the foreign agent receives an authenticated revocation message in which the mask field is set to 0x01, it understands that all mobile nodes whose home address falls in the subnet range S. Glass, M. Chandra Expires February 2003 [page 12] Internet Draft Registration Revocation in Mobile IPv4 August 2002 indicated by the home address field and the prefix length extension (using the home agent whose address appears in the home domain address field) have been revoked. For authentication where domain bindings are being revoked, the appropriate NAI extension MUST be appended to the revocation message. For example, a foreign agent revoking all binding from the same NAI domain as mn@home.domain would set the mask to 0x10, and include an NAI extension after the revocation message including the NAI mn@home.domain. When the foreign agent receives an authenticated message in which the mask is set to 0x10, it understands that all mobile nodes that used an NAI containing @home.domain have been revoked. Note that the scope of the revocation MUST only apply to the subset of bindings between the revoking agent, and the agent receiving the revocation message. For example, if foreign agent x.y.z.t sends a revocation message to home agent a.b.c.d for mobile node subnet a.b.c.0, and 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 the foreign agent sending the revocation message. 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 links but being served by the same foreign agent, e.g., a foreign agent may be servicing different classless subnets [7], each with their own NAI, or it may be multihomed but using the same CoA for all its subnets (e.g. disparate address support). See Appendix B in [2] on disparate address support for a related discussion. 3.3 Revocation Acknowledgment Message The format of revocation acknowledgment message is analogous to the revocation message. IP fields: Source Address Copied from the destination address of the received registration revocation message for which this registration revocation acknowledgment message is being generated. S. Glass, M. Chandra Expires February 2003 [page 13] Internet Draft Registration Revocation in Mobile IPv4 August 2002 Destination Address Copied from the source address of the received registration revocation message for which this registration revocation acknowledgment message is being generated. UDP fields: Source Port 434 (copied from the destination port of the revocation message) Destination Port Copied from the source port of the revocation message. 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 | Length |I| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Domain Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Domain Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA. (Revocation Acknowledgment) Length 10. The length of the revocation acknowledgment message on octets, not including Type and Length fields. I Inform bit. The 'I' bit MUST NOT be used in the revocation acknowledgment messages unless it was set to '1' in the revocation message. When sent by the home agent: Set to '1' by the home agent to request the foreign agent inform the mobile node of the revocation. Set to '0' by the home agent to request the foreign agent not inform the mobile node of the revocation. When sent by a foreign agent: S. Glass, M. Chandra Expires February 2003 [page 14] Internet Draft Registration Revocation in Mobile IPv4 August 2002 Set to '1' to indicate to the home agent that the mobile node was/will be informed of the revocation. Set to '0' to indicate to the home agent that the mobile node was/will not be informed of the revocation Set to the OPPOSITE of what the home agent set the 'I' bit to in the revocation message to indicate the foreign agent is NOT revealing whether the mobile node was informed or not. See Section 4.1.1.2 for an example. reserved MUST be sent as 0, ignored when received. Foreign Domain Identifier Copied from the Foreign Domain Identifier field of the revocation message for which this revocation acknowledgment is being generated. See Section 3.4. Home Domain Identifier Copied from the Home Domain Identifier field of the revocation message for which this revocation acknowledgment is being generated. See Section 3.4. A registration revocation acknowledgment message MUST only be sent in response to a registration revocation messages in which the 'A' bit was set to 1. A revocation acknowledgment message MUST contain a valid authenticator, namely a home-foreign authenticator if the communication is between home and foreign agents, or a mobile-home authenticator if the communication is between home agents and co-located mobile nodes. An example of the use of the revocation messages is given in Appendix D. 3.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, or by "malicious reflectors" - those who reflect packets back at their original source (both a form of "man-in-the-middle" attack). See Section 7 for a discussion of these security considerations. Replay protection is handled in analogy with the mechanism defined by [1], through two 32-bit identifier fields in the registration revocation message and revocation acknowlegement messages. S. Glass, M. Chandra Expires February 2003 [page 15] Internet Draft Registration Revocation in Mobile IPv4 August 2002 - The agent revoking a registration sets their domain Identifier field in the registration revocation message to a valid 32-bit timestamp, and sets the other Identifier field to a value which, when combined with the 32-bit timestamp, uniquely identifies this revocation. In order to protect against reflection attacks, the value used in the other domain's Identifier field MUST NOT be the same as the timestamp value appearing in that domain's own field. - Upon receipt of an authenticated revocation message, the receiving agent MUST check the values in both Identifier fields to make sure this revocation message is neither a replay of an old revocation message received from the same agent, nor a reflection of a revocation message it sent. If the Identifier fields imply this packet is a replay, the revocation message MUST be silently discarded. - When building a revocation acknowledgment message the acknowledging agent copies the Foreign Domain Identifier and Home Domain Identifier fields of the registration revocation message into the Foreign Domain Identifier and Home Domain Identifier fields of the revocation acknowledgment message respectively. - Upon receiving a valid revocation acknowledgment, the revoking agent MUST check both Identifier fields to make sure they match the Identifier fields from the corresponding revocation message it sent. If not, the revocation acknowledgment message MUST be silently discarded. Note that since one of the identifiers in an incoming revocation message is a 32-bit timestamp, it is possible for an agent, upon identifying the binding(s) for which the revocation message applies, to check the validity of the Identifier fields without having to remember all identifiers sent by a corresponding agent. Implementors are advised to see the information Section 7 when taking this approach. 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 the Identifier fields 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 two or more are being revoked simultaneously, it is possible the revocation message from one of these foreign agents may contain Identifier fields that happen to match that of any or all the other foreign agents. This MUST NOT result in any of these revocation message being ignored. S. Glass, M. Chandra Expires February 2003 [page 16] Internet Draft Registration Revocation in Mobile IPv4 August 2002 4. Registration Revocation Overview Registration Revocation consists of two disjoint pieces: a signaling mechanism between tunnel endpoints, and a signaling mechanism between foreign agent and mobile node. A co-located mobile node (a mobile node which is decapsulating its own tunnel traffic) MAY implement the revocation acknowlegement portion of this protocol in order to respond to revocation messages from its home agent. However, a co-located mobile node MUST NOT send a revocation message as deregistration messages defined in [1] are sufficient for this purpose. 4.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. The following paragraph contains a brief overview of the mechanics of the sequence number in agent advertisement from [1] so the mechanism by which the foreign agent 'implies' to the mobile node that its binding is no longer active is clearly understood. 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 that has simply exhausted the sequence number space from one which has been reset, and thereby lost the mobile node's binding information, a foreign agent sets the sequence number to 256 instead of rolling to 0. In this way, a mobile node would have to miss, at that time, 256 advertisements in a row to mistake a reset as a roll-over. Moreover, the lifetimes contained within an agent advertisement should be set in such a way that when a mobile node believes it has missed 3 beacons, the entry for this foreign agent should time out, and if the mobile node is registered there, it should send an agent solicitation [1]. If, however, an agent is somehow reset, it will begin advertising with a sequence number of 0, and the mobile node can presume this foreign agent has lost its binding, and the mobile node SHOULD re-register to make sure it is still obtaining Mobile IP services through this foreign agent. Leveraging this mechanism, a foreign agent may consciously notify all mobile nodes 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 the next agent advertisement to 0. Moreover, a foreign agent may inform all mobile nodes currently bound S. Glass, M. Chandra Expires February 2003 [page 17] Internet Draft Registration Revocation in Mobile IPv4 August 2002 to it they should re-register with a different foreign agent by simultaneously setting the sequence number to 0, and also setting the 'B' bit in the advertisement to 1, indicating this foreign agent is busy and is not accepting new registrations [1]. In these situations, any mobile node in compliance with [1] will presume this foreign agent has lost its binding, and must re-register if they wish to re-establish Mobile IP functionality with their home subnet. To indicate to any registered mobile node that its binding no longer exists, the foreign agent with which the mobile node is registered may unicast an agent advertisement with the sequence number set to 0 to the mobile node [1], [3]. Moreover, if such a foreign agent wishes to indicate to the mobile node that its binding has been revoked, and that the mobile node 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 [1]. 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 optionally remember the mobile node's binding was revoked, and respond to the solicit in the same way, namely with the 'B' bet set to 1. It should be noted, though, that since the foreign agent is likely to not be setting the 'B' bit to 1 in its broadcasted agent advertisements (sent to the entire link), the revoked mobile node, upon hearing this agent's multicast agent advertisement without the 'B' bit set may attempt to [re]register with it. If this happens, depending of foreign domain policy, the foreign agent can simply deny the mobile node with an appropriate error code (e.g., "administratively prohibited"). At this time, a mobile node MAY use foreign agent fallback to attempt to register with a different foreign agent as described in [1]. Mobile nodes which understand the revocation mechanism described by this document may understand that a unicast agent advertisement with the sequence number reset to 0 could indicate a revocation, and may attempt to register, or co-locate. 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. Such mechanisms are highly desirable to protect from denial-of-service attacks [5]. S. Glass, M. Chandra Expires February 2003 [page 18] Internet Draft Registration Revocation in Mobile IPv4 August 2002 4.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 a 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 any revocation. Moreover, a revocation message MUST NOT be sent for a registration that has expired, and MUST only be sent prior to the expiration of a mobile node's registration. During the registration process, if the foreign agent wishes to participate in revocation messages with the home domain, it MUST append a revocation support extension (defined in Section 3.1) to the registration request. If the corresponding registration reply from this home agent does not contain a revocation support extension, the foreign agent MAY assume the home agent/domain does not understand registration revocation, or is unwilling to participate. Note that in this case, as specified in [1], both registration request and registration reply MUST contain a home-foreign authenticator. If a home agent wishes to participate in revocation messages with the foreign domain, it MUST append a revocation support extension to the registration reply. If the registration request from a foreign agent does not contain a revocation support extension, the home agent MAY assume the foreign agent/domain does not understand registration revocation, or is unwilling to participate specifically for this binding. The home agent MAY include a revocation support extension in the registration reply anyway. If a co-located mobile node wishes to be informed of a released binding by the home agent, it MUST insert a revocation support extension into the registration request. The 'A' bit in the revocation extension is used to indicate the desire to use acknowledgment messages in response to revocation messages for the binding to which they correspond. The use of acknowledgment messages for this registration is negotiated, and is offered by the foreign agent, and agreed to by the home agent. More precisely, by sending a revocation extension in which the 'A' bit is set, the foreign agent is indicating it would like the home agent to resend any revocation message for this registration for which it does not receive a revocation acknowledgment message, and is offering to do the same for the home agent. The home agent then can disagree, in which case it simply does not set the 'A' bit, or agree by setting the 'A' bit to 1 in the revocation extension appearing in the registration reply. The 'I' bit in the revocation extension is used to indicate the decision to inform the mobile node its binding has gone away will be S. Glass, M. Chandra Expires February 2003 [page 19] Internet Draft Registration Revocation in Mobile IPv4 August 2002 left to the home agent. As with the 'A' bit, this functionality is offered by the foreign agent, and accepted by the home agent. More precisely, by sending a revocation extension attached to a registration request in which the 'I' bit is set to 1, the foreign agent is indicating to the home agent that it MAY leave the decision to inform this mobile node its registration has gone away to the home agent (the term "MAY" is used here because it is recognized that domain policy may change during the lifetime of any registration). The home agent can acknowledge that it wishes to do this by setting the 'I' bit to 1, or it can indicate it will not do so by setting the 'I' bit to 0 in the revocation extension appearing in the registration reply. If any agent, or co-located mobile node receives a registration revocation message that does not contain a valid authenticator, namely a home-foreign authenticator if the revocation message is between home and foreign agents, or a mobile-home authenticator if the message is from home agent to co-located mobile node, the revocation message MUST be ignored, and silently discarded. Revocation support is considered to be negotiated when both sides have included a revocation support extension during a successful registration exchange. 4.2.1 Home Domain Revoking/Releasing a Registration The following section details the responsibilities of each party depending on the functionality negotiated in the revocation support extension when the home domain is revoking a registration. 4.2.1.1 Home Agent Responsibilities In the case where a home agent is revoking/releasing a mobile node's binding, and revocation support has been negotiated, the home agent MUST notify the foreign domain address it is terminating the tunnel entry point by sending a revocation message. Note that the foreign domain address can either be the foreign agent's care-of address, or a co-located care-of address. Note that if a co-located mobile node included a revocation support extension in its registration request, and passed it to a foreign agent (because the 'R' bit was set) in which case the foreign agent also included a revocation support extension, there may be a need to send a revocation message to both mobile node and foreign agent. If the 'A' bit was negotiated because it was set to '1' in both revocation extensions passed in the registration process, the home agent MUST set the 'A' bit to '1' in the revocation message and expect S. Glass, M. Chandra Expires February 2003 [page 20] Internet Draft Registration Revocation in Mobile IPv4 August 2002 a revocation acknowledgment in return. If the home agent does not receive a revocation acknowledgment message with in a reasonable amount of time, it MUST retransmit the revocation message. How long the home agent waits to retransmit, and how many times the message is retransmitted is only limited by the requirement that the home agent MUST NOT send more than one revocation per second for a particular binding, that the time between retransmissions SHOULD fall-back in analogy with the registration guidelines in [1], and that it MUST NOT retransmit revocation messages beyond the normal life of the revoked binding. If the revocation message is being sent to a foreign agent, and the use of the 'I' bit was negotiated in the registration process, the home agent MUST set the 'I' bit to 1 if the home agent would like the foreign agent to inform the mobile node of the revocation. Conversely, if the home agent does not want the mobile node notified, it MUST set the 'I' bit to 0. Use of the 'I' bit, by definition, requires the 'A' bit to be set to '1'. The home agent MUST set the Identifier fields as defined in Section 3.4, and include either a home-foreign authenticator, or a mobile-home authenticator if the revocation message is being sent to a co-located mobile node. 4.2.1.2 Foreign Agent Responsibilities Upon receiving a registration revocation message, the foreign agent MUST check the home-foreign authenticator as defined by [1], and the Identifier fields as defined by Section 3.4. The foreign agent must then identify the binding(s) described by the home agent as being released using the information in the revocation message, namely the addresses identified by the mobile node address, the foreign domain address, and the home domain address. Upon locating such bindings, if the 'A' bit was negotiated in the registration phase, and the 'A' bit is now set in the revocation message, the foreign agent MUST respond with a revocation acknowledgment sent to the source address of the revocation message. If the 'I' bit was also negotiated, the foreign agent MUST check the value of the 'I' bit in the revocation message and act accordingly. If notifying the mobile node by the methods described in Section 4.1, the foreign agent MUST set the 'I' bit to '1' in the revocation acknowlegement to be sent to the home agent, or if not notifying the mobile node, the foreign agent MUST set the 'I' bit to '0'. If however, since the negotiation of the 'I' bit in the most recent registration, the policy on the foreign domain has changed so that use of the 'I' bit is no longer allowed, the foreign agent MUST set the 'I' bit in the revocation acknowledgment to the OPPOSITE of what was sent by the home agent. This indicates to the home agent that its wishes were not necessarily followed, and the setting of the S. Glass, M. Chandra Expires February 2003 [page 21] Internet Draft Registration Revocation in Mobile IPv4 August 2002 'I' bit does not indicate whether the mobile node was notified or not. The foreign agent may also free up any resources that were being used by the former binding(s), and discontinue all Mobile IP services for the identified mobile nodes. 4.2.1.3 Co-located Mobile Node Responsibilities Upon receiving a revocation message, the co-located mobile node MUST check the mobile-home authenticator, and the identifiers. If the packet passes authentication, the mobile node MUST verify that the information contained in the revocation messages identifies the home agent with which it has a current binding, that this binding identifies correctly this mobile node and any foreign domain address it is currently using. If the mobile node is able to identify such a binding, the mobile node SHOULD immediately terminate any reverse tunnel encapsulation it is using to this home agent. The mobile node may also free up any other resources associated with the former binding. In addition, if the 'A' bit was negotiated in the registration process, and the 'A' bit was set in the revocation message, the mobile node MUST immediately generate a revocation acknowledgment message in response. The revocation acknowledgment message MUST be sent to the IP source address of the revocation message. 4.2.2 Foreign Domain Revoking/Releasing a Registration The following section details the responsibilities of each party depending on the functionality negotiated in the revocation support extensions when the foreign domain is revoking a registration. 4.2.2.1 Foreign Agent Responsibilities If the most recent registration request indicated the mobile node is using a co-located care-of address (the 'D' bit was set), and hence the registration request was unlikely to 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. (Note: it is presumed the foreign agent had the 'R' bit set when such a co-located mobile node last registered, but even if not, obviously the foreign agent is aware of this binding. In this case, the foreign agent is implying to the home agent this it and/or the foreign domain in general have some way of controlling communications between the mobile node and home agent, and therefore a revocation message in this case implies to the home agent that such lines of communication are going away. See Section 4.3.1 "Use of the 'R' bit"). If the 'A' bit was negotiated in the revocation extension, the foreign agent MUST set the 'A' bit to 1 in the revocation message. S. Glass, M. Chandra Expires February 2003 [page 22] Internet Draft Registration Revocation in Mobile IPv4 August 2002 If the use of the 'I' bit was negotiated, and the policy of informing the mobile node has not changed since the last successful registration exchange, the foreign agent MUST NOT inform any mobile node of its revocation at this time. Instead, the foreign agent MUST set the 'I' bit to '1' in the revocation message, thereby asking the home agent to use the 'I' bit in the revocation acknowledgment to indicate if it should notify the effected mobile nodes. If the policy on the foreign domain has changed since the most recent successful registration, and the foreign agent is no longer able to use the 'I' bit, the foreign agent MUST set the 'I' bit to '0', and follow the policies of the foreign domain with regard to notifying the mobile node. Note, when setting the 'I' bit to 1, the 'A' bit MUST also be set to '1'. If the use of the 'I' bit was not negotiated, the foreign agent MAY inform the mobile node of its revocation as described in Section 4.1, before sending the revocation message to the home agent, just after sending the revocation message to the home agent, or after it receives a revocation acknowledgment message from the home agent, or MAY NOT inform the mobile node at all. If the 'A' bit was set to '1' in the revocation message, the foreign agent SHOULD wait for a revocation acknowledgment message from the home agent. How long the foreign agent waits to retransmit, and how many times the message is retransmitted is only limited by the specification that the foreign agent MUST NOT send more than one revocation per second for a particular binding, SHOULD set its retransmissions to fall-back in analogy with the registration guidelines in [1], and MUST NOT retransmit revocation messages beyond the normal life of the revoked binding. 4.2.2.2 Home Agent Responsibilities Upon receiving a registration revocation message, the home agent MUST check the foreign-home authenticator, and identifier fields. If the packet is acceptable, the home agent MUST locate the binding(s) identified by the foreign agent as being released using the information in the revocation message, namely the addresses identified by the home address, the foreign domain address, and the home domain address fields. Since these bindings are no longer active, the home agent can free up any resources associated with the former bindings and discontinue all Mobile IP services for them. 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 S. Glass, M. Chandra Expires February 2003 [page 23] Internet Draft Registration Revocation in Mobile IPv4 August 2002 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. If use of the 'A' bit was negotiated, and the 'A' bit is set to '1' in the revocation message, the home agent MUST send a revocation acknowledgment to the IP source address of the registration revocation message. If use of the 'I' bit was negotiated, and the 'I' bit is set to '1' in the revocation message, the home agent SHOULD decide if it wants the mobile node informed of the revocation of this binding. If it does want the mobile node informed, it MUST set the 'I' bit in the revocation acknowledgment message to '1'. If it does not want the mobile node informed, it MUST set the 'I' bit to '0'. The home agent MUST set the Identifier field as described by Section 3.4, and protect the revocation acknowledgment message with a home-foreign authenticator or equivalent mechanism before sending the revocation acknowledgment message. 4.2.3 Mobile Node Deregistering a Registration The cases where a mobile node is registered with its home agent, whether it is registered directly with its home agent, or registered via a foreign agent (and in either case may be co-located), and wishes to terminate it's own binding, the mobile node MUST NOT send a revocation message, but SHOULD simply deregister the appropriate care-of address with its home agent as described by [1]. Note that when a co-located mobile node includes a revocation extension in its registration request, it will expect to see a revocation extension in the registration reply from the home agent acknowledging that the home agent is willing to send revocation messages to such a mobile node. However, the home agent should understand that it will not receive revocation messages from such a mobile node, so the decision to include a revocation extension in the registration reply MUST NOT be made based on the home agent's desire to see such messages. A co-located mobile node, and home agent MAY negotiate the use of the 'A' bit, and use it in the revocation process. S. Glass, M. Chandra Expires February 2003 [page 24] Internet Draft Registration Revocation in Mobile IPv4 August 2002 4.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. The 'R' bit in the agent advertisement is an effective way to assure that the foreign domain is provided with the binding information necessary to revoke it. This is especially important in the case of a co-located mobile node whose registration request may otherwise by-pass the foreign agent. How the foreign domain enforces this policy is beyond the scope of this document, but a few examples are through either restricted access to topologically correct addresses with which to co-locate, some form of access control lists on the routers, etc. The 'D' bit in the registration request is a sign to a home domain that a foreign agent address likely 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. Note that if the registration request came from a foreign agent (e.g. the 'R' bit was set), then the source address of the registration request could be that of the foreign agent. The home agent MAY check to see if that address is the care-of address identified in the care-of address field of the registration request (if not, the source address of the registration request is likely that of the foreign agent). Alternatively, as any such NAI extension MUST be secured via a foreign-home authenticator [1], the security association identified by the foreign agent's NAI MAY be used to identify an IP address to which any revocation message is to be sent. More information, and an example, is provided in "Appendix A: registration revocation in 'R' and 'D' Bit Worlds." 4.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. A foreign agent advertising the 'R' bit requests every mobile node, even one that is co-located, to register 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 the mobile node's link address, home IP address, and the address of the mobile node's home agent. The foreign agent will then S. Glass, M. Chandra Expires February 2003 [page 25] Internet Draft Registration Revocation in Mobile IPv4 August 2002 be capable of unicasting an agent advertisement to the mobile node, and sending a registration revocation message to the home agent, as described in Sections 4.1 and 4.2.2. 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 to enforce the revocation, and/or to notify the home domain of revoked registrations, such an enforcement mechanism is crucial. Since the co-located care-of address is by definition topologically correct, the reader must understand that a co-located mobile node may send the registration request directly to the home agent, and perhaps receive a registration reply from 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 enforce the revocation of a co-located mobile node's registration, 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 for local policy to not provide a mechanism for co-location, or for the foreign agent to simply not accept registration requests from co-located mobile nodes, though there are enforcement mechanisms available which allow co-location. 4.3.2 The 'D' bit in Use If the mobile node has set the 'D' bit in the registration request, and forwards the registration via a foreign agent (see Section 4.3.1), and the foreign agent determines it will accept the registration from the mobile node, then the foreign agent MUST append a revocation extension if it wants to be notified of registration revocations for this mobile node (in addition to any already included by the mobile node and protected by the mobile-home authenticator). The foreign agent MAY also append the prefix length extension [1] that appears in the agent advertisements on the link from which 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. In order to authenticate these extensions, the foreign agent MUST append its NAI extension so the home agent may know how to validate the foreign-home authenticator. Note that registration requests where the 'D' bit is set, and which are relayed through a foreign agent due to the advertising of the 'R' bit can contain the foreign agent address as the source address of the S. Glass, M. Chandra Expires February 2003 [page 26] Internet Draft Registration Revocation in Mobile IPv4 August 2002 registration request as received by the home agent. A home agent MAY verify that the source address of this registration request is not the same as the care-of address contained in the registration request, and is therefore likely to be the address of a foreign agent. The reader should note that according to [1] the home agent is required to send the registration reply to the source IP address of the registration request. If the home agent wishes to support registration revocation for this binding, which can be conveyed to either the co-located mobile node, and/or the foreign agent whose NAI appears in the registration request, it MUST include a revocation support extension in the mobile-home portion of the registration reply if it agrees to notify the mobile node of a release of this registration, and/or MUST include a revocation support extension in the foreign-home portion of the registration reply if it agrees to notify the foreign agent of a release of this registration. Note that, as determined by the security association with the foreign agent, it may be necessary for the home agent to include its NAI extension for use by the foreign agent in authenticating the registration reply. Upon release of this registration, if revocation support was negotiated with BOTH the co-located mobile node, and the foreign agent, revocation messages for this binding MUST be first sent to the mobile node's co-located care-of address to ensure that they reach it. This includes the time for any necessary retransmissions should a revocation acknowledgment not be forthcoming. A revocation message MUST then be sent to the foreign agent. If a revocation message was sent to the foreign agent first, there may be no way for a revocation message to then reach the mobile node. Also, in order for the home agent to be able to send a revocation message to the foreign agent, it is presumed that the source IP address of the most recently accepted registration request is that of the foreign agent, or that the security association between the home and foreign agents contains (among other things) the NAI and IP addresses of the foreign agent. 5. Error Codes As the intent of a registration revocation message is not a request to discontinue services, but is a notification that Mobile IP services are discontinued, there are no new error codes. S. Glass, M. Chandra Expires February 2003 [page 27] Internet Draft Registration Revocation in Mobile IPv4 August 2002 6. Multiple Binding Support RFC 3220 [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 registration, 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 the zero address (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 then revoke 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 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, through the use of NAIs, even in situations where network topologies make revoking multiple mobile node bindings difficult to specify numerically. 7. Security Considerations There are two basic susceptibilities, one in agent advertisement mechanism, and one relating to unauthorized revocation messages. 7.1 Agent Advertisements Although the mechanisms defined by this document do not introduce this, it has been recognized that agent advertisements as defined in [1] provide a denial-of-service potential. This is because the agent advertisements as defined in [1] may be spoofed by other machines residing on the link. This makes it possible for such nodes to trick the mobile node into believing its registration has been revoked either by unicasting an advertisement with a reset sequence number to the link-local address of the mobile node, or by broadcasting it to the subnet, thereby tricking all mobile nodes registered with a S. Glass, M. Chandra Expires February 2003 [page 28] Internet Draft Registration Revocation in Mobile IPv4 August 2002 particular foreign agent into believing all their registrations have been lost. For particulars regarding this issue, the reader is referred to [5]. 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. To help circumvent possible denial of service issues here, bringing their potential for disruption to a minimum, mobile node implementors should ensure that any agent advertisement which doesn't conform to a strict adherence to [1], specifically those whose TTL is not 1 or e.g. which do not emanate from the same link-address (when present) as the last successful registration reply, be silently discarded. 7.2 Revocation Messages As registration revocation, when performed, terminates Mobile IP services being provided to the mobile node, it is crucial that all security and replay protection 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], namely the use of challenge-response and mobile-foreign authenticators, but these have no relation, and hence do not add any security to the enhancements described by this document. RFC 3220 [1] defines a security mechanism that MUST be used between home agents and mobile nodes, and MAY used between home agents and foreign agents, namely the use of authenticators. However, revocation messages as defined in this document which are passed between home and foreign agents in the revocation process MUST be protected by the same foreign-home authenticators defined in [1]. As a result, these messages are as secure as registration messages passed between home and foreign agents and containing home-foreign authenticators as defined in [1]. As a result, there are no new security threats introduced by the revocation mechanism than those present in [1] with respect to the compromise of the shared secret which is used to generate the home-foreign authenticators. That said, there are two types of replay attacks which use messages captured "in flight" by a man-in-the-middle between the home and foreign agents - "malicious repeaters" and "malicious reflectors". In the case of a "malicious repeater", a man-in-the-middle captures a revocation message then replays it to the same IP destination address at a later time. Presuming the authenticator of the original packet S. Glass, M. Chandra Expires February 2003 [page 29] Internet Draft Registration Revocation in Mobile IPv4 August 2002 was deemed valid, without replay protections the home-foreign authenticator of the replayed packet will (again) pass authentication. Note that since datagrams are not guaranteed to arrive unduplicated, a replay may occur by "design". In the case of a "malicious reflector" where a man-in-the-middle captures a revocation message then returns it to its originator at a later time, using a security association that involved a (single) shared secret which only protects the contents of the UDP portion of the packet (such as home-foreign authenticators as defined by [1]), without replay protection the sender of the packet will also believe the revocation message to be authenticated. The replay protection mechanism used by the revocation messages defined by this document is designed to protect against both of these man-in-the-middle attacks. As a benefit, by using a 32-bit timestamp it can be more quickly determined if revocation messages are replays, though the reader is advised to use caution in this approach. An agent which receives an authenticated revocation message can compare the Identifier field to that of a previously received revocation message, and if the timestamp in the Identifier field is found to postdate that of the revocation message with the latest timestamp, it can immediately be determined as not being a replay. Note however that since datagrams are not guaranteed to arrive in order, it should not be presumed that because the values contained in an Identifier field are timestamps that they will necessarily be increasing with each successive revocation message received. Should an implementor decide to base his replay detection mechanism on increasing timestamps, and therefore increasing Identifier values, a suitable time window should be defined in which revocation messages can be received. At worst, should the 'A' bit have been negotiated, ignoring any revocation message should result in the retransmission of another revocation message, this time with timestamp later than the last one received. RFC 2794 [4] describes the use of the Network Access Identifier in Mobile IP. Its relevant use here is for agents to be able to identify each other in a revocation message. In cases where foreign and home domains are going to approve registrations from co-located mobile nodes (registering with the 'D' bit [1]), and in topologies where the foreign agent is setting the 'R' bit in its agent advertisements [1], if the agents are going to use their NAIs to identify themselves the security association they share MUST include the IP address the registration revocation messages are to be sent to, and will be sent from. For a more involved discussion, see Appendix A. S. Glass, M. Chandra Expires February 2003 [page 30] Internet Draft Registration Revocation in Mobile IPv4 August 2002 Appendix A: Registration Revocation in 'R' and 'D' Bit Worlds. Two issues 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, all the necessary information to revoke a mobile node's registration is contained in the registration. The security association between the agents can be based on IP address, or NAI. - Second is a mobile node that co-locates, then registers directly to its home agent without registering through a foreign agent (foreign agents ignored, 'R' bit irrelevant). In this case, the home agent 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's registration in this way, nor is it possible for a foreign domain to suspend Mobile IP services being provided to a co-located mobile node 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 the last 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 MUST 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 such a registration request, the home agent MUST check the foreign-home authenticator. It does so by using the NAI if present, or perhaps the source address of the request. The registration reply the home agent sends MAY contain the S. Glass, M. Chandra Expires February 2003 [page 31] Internet Draft Registration Revocation in Mobile IPv4 August 2002 home agent's NAI, but it MUST contain a 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. Note that in cases where a foreign agent is able to revoke the registration of a co-located mobile node, it is expected that such a foreign agent has the power to control the data-flow of a co-located mobile node even though tunnel datagrams are being addressed directly to the mobile node. This is akin to how such a foreign agent would enforce the 'R' bit, preventing the mobile node from sending the registration request directly to the home agent. S. Glass, M. Chandra Expires February 2003 [page 32] Internet Draft Registration Revocation in Mobile IPv4 August 2002 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 the ultimate hop from 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 (foreign agent) 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 must form a unique pair in the context of this mobile node to both agents. Another way of understanding this is that the tunnel endpoint are in some way connected, and hence each 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 therefore 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. In the following diagram, [*] indicates an interface of the entity in which it appears. MN[a]-----[c]FA[b]=====((()))=====[b]HA[a]-----[a]CN Address Some topologically Address Space C connected network Space A We presume a binding for MN exists, and hence a tunnel between FA[b] and HA[b] exists. Then, since the address assigned to MN[a] MUST be unique in address space A, the pair {FA[b],MN[a]} is guaranteed to be unique in the binding table of HA, and the pair {HA[b],MN[a]} is guaranteed to be unique in the foreign agent's visitor list. As a result, a home agent receiving a registration revocation message and foreign-home authenticator for MN[a] from FA[b] is able to determine the unique mobile node address(es) being deregistered. Conversely a foreign agent receiving a registration revocation message and home-foreign authenticator for MN[a] from HA[b] is able to determine the exact mobile node address being deregistered. S. Glass, M. Chandra Expires February 2003 [page 33] Internet Draft Registration Revocation in Mobile IPv4 August 2002 For this reason, if a foreign agent receives a registration revocation message with the home domain field set to the zero address it MUST be silently discarded. This is to prevent confusion in the case of overlapping private addresses; when multiple mobile nodes are registered via the same care-of address and coincidentally using the same (disparate/private) home address, the home agent address appearing in the home domain field is the only way a foreign agent can discern the difference between these mobile nodes. S. Glass, M. Chandra Expires February 2003 [page 34] Internet Draft Registration Revocation in Mobile IPv4 August 2002 Appendix C: Using Registration Revocation to Help Release Resources When a mobile node moves out/around a foreign domain from where it had registered, relevant resources at a previous foreign agent may be consumed until its visitor entry for the mobile node expires. For example, consider a cdma2000 network deployment using Mobile IP. The Wireless IP Network Standard [8] defines foreign agent/Packet Data Servicing Node (PDSN) procedures for managing the PPP session for a mobile node, i.e., when the Radio Network opens an R-P session for an mobile node, the foreign agent/PDSN initiates establishment of a PPP session. As a mobile node moves from one foreign domain serviced by a foreign agent/PDSN (source PDSN) to another PDSN (target PDSN) during an inter-PDSN handoff, a Mobile IP registration is sent to the home agent and a new PPP session is established at the target PDSN. The PPP session at the source PDSN remains exhausted until the PPP inactivity timer expires. Maintaining these PPP sessions may consume valuable resources at the source PDSN that could otherwise be used to support additional mobile nodes. Registration revocation messages can be used to help identify resources that could be released (without actually having an administrative revocation). To accomplish this, the revocation support extension would need to be appended to a registration request as it is forwarded by a foreign agent that supports registration revocation. Note that the revocation support extension is protected by the foreign-home authenticator. When a home agent that supports registration revocation receives such a registration request, as required by this specification it MUST record the capability of this foreign agent. The home agent may then use a registration revocation message to notify this foreign agent if the mobile node's care-of address changes, e.g., when the mobile node moves from one foreign agent to another, or when the mobile node deregisters with the home agent. As a result, upon receipt of an authenticated revocation message, the foreign agent can delete the visitor entry for this mobile node, thereby releasing the resources being used to support it. S. Glass, M. Chandra Expires February 2003 [page 35] Internet Draft Registration Revocation in Mobile IPv4 August 2002 Appendix D: An Example of the New Messages in Use For clarity, the following examples are meant to illustrate the use of these messages in the registration phase, and the revocation phase. In cases where there may be some question to the order of processing, any order indicated by [1] MUST be followed. D.1 The Registration Phase A foreign agent that supports registration revocation, and has a security association with a home agent to which it is forwarding a registration request MAY include the revocation support extension after the mobile-home authenticator. If the foreign agent wishes to receive a revocation acknowledgment from the home agent in the event that the registration for this mobile node is revoked, and/or if it is willing to send a revocation acknowledgment message in response to a revocation message from the home agent for this mobile node, it MUST set the 'A' bit to '1'. Furthermore, if the foreign agent supports the use of the 'I' bit, and is willing to let the home agent decide if the mobile node should be informed of the revocation of its registration, it MAY set the 'I' bit to '1'. Additionally, the foreign agent MUST append a foreign-home authenticator to the registration request, and include any other extension needed by the foreign agent to verify the authenticator [1]. Upon receiving a registration request containing a revocation extension, a home agent that supports registration revocation MAY include a revocation support extension in the registration reply. If the 'A' bit is set in the revocation extension sent by the foreign agent, a home agent that wishes that foreign agent to retransmit unacknowledged revocation messages, and agrees to do the same, MUST set the 'A' bit in its revocation extension to '1'. Furthermore, if the foreign agent set the 'A' bit to '1', and also set 'I' bit to '1' in its revocation extension, and the home agent supports the use of the 'I' bit, and wishes to determine whether this mobile node is to be informed in the event that its registration has been revoked, the home agent MUST set the 'A' bit, and the 'I' bit in its registration extension to '1'. Additionally, the home agent MUST append a home-foreign authenticator to the registration request, and include any other extension needed by the foreign agent to verify the authenticator [1]. Upon receiving the authenticated registration reply, the foreign agent MUST check the revocation support extension. If none is present, the foreign agent SHOULD assume that the home agent doesn't understand revocation messages, or is unwilling to participate. If a revocation support extension is present, and if the foreign agent included the S. Glass, M. Chandra Expires February 2003 [page 36] Internet Draft Registration Revocation in Mobile IPv4 August 2002 revocation extension in the registration request with the 'A' and 'I' bit were set to '1', the foreign agent MUST check the 'A' bit to see if the home agent will provide revocation acknowledgment services (if they were requested), and MUST also check the 'I' bit to see if the home agent wants to decide if the mobile node should be notified in the event this registration is revoked. D.2 The Revocation Phase If a foreign agent wishes inform a home agent that is is revoking a mobile node's registration, it generates a revocation message. If the 'A' bit was negotiated in the revocation extension for this registration, the foreign agent MUST set the 'A' bit in the revocation message to '1'. If the 'A' bit and 'I' bits were negotiated in the revocation extensions, and the foreign agent is willing to let the home agent indicate whether this mobile node should be informed that its registration has been revoked, it will set both the 'A' bit and the 'I' bit to '1'. The foreign agent will also place 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 in the home domain address field. The foreign agent MUST set the Foreign Domain Identifier to the current 32-bit timestamp, and set the Home Domain Identifier to a value that will, when combined with the timestamp, uniquely identify this binding to the foreign agent. The foreign agent MUST append a foreign-home authenticator, and any additional information it needs to include for the home agent to validate it (e.g. if the care-of address is not its own, it can use its NAI extension). Upon receiving the above revocation message, the home agent assures the revocation is protected with a valid foreign-home authenticator. The home agent uses either the foreign agent NAI if present, or the address identified as the foreign domain address to identify the security association, and authenticate the revocation message. If the authenticator is bad, the home agent MUST ignore, and silently discard the revocation message. If the authenticator is good, the home agent MUST check to make sure the Identifier does NOT indicate this revocation is a replay. The home agent then uses the mobile node home address, foreign domain address, and home domain address to locate the mobile node(s) whose registration(s) is/are being revoked. If the 'A' bit was negotiated in the registration phase for the binding(s) identified, and set to '1' in the revocation message, the home agent MUST generate a revocation acknowledgment message. If the 'I' bit was negotiated in the registration phase for the binding(s) identified, the home agent will check to see if the 'A' bit and 'I' bit are both set to '1' in the revocation message. If so, and the S. Glass, M. Chandra Expires February 2003 [page 37] Internet Draft Registration Revocation in Mobile IPv4 August 2002 home agent wishes for the identified mobile node(s) to be informed of the revocation, it MUST set the 'I' bit in the revocation acknowledgment to '1', or if the home agent does not wish the identified mobile node(s) to be informed of the revocation, it MUST set the 'I' bit in the revocation acknowledgment to '0'. The home agent then copies the addresses, and the Identifier field into the reply. The home agent MUST protect the revocation acknowledgment with a home-foreign authenticator (and any other extension necessary for the foreign agent to authenticate the home-foreign authenticator, e.g. its NAI extension). Upon receiving a valid revocation acknowledgment (in which the authenticator and Identifier fields are acceptable), if the foreign agent set the 'I' bit in the revocation message to '1', it MUST check the 'I' bit in the revocation acknowledgment, and if set to '1', MUST notify the mobile node of the revocation, or if the 'I' bit is set to '0' in the revocation acknowledgment, the foreign agent MUST NOT notify the mobile node of the revocation. S. Glass, M. Chandra Expires February 2003 [page 38] Internet Draft Registration Revocation in Mobile IPv4 August 2002 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 Solaris Network Technologies 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 February 2003 [page 39] Internet Draft Registration Revocation in Mobile IPv4 August 2002 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 RFC2989, 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] IP Mobility Support for IPv4 RFC3220, January 2002 C. Perkins, Editor. [2] Reverse Tunneling for Mobile IP, revisited RFC3024, January 2001 G. Montenegro, Editor. [3] ICMP Router Discovery Messages RFC 1256, September 1991 S. Deering, Editor. [4] Mobile IP Network Access Identifier Extension for IPv4 RFC 2794, March 2000 P. Calhoun, C. Perkins. [5] Security Issues in Mobile IP draft-glass-mobileip-securities-issues-02.txt S. Glass. [6] Key Words for us in RFCs to Indicate Requirement Levels RFC 2119, March 1997 S. Bradner [7] CIDR and Classful Routing RFC 1817, August 1995 Y. Rekhter [8] TIA/EIA/IS-835, Wireless IP Network Standard, June 2000. S. Glass, M. Chandra Expires February 2003 [page 40] Internet Draft Registration Revocation in Mobile IPv4 August 2002 Full Copyright Statement "Copyright (C) The Internet Society (2001 - 2002). 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 February 2003 [page 41]