diff options
Diffstat (limited to 'doc/rfc/rfc3543.txt')
| -rw-r--r-- | doc/rfc/rfc3543.txt | 1851 |
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc3543.txt b/doc/rfc/rfc3543.txt new file mode 100644 index 0000000..dd7142a --- /dev/null +++ b/doc/rfc/rfc3543.txt @@ -0,0 +1,1851 @@ + + + + + + +Network Working Group S. Glass +Request for Comments: 3543 Sun Microsystems +Category: Standards Track M. Chandra + Cisco Systems + August 2003 + + + Registration Revocation in Mobile IPv4 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines a Mobile IPv4 Registration Revocation mechanism + whereby a mobility agent involved in providing Mobile IP services to + a mobile node can notify the other mobility agent providing Mobile IP + services to the same mobile node of the termination of this + registration. The mechanism is also usable by a home agent to notify + a co-located mobile node of the termination of its binding as well. + Moreover, the mechanism provides for this notification to be + acknowledged. A signaling mechanism already defined by the Mobile + IPv4 protocol is leveraged as a way to inform a mobile node of the + revocation of its binding. + +Table of Contents + + 1. Introduction and Applicability . . . . . . . . . . . . . . . . 2 + 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Registration Revocation Extensions and Messages. . . . . . . . 4 + 3.1. Advertising Registration Revocation Support. . . . . . . 5 + 3.2. Revocation Support Extension . . . . . . . . . . . . . . 6 + 3.3. Registration Revocation Message. . . . . . . . . . . . . 8 + 3.4. Registration Revocation Acknowledgment Message . . . . . 11 + 3.5. Replay Protection. . . . . . . . . . . . . . . . . . . . 14 + 4. Registration Revocation Overview . . . . . . . . . . . . . . . 15 + 4.1. Mobile Node Notification . . . . . . . . . . . . . . . . 15 + 4.2. Registration Revocation Mechanism - Agent Notification . 17 + 4.2.1. Negotiating Revocation Support . . . . . . . . . 17 + + + +Glass & Chandra Standards Track [Page 1] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + 4.2.2. Home Domain Revoking a Registration. . . . . . . 19 + 4.2.2.1. Home Agent Responsibilities. . . . . . 19 + 4.2.2.2. Foreign Agent Responsibilities . . . . 20 + 4.2.2.3. 'Direct' Co-located Mobile Node + Responsibilities . . . . . . . . . . . 20 + 4.2.3. Foreign Domain Revoking a Registration . . . . . 21 + 4.2.3.1. Foreign Agent Responsibilities . . . . 21 + 4.2.3.2. Home Agent Responsibilities. . . . . . 22 + 4.2.4. Mobile Node Deregistering a Registration . . . . 23 + 4.3. Mobile IP Registration Bits in the Revocation Process. . 23 + 4.3.1. The 'R' Bit in Use . . . . . . . . . . . . . . . 23 + 4.3.2. The 'D' Bit in Use (co-located mobile nodes) . . 23 + 5. Error Codes. . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 24 + 6.1. Agent Advertisements . . . . . . . . . . . . . . . . . . 24 + 6.2. Revocation Messages. . . . . . . . . . . . . . . . . . . 25 + 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 27 + 7.1. New Message Types. . . . . . . . . . . . . . . . . . . . 27 + 7.2. New Extension Values . . . . . . . . . . . . . . . . . . 27 + 7.3. New Error Codes. . . . . . . . . . . . . . . . . . . . . 27 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 8.1. Normative (Numerical References) . . . . . . . . . . . . 27 + 8.2. Informational (Alphabetical References). . . . . . . . . 28 + Appendix A An Example of the New Messages in Use. . . . . . . . . 29 + A.1. The Registration Phase . . . . . . . . . . . . . 29 + A.2. The Revocation Phase . . . . . . . . . . . . . . 29 + Appendix B Disparate Address, and Receiver Considerations . . . . 30 + Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 32 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 33 + +1. Introduction and Applicability + + 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. At any time, either the home or foreign agent may wish to + cease servicing a mobile node, or for administrative reasons may no + longer be required to service a mobile node. + + This document defines a general registration revocation mechanism for + Mobile IPv4, whereby a mobility agent can notify another mobility + agent (or a 'direct' co-located mobile node) of the termination of + mobility bindings. A mobility agent that receives a revocation + notification no longer has to provide services to the mobile node + whose registration has been revoked. A signaling mechanism already + defined by the Mobile IPv4 protocol [1] is leveraged as a way to + inform a mobile node of the revocation of its binding. + + + +Glass & Chandra Standards Track [Page 2] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + The registration revocation protocol provides the following + advantages: + + 1. Timely release of Mobile IP resources. 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. This also applies to the case in which a + mobile node roams away from a foreign agent to another foreign + agent. Notification to the previous foreign agent would allow it + to reclaim resources. + + 2. Accurate accounting. This has a favorable impact on resolving + accounting issues with respect to the length of mobility bindings + in both domains, as the actual end of the registration is relayed. + + 3. Earlier adoption of domain policy changes with regards to services + offered/required of a Mobile IP binding. For example, the home + domain may now require reverse tunnels [C], 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. + + 4. Timely notification to a mobile node that it is no longer + receiving mobility services, thereby significantly shortening any + 'black-hole' periods to facilitate a more robust recovery. + + The revocation protocol is an active, yet unobtrusive mechanism + allowing more timely communication between the three Mobile IP + entities in the various administrative domains. Since many mobile + nodes may not understand the concept of revocation, care has been + taken to ensure backwards compatibility with [1]. + + The registration revocation protocol does not replace the methods + described in [1] for Mobile IP deregistration, as the purpose of + these mechanisms is fundamentally different. Deregistration messages + are used by a mobile node to inform its home agent that it has e.g., + roamed back to its home subnet, whereas revocation messages are used + between mobility agents to signal the termination of mobility + bindings. More specifically, the revocation message defined here is + NOT for use by 'direct' co-located mobile nodes that are terminating + their registration as deregistration messages are already sufficient + for this purpose. A 'direct' co-located mobile node, however, may + wish to process revocation messages as it is a useful mechanism to + trigger the re-negotiation of required services from the home domain. + + + + + + +Glass & Chandra Standards Track [Page 3] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + +2. Terminology + + It is assumed that the reader is familiar with the terminology used + in [1]. In addition, the following terms are defined: + + 'Direct' Co-located Mobile Node + + A mobile node registering directly with its home agent, with the + 'D' bit set in its registration request, and NOT registering + through a foreign agent. + + Mobile IP Resources + + Various functional elements allocated by a mobility agent to + support a Mobile IP binding, e.g., memory. + + Mobile IP Services + + Various responsibilities of a mobility agent in supporting a + mobile node as defined in [1], e.g., encapsulation of packets + addressed to a mobile node by a home agent, decapsulation of these + packets by a foreign agent for delivery to a mobile node, etc. + + Mobility Agent + + The home agent or foreign agent as specified in [1]. + + Revocation + + Premature termination of a mobility binding. + + 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 BCP 14, RFC 2119 [3]. + +3. Registration Revocation Extensions and Messages + + Registration revocation in Mobile IPv4 is accomplished via the + following: + + - Advertising Registration Revocation Support (Section 3.1.): + + o A flag in the Agent Advertisement extension has been reserved + for agents to advertise their support of revocation messages. + + + + + + + +Glass & Chandra Standards Track [Page 4] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + - Revocation Support Extension (Section 3.2.): + + o This extension is appended to a registration request or + registration reply by a mobility agent to indicate its support + of registration revocation. + + o This extension is appended to a registration request by a + 'direct' co-located mobile node to indicate its understanding + of revocation messages. + + - Registration Revocation Message (Section 3.3.): + + o A message sent by a mobility agent to inform another mobility + agent, or a 'direct' co-located mobile node, that it has + revoked the binding of a mobile node. + + - Registration Revocation Acknowledgment Message (Section 3.4.): + + o A message sent by mobility agents or 'direct' co-located mobile + nodes to indicate the receipt of a revocation message. + + Security considerations related to the above messages and extensions + are covered in Section 6. + +3.1. Advertising Registration Revocation Support + + Mobility agents can advertise their support of registration + revocation with a modification to the Mobility Agent Advertisement + extension described in [1]. An 'X' bit is introduced to indicate an + agent's support for Registration Revocation. + + 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 | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Registration Lifetime |R|B|H|F|M|G|r|T|U|X| reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | zero or more Care-of Addresses | + | ... | + + X The mobility agent supports Registration Revocation + + A foreign agent that sets the 'X' bit in an agent advertisement + extension MUST support registration revocation messages on that link, + specifically the Revocation Support Extension (section 3.2.), + Revocation Messages (section 3.3.), and Revocation Acknowledgment + + + + +Glass & Chandra Standards Track [Page 5] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + (section 3.4.). It is not required that all agents advertising on + the same link support registration revocation, nor is it required + that an agent advertise this support on all of its links. + + Note that using this information, a mobile node can select a foreign + agent that supports Registration Revocation. Should a mobile node + not understand this bit, it simply ignores it as per [1]. + + As a bit in the agent advertisement, use of the 'X' bit has no impact + on other messages, such as e.g., Challenge-Response [2]. + +3.2. Revocation Support Extension + + The Mobile IP revocation support extension indicates support of + registration revocation, and so MUST be attached to a registration + request or registration reply by any entity that wants to receive + revocation messages. Normally, this is either a foreign agent, or a + home agent. However a 'direct' co-located mobile node MAY also + include a revocation support extension in its registration request. + A mobile node which is not co-located MUST NOT include a Revocation + Support Extension in its registration. + + A foreign agent advertising the 'X' bit on the link on which the + registration request was received, and that has a security + relationship with the home agent identified in the same registration + request, MUST attach a revocation support extension to the forwarded + registration request. A home agent that receives a registration + request that does not contain a revocation extension SHOULD NOT + include a revocation support extension in the associated registration + reply. + + 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 |I| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Timestamp | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type 137 + + + + + + + + +Glass & Chandra Standards Track [Page 6] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + Length + Length (in bytes, currently 6). Does NOT include Type + and Length fields (in accordance with section 1.9. of + [1]). This allows for a longer extension length should + more bits be required in the future. + + Timestamp + Current 4-byte timestamp of the mobility agent or + 'direct' co-located mobile node. This is used to + identify the ordering of registrations as they are + forwarded, how they relate to the sending of any + revocation messages, and to identify the approximate + offset between the clocks of the mobility agents + providing support for this binding, or between a 'direct' + co-located mobile node and its home agent. + + '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 + (section 3.3.) + + When sent by a foreign agent in a registration request: + + If set to 1, the FA is willing to have the home agent use + the 'I' bit in the revocation process to determine + whether the mobile node should be 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 + whether or not 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. + + To preserve the robustness of the protocol, the + recommended default behavior for a foreign agent is to + inform the mobile node of its revocation as described in + Section 4.1. + + + +Glass & Chandra Standards Track [Page 7] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + Reserved + Reserved for future use. MUST be set to 0 on sending, + MUST be ignored on receiving. + + When appearing in a registration request, or registration reply, the + Mobile IP revocation 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], or perhaps IPsec. If the extension appearing in either of these + registration messages is NOT protected, the appropriate action as + described by [1] (Sections 3.8.2.1. and Sections 3.7.3.1.) MUST be + taken. + + Support of the 'I' bit is OPTIONAL. If a mobility agent does not + support the specified functionality, it MUST set the 'I' bit to zero. + Note that the home agent setting the 'I' bit to '1' in response to a + revocation extension from the foreign agent in which the 'I' bit was + set to '0' is undefined, and SHOULD NOT be done. + + 'I' bit support has been negotiated when both agents have set the 'I' + bit to '1' in their revocation support extensions. + + It is important to note that this extension is skippable (i.e., if + the receiving mobility agent does not understand this extension, it + MUST skip it, and continue processing the remainder of the + registration request). + +3.3. Registration Revocation Messages + + A revocation message is sent by a mobility agent to inform another + mobility agent, or a 'direct' co-located mobile node, that it is + revoking the binding of a mobile node. + + 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 (that is the address + identified as the home address of this + binding). + + In the case of the foreign agent issuing the + registration revocation, the address + registered with the home agent as the care-of + address. + + + + + +Glass & Chandra Standards Track [Page 8] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + Destination Address In the case of the home agent issuing the + registration revocation, the source address + of the last approved registration request for + this binding, i.e., the destination address + of the last registration reply indicating + success for this binding. + + 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 | Reserved |A|I| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Home Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Home Domain Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Foreign Domain Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Revocation Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Extensions... + +-+-+-+-+-+-+-+-+-+-+-+-+- + | Authenticator... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Type 7 + + Reserved MUST be sent as 0, ignored when received. + + A Agent bit ('direction' bit). + + This bit identifies the role of the agent sending the + revocation, that is the 'direction' of the revocation + message. This is useful for detecting reflection + + + +Glass & Chandra Standards Track [Page 9] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + attacks, particularly when symmetric keying is being + used. + + Set to '0' if the revoking agent is servicing this + binding as a foreign agent. + + Set to '1' if the revoking agent is servicing this + binding as a home agent. + + 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' to request that 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. + + When sending a revocation message to a 'direct' co- + located mobile node, this bit is essentially irrelevant, + but SHOULD be set to '1'. + + When sent by the foreign agent: + + Set to '0' to indicate that the foreign agent is using + foreign domain policy as to whether or not the mobile + node should 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. + + Reserved + MUST be sent as 0, ignored when received. + + Home Address + The home IP address of the mobile node whose registration + is being revoked. + + + + + + +Glass & Chandra Standards Track [Page 10] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + Foreign Domain Address + The relevant IP address in the foreign domain to identify + which binding is being revoked. This is one of the + following: (i) the foreign agent's IP address, or (ii) + the co-located care-of address. + + Home Domain Address + The IP address of the home agent to identify which + binding is being revoked. + + Revocation Identifier + Protects against replay attacks. The revoking agent MUST + insert its current 4-byte timestamp running off the same + clock as it is using to fill in the timestamp in its + revocation extensions. See section 3.5. + + A registration revocation message MUST be protected by either a valid + authenticator as specified in [1], 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 'direct' co-located mobile node, or + another security mechanism at least as secure, and agreed upon by the + home and foreign domains, e.g., IPsec. If any agent, or 'direct' + co-located mobile node, receives a registration revocation message + that does not contain a valid authenticator, and is not adequately + protected, the revocation message MUST be ignored, and silently + discarded. + + A revocation message MUST NOT be sent for any registration that has + expired, and MAY only be sent prior to the expiration of a mobile + node's registration. Note, however, due to the nature of datagram + delivery, this does not guarantee these messages will arrive before + the natural expiration of any binding. + + An agent MUST NOT send more than one revocation message or + registration message per second for the same binding. Note that this + updates [1] by including revocation messages in the rate limit + specified in [1], i.e., that an agent MUST NOT send more than one + registration message per second for the same binding. + + An example of the use of revocation messages is given in Appendix A. + +3.4. Registration Revocation Acknowledgment Message + + A revocation acknowledgment message is sent by mobility agents or + 'direct' co-located mobile nodes to indicate the successful receipt + of a revocation message. + + + + +Glass & Chandra Standards Track [Page 11] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + 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. + + 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 | Reserved |I| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Home Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Revocation Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Extensions... + +-+-+-+-+-+-+-+-+-+-+-+-+- + | Authenticator... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Type 15 + + Reserved + MUST be sent as 0, ignored when received. + + I Inform bit. + + The 'I' bit MUST NOT be set to '1' in the revocation + acknowledgment messages unless it was set to '1' in the + revocation message. If an agent receives a revocation + acknowledgment message in which the 'I' bit is set to + '1', but for which the revocation message being + + + +Glass & Chandra Standards Track [Page 12] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + acknowledged had the 'I' bit set to '0', the 'I' bit in + the revocation acknowledgment message MUST be ignored. + + 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: + + Set to '1' to indicate to the home agent that the mobile + node was informed. + + Set to '0' to indicate to the home agent that the foreign + agent used local policy to determine whether or not the + mobile node should be informed. For purposes of protocol + robustness, it is highly recommended that such a default + be set for the foreign agent to inform the mobile node of + the revocation. + + Reserved + MUST be sent as 0, ignored when received. + + Home Address + The home address copied from the revocation message for + which this acknowledgment is being sent. + + Revocation Identifier + Copied from the Revocation Identifier of the revocation + message for which this acknowledgment is being sent. See + Section 3.5. + + A registration revocation acknowledgment message MUST be sent in + response to a valid and authenticated registration revocation + message. + + A registration acknowledgment message MUST be protected by either a + valid authenticator as specified in [1], 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 agent and 'direct' co-located mobile node, or another + security mechanism at least as secure and agreed upon by the home and + foreign domains, e.g., IPsec. + + + + + +Glass & Chandra Standards Track [Page 13] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + An example of the use of Revocation Acknowledgment Messages is given + in Appendix A. + +3.5. Replay Protection + + As registration revocation messages are designed to terminate service + for a mobile node, or multiple mobile nodes simultaneously, 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 + "active" attack). See Section 6. for a discussion of these security + considerations. + + All Revocation Messages and Revocation Acknowledgment Messages MUST + be authenticated as well be replay-protected. The order in which + they are done, however, is up to implementation. + + Replay protection is handled with a simple timestamp mechanism, using + a single 32-bit identifier field in the registration revocation + message, in conjunction with the home address field, to associate any + revocation acknowledgment messages with its revocation messages. To + do this: + + - The revoking agent sets the 'A' bit to its agent-type, and the + Revocation Identifier field in the registration revocation message + to a valid 32-bit timestamp from the same clock it is using to set + the timestamp field of its revocation extensions included in + registration messages. + + - Upon receipt of an authenticated revocation message, the receiving + agent (or 'direct' co-located mobile node) MUST check the value of + the 'A' bit, and Revocation Identifier to make sure this + revocation message is not a replay of an old revocation message + received from the same agent. The receiving agent MUST also check + that the message is not a reflection of a revocation message it + sent in relation to the identified binding. If the 'A' bit and + Identifier field imply this packet is a replay, the revocation + message MUST be silently discarded. + + - When building a revocation acknowledgment message, the + acknowledging agent (or 'direct' co-located mobile node) copies + the values of the Home Address and Revocation Identifier fields + from the revocation message into the Home Address and the + Revocation Identifier of the revocation acknowledgment message. + This is so the revoking agent can match this revocation + acknowledgment to its corresponding revocation message. + + + + +Glass & Chandra Standards Track [Page 14] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + - Upon receiving a valid revocation acknowledgment, the revoking + agent MUST check the Home Address and Identifier fields to make + sure they match those fields from a corresponding revocation + message it sent to the acknowledging agent. If not, this + revocation acknowledgment message MUST be silently discarded. + + Note that since the Identifier in an incoming revocation message is a + 32-bit timestamp, it is possible for an agent to check the validity + of the Identifier fields without having to remember all identifiers + sent by that corresponding agent. + + 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 guarantee that clocks on different agents will be + synchronized. For example, if a mobile node has simultaneous + bindings with multiple foreign agents, and if revocation messages are + received by more than one such foreign agent "simultaneously", it is + possible the revocation message from one of these foreign agents may + contain Identifier fields that happen to match those of any or all + the other foreign agents. This MUST NOT result in any of these + revocation messages being ignored. + +4. Registration Revocation Overview + + Registration Revocation consists of two distinct pieces: a signaling + mechanism between tunnel endpoints, and a signaling mechanism between + foreign agent and mobile node. A 'direct' co-located mobile node MAY + implement revocation extensions and revocation acknowledgment in + order to receive and respond to revocation messages from its home + agent, however, a 'direct' co-located mobile node MUST NOT send a + revocation message as de-registration messages defined in [1] are + sufficient for this purpose. + + For further discussion on security issues related to registration + revocation, refer to Section 6. + +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. + + A brief overview of the mechanics of the sequence number in agent + advertisement from [1] is given so that the mechanism by which the + foreign agent 'implies' to the mobile node that its binding is no + longer active is clearly understood. + + + +Glass & Chandra Standards Track [Page 15] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + 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, when the agent increments the sequence number counter + past its maximum value, it sets the sequence number to 256 instead of + rolling to 0 [1]. 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 of 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 + to it that they should re-register with a different foreign agent by + simultaneously 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], [D]. 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 its + 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 that 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' bit set to 1. It should be noted, though, + that since the foreign agent is likely to not be setting the 'B' bit + + + +Glass & Chandra Standards Track [Page 16] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + 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 on 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 can 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 re-register with the same foreign agent, or register with + a different foreign agent, 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 to protect from denial- + of-service attacks. + +4.2. Registration Revocation Mechanism - Agent Notification + + A foreign agent that is currently supporting registration revocation + on a link MUST set the 'X' bit in its Agent Advertisement Extensions + being sent on that link. This allows mobile nodes requiring + Registration Revocation services to register with those foreign + agents advertising its support. + +4.2.1. Negotiation of Revocation Support + + During the registration process, if the foreign agent wishes to + participate in revocation messages with the home domain, it MUST have + an existing security association with the home agent identified in + the registration request, and append a revocation support extension + (defined in Section 3.2.) to it. If the corresponding registration + reply from this home agent does not contain a revocation support + extension, the foreign agent SHOULD assume the home agent does not + understand registration revocation, or is unwilling to participate. + If this is unacceptable to the foreign agent, it MAY deny the + registration with e.g., "Administratively Prohibited". Note that in + this case, where a security association exists, as specified in [1], + both registration request and registration reply MUST still contain + home-foreign authenticators. + + If a home agent wishes to be able to exchange revocation messages + with the foreign domain, it MUST have an existing security + association with the foreign agent who relayed the registration + request, and it MUST append a revocation support extension to the + + + +Glass & Chandra Standards Track [Page 17] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + registration reply. If the registration request from a foreign agent + did not contain a revocation support extension, the home agent SHOULD + assume the foreign agent does not understand registration revocation, + or is unwilling to participate specifically for this binding. If + this is unacceptable to the home agent, it MAY deny the registration + with e.g., "Administratively Prohibited". The home agent MAY include + a revocation support extension in the registration reply. + + If a 'direct' co-located mobile node wishes to be informed of a + released binding by its home agent, it MUST insert a revocation + support extension into the registration request. If this is + acceptable to the home agent, it MUST include a revocation support + extension in its registration reply. Note that if this is not + acceptable, the home agent MAY deny the registration, or it MAY + simply not include a revocation support extension in its registration + reply indicating to the mobile node that it will not participate in + revocation for this binding. A home agent which receives a + registration request from a 'direct' co-located mobile node which + does not contain a revocation support extension MAY deny the + registration with e.g., "Administratively Prohibited" and also MAY or + MAY NOT include a revocation support extension in the registration + reply. + + Note that a non-colocated mobile node MUST NOT insert a revocation + support extension into its registration request. If a foreign agent + receives such a registration request, it MUST silently discard it, + and MAY log it as a protocol error. + + The 'I' bit in the revocation extension is used to indicate whether + or not the decision to inform the mobile node that its binding is + terminated will be left to the home agent. 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 that its registration is terminated up 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. + + Revocation support is considered to be negotiated for a binding when + both sides have included a revocation support extension during a + successful registration exchange. + + + + + +Glass & Chandra Standards Track [Page 18] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + +4.2.2. Home 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 home domain is revoking a registration. + +4.2.2.1. Home Agent Responsibilities + + In the case where a home agent is revoking 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 care-of address, or the co- + located care-of address of a 'direct' co-located mobile node. + + As a home agent, it MUST set the 'A' bit to '1', indicating this + packet is coming from the home agent servicing this binding. + + When a 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. Note that the home agent could also + set the 'I' bit to '0' because it knows the mobile node has + registered with a different foreign agent, and so there is no need + for the foreign agent to attempt a notification. + + The home agent MUST set the Identifier field as defined in Section + 3.5., and MUST include a valid authenticator as specified in Section + 3.3. + + If the home agent does not receive a revocation acknowledgment + message within 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 limited by the + requirement that: + + - every time the home agent is about to retransmit the revocation + message, it MUST update the value of the timestamp in the + revocation identifier with a current value from the same clock + used to generate the timestamps in the revocation extensions sent + to this foreign agent. Note that this also necessarily means + updating any fields derived using the revocation identifier (e.g., + a home-foreign authenticator). + + - the home agent MUST NOT send more than one revocation per second + for a particular binding, + + + +Glass & Chandra Standards Track [Page 19] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + - the time between retransmissions SHOULD fall-back in analogy with + the registration guidelines in [1], namely exponential backoff, + and + + - the home agent MUST NOT retransmit revocation messages beyond the + normal life of the binding identified by the revocation message. + +4.2.2.2. Foreign Agent Responsibilities + + Upon receiving a registration revocation message, the foreign agent + MUST check that the validity of the authenticator, the 'A' bit, and + the identifier field against replay as defined by Section 3.5. The + foreign agent MUST also identify the binding 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, the home domain address, as well as the + timestamp in the revocation message, and also the timestamp in the + last accepted registration message; revocations are only valid for + existing registrations, and so the timestamp of a registration MUST + precede the revocation message (note that both of those timestamps + were set by the same home agent). Upon locating the binding, the + foreign agent MUST revoke it, and MUST respond with a revocation + acknowledgment sent to the source address of the revocation message. + If the 'I' bit was 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 + acknowledgment to be sent to the home agent, or if not notifying the + mobile node, the foreign agent MUST set the 'I' bit to '0'. + + The foreign agent may discontinue all Mobile IP services by the + former binding at this time, and free up any resources that were + being used by it. + + The foreign agent MUST then generate a revocation acknowledgment, + setting the Home Address and Identifier field in the revocation + acknowledgment message as described by Section 3.5., and protect it + with a valid authenticator as specified in Section 3.3. + +4.2.2.3. 'Direct' co-located mobile node Responsibilities + + Upon receiving a revocation message, the 'direct' co-located mobile + node MUST validate the authenticator, and check the home address and + identifier specified in the revocation message for replay. If the + packet passes authentication, and the identifier reveals this + revocation to be new, the mobile node MUST verify that the + information contained in the revocation messages identifies the home + + + +Glass & Chandra Standards Track [Page 20] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + 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 first generate a revocation + acknowledgment message which MUST be sent to the IP source address of + the revocation message. The mobile node may then terminate any + reverse tunnel encapsulation [C] it is using to this home agent, and + consider its binding revoked, and free up any other resources + associated with the former binding. + +4.2.3. 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. Note + that revocation support for a co-located mobile node registering via + a foreign agent (because the 'R' bit was set in the agent's + advertisement) is not supported. See Section 4.3.1. for details. + +4.2.3.1. Foreign Agent Responsibilities + + If the use of the 'I' bit was negotiated, and the foreign domain + 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 was to not notify the + mobile node, or if it 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 that the 'A' bit MUST be set to '0' to indicate that the + revocation message is coming from the foreign agent servicing this + binding. + + Before transmitting the revocation message, the foreign agent MUST + set the revocation identifier as described by section 3.5., and MUST + include an authenticator as described by section 3.3. + + If the foreign agent does not receive a revocation acknowledgment + message within a reasonable amount of time, it MUST retransmit the + revocation message. How long the foreign agent waits to retransmit, + and how many times the message is retransmitted is only limited by + the following specifications: + + + +Glass & Chandra Standards Track [Page 21] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + - every time the foreign agent is about to retransmit the revocation + message, it MUST update the value of the timestamp in the + revocation identifier with a current value from the same clock + used to generate the timestamps in the revocation extensions sent + to this home agent. Note that this also necessarily means + updating any fields derived using the revocation identifier (e.g., + a home-foreign authenticator). + + - 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], namely exponential backoff, and + + - MUST NOT retransmit revocation messages beyond the normal life of + the binding identified by the revocation message. + +4.2.3.2. Home Agent Responsibilities + + Upon receiving a registration revocation message, the home agent MUST + check the 'A' bit, and identifier field, as well as the + authenticator. If the packet is acceptable, the home agent MUST + locate the binding 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. As revocations are only valid for + existing registrations, the timestamp of a registration MUST precede + the revocation message (note that both of those timestamps were set + by the same foreign agent). Since this binding is no longer active, + the home agent can free up any resources associated with the former + binding and discontinue all Mobile IP services for it. + + Upon processing a valid registration 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 Home Address, and Revocation Identifier + fields as described by Section 3.5., and protect the revocation + acknowledgment message with a valid authenticator as specified in + Section 3.3. + + + + +Glass & Chandra Standards Track [Page 22] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + +4.2.4. 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 ('direct' co- + located mobile node), or registered via a foreign agent, and wishes + to terminate its 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]. + +4.3. Mobile IP Registration Bits in the Revocation Process + + Several of the bits used in the registration process need special + consideration when using the revocation mechanism. + +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 (and whose registration would otherwise + by-pass the foreign agent), to register with the foreign agent.) + However, in this case, the foreign agent SHOULD deny a registration + request as "Administratively Prohibited" from a mobile node that is + registering in a co-located fashion. The reason being that the + foreign agent will not be able to revoke the binding of a co-located + mobile node due to reasons outlined in Section 4.3.2. + + How the foreign agent and/or foreign domain enforce the 'R' bit is + beyond the scope of this document. + +4.3.2. The 'D' bit in Use + + A mobile node registering directly with its home agent in a co- + located fashion with the 'D' bit set in its registration request is + supported in registration revocation. However, support for a co- + located mobile node (with the 'D' bit set in its registration + request) registering via a foreign agent is not supported for the + following reasons. + + Registration requests where the 'D' bit is set, and which are relayed + through a foreign agent (e.g., due to the advertising of the 'R' bit) + should theoretically contain the foreign agent address as the source + address of the registration request when received by the home agent. + A home agent may conclude that the source address of this + registration request is not the same as the co-located care-of + address contained in the registration request, and is therefore + likely to be the address of the foreign agent. However, since there + is no way to guarantee that this IP source address is in fact an + + + +Glass & Chandra Standards Track [Page 23] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + address of the foreign agent servicing the mobile node, accepting a + revocation message from this IP source address may lead to a denial- + of-service attack by a man-in-the-middle on the mobile node. + + Moreover, there is currently no method for the foreign agent + servicing the mobile node to identify itself to the home agent during + the Mobile IP registration phase. Even if a foreign agent could + identify itself, the co-located mobile node would also need to + authorize that this foreign agent is indeed the agent that is + providing it the Mobile IP services. This is to thwart a denial-of- + service attack on the mobile node by a foreign agent that has a + security association with the home agent, and is on the path between + the co-located mobile node and the home 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. + +6. Security Considerations + + There are two potential vulnerabilities, one in the agent + advertisement mechanism, and one related to unauthorized revocation + messages. + +6.1. Agent Advertisements + + Although the mechanisms defined by this document do not introduce + this problem, it has been recognized that agent advertisements as + defined in [1] subject mobile nodes to a denial-of-service potential. + This is because the agent advertisement 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 particular foreign agent into + believing all their registrations have been lost. + + There has been some work in this working group and others (e.g., + IPsec) to secure such router advertisements, though at the time of + this publication, no solutions have become common practice. 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 + which do not emanate from the same link-address (when present) as + + + +Glass & Chandra Standards Track [Page 24] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + other agent advertisements supposedly from the same agent, or even + that of the last successful registration reply, be silently + discarded. + +6.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 believes that the other agent has revoked a binding. + 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 mobile-foreign authenticators, but these have no direct + relation to registration revocation. + + RFC 3344 [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. All foreign and + home agents MUST support protection of revocation messages via the + foreign-home authenticators defined in [1]. They MAY implement other + mechanisms of equal or greater strength; if such mechanisms are known + to be available to both parties, they MAY be used instead. + + Revocation messages are at least as secure as registration messages + passed between home and foreign agents and containing home-foreign + authenticators as defined in [1]. Thus, there are no new security + threats introduced by the revocation mechanism other 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 active 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 was deemed valid, without replay protection, 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," a man-in-the-middle captures + a revocation message, then returns it to its originator at a later + time. If the security association between home and foreign domains + uses a security association involving 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 + + + +Glass & Chandra Standards Track [Page 25] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + protection, the sender of the packet will also believe the revocation + message to be authentic. + + The replay protection mechanism used by the revocation messages + defined by this document is designed to protect against both of these + active 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 new message is found to have been + generated after that of the time-stamp in the last revocation message + received, 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, ignoring any revocation message should + result in the retransmission of another revocation message, this time + with timestamp later than the last one received. + + Note that any registration request or reply can be replayed. With + the exchanging of time-stamps by agents in revocation extensions, an + agent should have a belief that such messages have been delivered in + a timely manner. For purposes of registration revocation, the + timeliness of a registration packet is simply based on the + granularity of each registration. Since [1] provides a replay + mechanism for the home agent to use, it has a way to tell if the + registration request being presented to it is new. The foreign + agent, however, has no such mechanism in place with the mobile node. + Foreign agents are advised to continue to consider registrations + 'outstanding' until the associated registration reply is returned + from the home agent before using the information in any of its + visitor entries. Even so, this leaves the foreign agent open to a + potential denial of service attack in which registration requests and + replies are replayed by multiple nodes. When this happens, the + foreign agent could be lead to believe such registrations are active, + but with old information, which can have adverse effects on them, as + well as to the ability of that agent to successfully use the + procedures outlined in this document. Sufficient protection against + this scenario is offered by the challenge-response mechanism [2] by + which a foreign agent generates a live challenge to a mobile node for + the purposes of making sure, among other things, that the + registration request is not a replay. + + + + +Glass & Chandra Standards Track [Page 26] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + +7. IANA Considerations + + This document defines an additional set of messages between the home + and foreign agent specific to the services being provided to the same + mobile node, or sub-set of mobile nodes. To ensure correct + interoperation based on this specification, IANA has reserved values + in the Mobile IP number space for two new message types, and a single + new extension. + +7.1. New Message Types + + The following message types are introduced by this specification: + + Registration Revocation: A new Mobile IP control message, using UDP + port 434, type 7. This value has been taken from the same number + space as Mobile IP Registration Request (Type = 1), and Mobile IP + Registration Reply (Type = 3). + + Registration Revocation Acknowledgment: A new Mobile IP control + message, using UDP port 434, type 15. This value has been taken from + the same number space as Mobile IP Registration Request (Type = 1), + and Mobile IP Registration Reply (Type = 3). + +7.2. New Extension Values + + The following extensions are introduced by this specification: + + Revocation Support Extension: A new Mobile IP Extension, appended to + a Registration Request, or Registration Reply. The value assigned is + 137. This extension is derived from the Extension number space. It + MUST be in the 'skippable' (128 - 255) range as defined in RFC 3344. + +7.3. New Error Codes + + There are no new Mobile IP error codes introduced by this document. + +8. References + +8.1. Normative References (Numerical) + + [1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, + August 2002. + + [2] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response + Extensions", RFC 3012, November 2000. + + [3] Bradner, S., "Key Words for us in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + +Glass & Chandra Standards Track [Page 27] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + +8.2. Informational References (Alphabetical) + + [A] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP + Authentication, Authorization, and Accounting Requirements", RFC + 2977, October 2000. + + [B] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., + Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil, + B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham, + S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., + Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and + E. Jaques, "Criteria for Evaluating AAA Protocols for Network + Access", RFC 2989, November 2000. + + [C] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", + RFC 3024, January 2001. + + [D] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, + September 1991. + + [E] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier + Extension for IPv4", RFC 2794, March 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Glass & Chandra Standards Track [Page 28] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + +Appendix A: An Example of the Revocation Messages in Use + + For clarity, the following example is meant to illustrate the use of + the new messages in the registration phase, and the revocation phase. + In this example, a foreign agent and home agent will negotiate + revocation during the registration phase. During the revocation + phase, the foreign agent will revoke the binding of a mobile node. + +A.1. The Registration Phase + + Consider a foreign agent that supports registration revocation, and + has a security association with a home agent to which it is + forwarding a registration request. The foreign agent will include + the revocation support extension after the mobile-home authenticator. + Assume that 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. Thus, the foreign + agent will set the 'I' bit to '1'. The foreign agent will append a + foreign-home authenticator to the registration request. + + Upon receiving the registration request containing a revocation + extension, the home agent will include a revocation support extension + in the registration reply. Since the foreign agent set the 'I' bit + to '1' in its revocation extension, and the home agent supports the + use of the 'I' bit, the home agent will set the 'I' bit in its + registration extension to '1'. Additionally, the home agent will + append a home-foreign authenticator to the registration request. + + Upon receiving the authenticated registration reply, the foreign + agent will check the revocation support extension and note that the + home agent wants to decide if the mobile node should be notified in + the event this registration is revoked, i.e., since the home agent + set the 'I' bit in the return revocation extension. + +A.2. The Revocation Phase + + The foreign agent revokes a mobile node's binding, and generates a + revocation message to be sent to the mobile node's home agent. Since + the 'I' bit was negotiated in the revocation extensions, and the + foreign agent is still willing to let the home agent indicate whether + this mobile node should be informed about the revocation, it will set + the 'I' bit to '1' in the revocation message. The foreign agent also + makes sure the 'A' bit is set to '0'. + + 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 the mobile node registered as the care-of address in the + foreign domain field, and the address registered as the home agent in + + + +Glass & Chandra Standards Track [Page 29] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + the home domain address field. The foreign agent will set the + Revocation Identifier to the current 32-bit timestamp, and append the + foreign-home authenticator. + + Upon receiving the above revocation message, the home agent uses the + address identified as the foreign domain address to identify the + security association, and authenticate the revocation message. After + authenticating the message, the home agent will check to make sure + the 'A' bit and Identifier indicate that this revocation is not a + replay. The home agent then uses the mobile node home address, + foreign domain address, and home domain address to locate the mobile + node whose registration is being revoked. + + Upon processing a valid registration revocation message, the home + agent generates a revocation acknowledgment message. Since the 'I' + bit was set to '1' in the revocation message and the home agent + wishes for the identified mobile node to be informed of the + revocation, it will set the 'I' bit in the revocation acknowledgment + to '1'. The home agent then copies the home address and the + Revocation Identifier field into the revocation acknowledgement. The + home agent protects the revocation acknowledgment with a home-foreign + authenticator. + + Upon receiving a valid revocation acknowledgment (in which the + authenticator and Identifier fields are acceptable), the foreign + agent checks the state of the 'I' bit. Since the 'I' bit is set to + '1', the foreign agent will notify the mobile node of the revocation. + +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. + + + + + + +Glass & Chandra Standards Track [Page 30] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + + Another way of understanding this is that the tunnel endpoints 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 its 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 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. 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. + + + + + + + + + + + + + + +Glass & Chandra Standards Track [Page 31] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + +Acknowledgments + + The authors would like to thank Rajesh Bhalla, Kent Leung, and Alpesh + Patel for their contributions to the concepts detailed in + draft-subbarao-mobileip-resource-00.txt, "Releasing Resources in + Mobile IP," from which the revocation support extension, and the + acknowledgment mechanism contained in this document were derived. + + The authors would also like to thank Pete McCann for his discussions + on replay mechanisms, and security concerns, and Ahmad Muhanna for + pointing out a problem with the initial replay mechanism, which + eventually lead to the addition of a time stamp to the Revocation + Extension. + + The authors would also like to acknowledge Henrik Levkowetz for his + detailed review of the document, and Michael Thomas for his review of + the replay mechanism described herein. + +Authors' Addresses + + Steven M. Glass + Solaris Network Technologies + Sun Microsystems + 1 Network Drive + Burlington, MA. 01801 + + Phone: +1.781.442.0000 + Fax: +1.781.442.1706 + EMail: steven.glass@sun.com + + + Madhavi W. Chandra + IOS Technologies Division + Cisco Systems + 7025 Kit Creek Road + Research Triangle Park, NC 27709 + + Phone: +1.919.392.8387 + EMail: mchandra@cisco.com + + + + + + + + + + + + +Glass & Chandra Standards Track [Page 32] + +RFC 3543 Registration Revocation in Mobile IPv4 August 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 assignees. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Glass & Chandra Standards Track [Page 33] + |