| A mobility binding can be viewed as a contract between the Home Agent and CoA endpoint, which is either a FA or a colocated Mobile Nodes. In the metro mobility model, the contract is across different administrative domains because the Home Agent and FA are in different autonomous systems. During the lifetime of this contract, either Mobility Agent might want to prematurely terminate the binding, for example, for administrative reasons, and thus revoke the contract. Now, instead of waiting for the binding to expire on the peer Mobility Agent, wouldn't it be nice if the revoking Mobility Agent could somehow tell the peer agent that the binding is gone? This allows the peer agent to reclaim resources that it was using to service the Mobile Nodes. Wouldn't it be nice if resources could also be reclaimed when a Mobile Nodes moved from one FA to another FA? In base Mobile IP, the Home Agent would obviously learn about the new FA through a RRQ and, thus, update the mobility binding. However, the previous FA would have to maintain the visitor entry until it expired because it has no way of knowing that the Mobile Nodes moved on. Registration Revocation, as defined in RFC 3543, is an enhancement to Mobile IP that allows more efficient management of Mobile IP resources and services. It is an unobtrusive, yet proactive, feature that allows more timely communication between the different Mobile IP entities. Basically, Registration Revocation solves all the mobility problems. Okay, not really, but with Registration Revocation, you can accomplish the following: Timely release of Mobile IP resources Resources being consumed to provide Mobile IP services for a Mobile Nodes that has stopped receiving Mobile IP services by one agent can be reclaimed by the peer agent in a more timely fashion than if it had to wait for the mobility binding to expire. Early adoption of domain policy changes with regard to services offered/required of a Mobile IP binding For example, the home domain might now require reverse tunneling, yet existing mobility bindings do not use them. Without a revocation mechanism, new services can be put in place or removed only as bindings are reregistered. Timely notification to a Mobile Nodes that it is no longer receiving mobility services This significantly shortens any black-hole periods to facilitate a more robust recovery. Accurate accounting This has a favorable impact on resolving accounting issues with respect to the length of mobility bindings in both domains, because the end of the registration is relayed.
Resource Revocation Overview Resource revocation has a negotiation phase and a revocation phase. During the negotiation phase, the Mobility Agents agree to inform one another of revocations and exchange their clock timestamps so that they can be used during the revocation phase. They also negotiate whether the Mobile Nodes is to be informed of a revocation of its binding. During the revocation phase, the Mobility Agents inform one another when a mobility binding is revoked. The Mobile IP signaling that is involved in the negotiation phase and revocation phase can be summarized into the following four main components: The Mobility Agents advertise support for the revocation feature. This is accomplished by setting a newly defined X bit in the Mobile IP agent advertisement message. This allows Mobile Nodess to choose FAs that support revocation, if so desired. The X bit in agent advertisements is backward compatible, and if a Mobile Nodes does not understand the X bit, it simply ignores the bit. The Mobility Agents convey to one another that they are interested in receiving revocation messages upon early termination of a binding. They accomplish this by appending the Revocation Support Extension, as defined in RFC 3543, to the RRQ and RRP messages. Specifically, a FA can append the extension to a RRQ to start the negotiation phase. When the Home Agent receives the RRQ, it knows that the FA supports the revocation mechanism. In turn, if the Home Agent wants to participate in the revocation mechanism, it appends the extension to the RRP. When the FA receives the reply, revocation support is considered to be negotiated and the Mobility Agents have agreed to inform one another upon revocation (or early termination) of a binding. In the revocation extension, the Mobility Agent can also express whether it wants the Mobile Nodes to be informed upon revocation (or early termination) of the binding through the I bit in the extension. After negotiating and establishing use of the revocation mechanism for mobility binding(s), the Mobility Agents send reliable revocation messages that must be authenticated to one another upon revocation (or early termination) of a mobility binding. Revocation messages are sent reliably through an acknowledgment mechanism in an earnest effort to notify the peer agent so that the peer can also release the resources consumed in supporting the Mobile Nodes. Upon receiving a revocation message, the peer agent responds with a revocation acknowledgment message. If the Mobile Nodes should be notified that its binding has been revoked, the FA simply unicasts an agent advertisement with a [re]set sequence number of 0 to the Mobile Nodes. The Mobile Nodes understands that its mobility binding has been reset and that it must reregister, as discussed in Chapter 2.
If a colocated Mobile Nodes is registering directly with its Home Agent, with the D bit set in its RRQ and not registering through a FA, the Mobile Nodes can participate in a "one-sided" revocation mechanism. In this case, the Mobile Nodes and Home Agent negotiate the revocation mechanism as previously described. However, in the revocation phase, the Mobile Nodes can receive revocation messages from the Home Agent upon early termination of its binding by the Home Agent, but it does not send revocation messages in the reverse case. Revocation Support Extension and Messages All the messaging associated with the revocation mechanism must be secure because it is altering the status of mobility bindings. Otherwise, you can imagine that there would be some unhappy Mobile Nodess if their bindings were rudely revoked without proper authorization! To this end, the revocation messages and revocation support extension must be protected. If the communication is between Mobility Agents, a HAFA security association is used. If, however, the communication is being sent from a Home Agent to a "direct" colocated Mobile Nodes, a MNHA security association is used. In either case, another security mechanism at least as secure, and agreed upon by the home and foreign domains (for example, IPSec), can also be used. The important point is that the messages must be secured. In addition to authentication protection, the revocation messages are also protected against replay attacks and reflection attacks. Such protection is crucial to prevent denial-of-service attacks by rogue repeatersthose who store packets with the intent of replaying them at a later time, or by rogue reflectorsthose who reflect packets at their original source. So, how is all of this, coupled with revoking a mobility binding, accomplished with the revocation extension and messages? We now look into the relevant fields. The Revocation Support Extension has the following main fields: Timestamp This is the current timestamp of the Mobility Agent (or direct colocated Mobile Nodes). It identifies the offset between the clocks of the Mobility Agents providing support for this binding. The timestamp offset is used later during the revocation phase to provide replay and reflection attack protection. I bit This bit negotiates whether the Mobile Nodes is informed upon revocation (or early termination) of its binding during the revocation phase.
The following fields in the revocation messages uniquely identify mobility bindings and provide replay and reflection protection: A bit This bit identifies the role of the Revoking Agent. Specifically, it is set to 0 if the Revoking Agent is serving as the FA, and set to 1 if the Revoking Agent is serving as the Home Agent. I bit This bit is used only if it was negotiated in the revocation extension messages. It specifies whether the Mobile Nodes should be informed of the revocation, with the exact meaning depending on the role of the Revoking Agent, as specified in RFC 3543. Home Address This field specifies the home IP address of the Mobile Nodes whose registration is being revoked. Foreign Domain Address This field specifies the relevant IP address in the foreign domain to identify which binding is being revoked. This is one of the following: - FA's IP address - Mobile Nodes's CCoA
Home Domain Address This field specifies the IP address of the Home Agent to identify which binding is being revoked. Revocation Identifier This field protects against replay and reflection 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.
A subset of these fields is found in revocation acknowledgment messages, namely, the Home Address and Revocation Identifier, to uniquely map acknowledgment messages to revocation messages. Specific details and format of the Revocation Support Extension and revocation messages can be found in RFC 3543. Registration Revocation Example Consider an example that illustrates the revocation mechanism. In this example, a Mobile Nodes is registering through a FA that shares a security association with the Home Agent. Both Mobility Agents support the revocation mechanism: The FA sends an agent advertisement with the X bit set. The Mobile Nodes sends a RRQ through the FA. The FA appends the Revocation Support Extension to the RRQ and secures it with the FAHome Agent Authentication Extension. The FA sets the I bit in the extension to 1, indicating that it will let the Home Agent decide whether the Mobile Nodes should be notified if the binding is revoked. Upon receiving the RRQ containing a revocation extension, the Home Agent includes a Revocation Support Extension in the RRP. Because the FA set the I bit to 1 in its revocation extension, and the Home Agent supports the use of the I bit, the Home Agent sets the I bit in its registration extension to 1. The Home Agent appends the revocation extension to its RRP and secures it with a HAFA Authentication Extension. Upon receiving the authenticated RRP, the FA checks the Revocation Support Extension and notes that the Home Agent wants to decide whether the Mobile Nodes should be notified in the event that this registration is revoked, that is, because the Home Agent set the I bit in the return revocation extension. At a later time, the FA revokes the Mobile Nodes's binding and generates a revocation message to be sent to the Mobile Nodes's Home Agent. Because the I bit was negotiated in the revocation extensions and the FA is still willing to let the Home Agent indicate whether this Mobile Nodes should be informed about the revocation, it sets the I bit to 1 in the revocation message. The FA sets the A bit to 0, places the address of the Mobile Nodes whose registration it is revoking in the Home Address field, places the address that the Mobile Nodes registered as the CoA in the foreign domain field, and places the address registered as the Home Agent in the home domain address field. The FA sets the revocation identifier to the current 32-bit timestamp and appends the FAHA Authentication Extension. Upon receiving the above revocation message, the Home Agent uses the address specified as the foreign domain address to identify the security association and authenticates the revocation message. After authenticating the message, the Home Agent verifies that the A bit and revocation identifier indicate that this revocation is not a replay. The Home Agent then uses the Mobile Nodes Home Address field, the foreign domain address field, and home domain address field to locate the Mobile Nodes whose registration is being revoked. It deletes the mobility binding. Upon processing a valid registration revocation message, the Home Agent generates a revocation acknowledgment message. Because the I bit was set to 1 in the revocation message and the Home Agent wants the identified Mobile Nodes to be informed of the revocation, it sets 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 acknowledgment. The Home Agent protects the revocation acknowledgment with a HAFA Authentication Extension. Upon receiving a valid revocation acknowledgment (in which the authenticator and identifier fields are acceptable), the FA checks the state of the I bit. Because the I bit is set to 1, the FA notifies the Mobile Nodes of the revocation by unicasting an agent advertisement with a reset sequence number.
|
