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