Internet Engineering Task Force S. Glass
INTERNET DRAFT Sun Microsystems
M. Chandra
Cisco Systems
March 2002
Registration Revocation in Mobile IP
draft-ietf-mobileip-reg-revok-02.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 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 an
active revocation mechanism explicitly for the purpose of registration
revocation, a passive mechanism, namely short registration lifetimes,
and the denial of a subsequent registrations from a mobile node, would
likely 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 whereby both domains providing
Mobile IP services are aware that the service is being suspended.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 1
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
In the ideal model, revocations must be possible from either home
or foreign domains, and any registration revocation mechanism being
defined must also provide a signaling mechanism between the two that
the current registration has been released, Mobile IP services are no
longer being provided on one side of the registration, so they need
not be provided on the other. In some cases the current registration
may be terminated to simply force the mobile node to renegotiate its
registration, but in other cases, where no renegotiation will be
considered by the terminating side, this should be communicated.
Moreover, there should also be a mechanism in place whereby the
mobile node whose registration has been terminated can also be
informed that such a revocation has occurred, 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.
This document defines such a general use registration revocation
mechanism meeting these requirements.
Table of Contents:
1. Introduction................................................. 2
2. Motivation................................................... 4
3. Registration Revocation Overview............................. 5
3.1 Mobile Node Notification.................................. 5
3.2 Registration Revocation Mechanism - Notification.......... 7
3.2.1 Home Domain Revoking a Registration................... 8
3.2.2 Foreign Domain Revoking a Registration................ 9
3.2.3 Mobile Node De-registering a Registration............. 9
3.3 The Use of Bits...........................................10
3.3.1 The 'R' Bit in Use....................................10
3.3.2 The 'D' Bit in Use....................................11
4. Revocation Messages Formats...................................12
4.1 Revocation Support Extension..............................12
4.2 Revocation Message........................................13
4.2.1 Revocation Mask.......................................16
4.2.2 Replay Protection.....................................18
4.3 Revocation Acknowledgement Message........................19
4.4 An Example of the New Messages in Use.....................21
4.4.1 The Registration Phase................................21
4.4.2 The Revocation Phase..................................22
5. No New Error Codes...........................................23
6. Multiple Binding Support.....................................23
6.1 Other Random Protocol Details.............................24
7. Security Considerations......................................24
Appendix A: Registration Revocation in 'R' and 'D' Bit Worlds....26
Appendix B: Disparate Address, and Receiver Considerations.......27
Acknowledgements.................................................29
Where to Direct Comments.........................................29
References.......................................................30
Full Copyright Statement.........................................31
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 2
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
1. Introduction
During the original design of Mobile IP, the need for an
administrative domain to be able to actively 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,
Was sufficient for this purpose. Investigations into the requirements
for a AAA protocol specific to Mobile IP have forced reconsideration
of a more pro-active Mobile IP registration revocation feature whereby
if either domain wishes to revoke a current registration, this can be
communicated to the other mobility agent providing mobile ip services
for the mobile node in question, and potentially also have said mobile
node informed that it is no longer receiving mobile ip services.
A mobility agent which receives a revocation notification no
longer has to provide services to the mobile node whose registration
has been revoked. This means resources being 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.
Moreover, should foreign domain policy allow for it, informing the
mobile node that it is no longer being provided mobile ip services
enables it to react faster than if it had to discover this for itself
(likely by having its attempt to reregister denied).
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 either [1] (or [2]) 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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 3
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
The mechanism described in this document differs from the methods
described in [1] for de-registration messages as they apply to
situations where the mobile node is playing the active role in
informing the home agent of its location when it has roamed (back)
home. The mechanism described here is for mobility agents playing the
active roll in ending the mobile node's service, and 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] (or [2]), and [7]. Knowledge of the concepts
of [3] and [4] is also be beneficial.
2. Motivation
Mobile IP [1], ([2],) [4] 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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 4
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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
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 the sending of revocation messages as deregistration
messages defined in [1] (and [2]) 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 Acknowledgement 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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 5
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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,
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] (or [2]) 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 [2] and [6], 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] (or [2]) 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
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 6
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
time, any mobile node may use foreign agent fallback to attempt to
register with a different foreign agent as described in [1]. Mobile
nodes which understand this revocation mechanism could understand that
a unicast agent advertisement with the 'B' bit set in this scenario
could indicate a revocation, and could 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]
(or [2]), even if their 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 [8].
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, and 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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 7
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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
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 acknowledgement 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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 8
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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
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 acknowledgement 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 [4]. If a co-located mobile node
receives an authenticated registration revocation from its home agent,
a mobile node MAY generate a revocation acknowledgement message in
response. In this scenario, the mobile node MUST include a
Mobile-Home authenticator.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 9
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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.
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
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 10
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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
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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 11
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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.
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 [5] and is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |A|I| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Skippable (TBD) See below.
Length
Length (in bytes). Does NOT include Type and Length.
'A' Bit
When this bit is set to '1', the mobility agent is
specifying that it will send an revocation
acknowledgement in receipt of a registration
revocation message.
'I' Bit
This bit is set to '1' by a mobility agent to indicate
it supports the use of the 'I' bit in revocation
messages (see section 4.2 below).
Reserved
Reserved for future use. MUST be set to 0 on sending,
MUST be ignored on receiving.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 12
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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 [1],
e.g. AAA [A], [B]. If the extension appearing in either of the above
registration messages is NOT protected, the approprate action as
described by [1] MUST be taken.
It is important to note that this extension is of the skippable
variety, that is if the receiving mobility agent doens't understand
this extension, it is to skip it, and continue processing the
registration request. This is so a home agent will continue
processing the registration request a foreign agent has forwarded to
it, and send a registration reply even though the home agent doesn't
support registration revocation. In this way, if local policy in the
foreign domain requires registrations must be made with home agents
which support this feature, the foreign agent may actively deny the
registration with this home agent (and indicate this to the mobile
node). In contrast, if this extension were not skippable, a home
agent which doesn't understand this extension would be silently
discarding the registration, and there would be no feedback to either
the foreign agent, or the mobile node.
4.2 Revocation Message
The format of revocation message is analogous to registration
request and registration reply messages.
IP fields:
Source Address In the case of the home agent issuing the
registration revocation, the address
registered with the care-of address (and
therefore registered with the foreign
agent if one was privy to the
registration) as that of the home agent.
In the case of the foreign agent issuing
the registration revocation, if the
registration being revoked is NOT for a
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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 13
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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
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|I| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Domain Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Domain Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Domain Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 14
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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
acknowledgement of the revocation message, or in any
revocation response message.
Set to '1' when the revoking agent would like
acknowledgement 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.
I Inform bit.
If sent by the home agent:
Set to '0' when the mobile node should NOT be informed
of the revocation.
Set to '1' to request that the mobile node be informed
of the revocation.
If sent by the foreign agent:
Set to '1' to ask the home agent if the mobile node
should be informed of the revocation.
This bit SHOULD only be used if used in the revocation
extension messages pass in the registration process.
Note: if the policy of the foreign domain mandates
whether the mobile node is to be informed of the
revocation, the foreign agent should set the 'I' bit to
'0', and ignore the setting of the 'I' bit in any
revocation acknowlegement message. The foreign agent
MAY also choose to not indicate its support of the 'I'
bit in the revocation extension during the registration
process. Furthermore, the setting of the 'I' bit to
'0' by the foreign agent MUST NOT imply to the home
agent that the foreign agent will not inform the mobile
node of the revocation; the home agent may send a
revocation acknowledgement message with the 'I' bet set
(see section 4.3 below).
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 15
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
reserved MUST be sent as 0, ignored when received.
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 Address
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.
Home Doman and Foreign Domain Identifier Fields
Each of these is a 32-bit number used for protecting
against replay attacks analogous to the use of
timestamps in [1]. See section 4.2.2 (below).
Other Extensions
Any relevent extensions for this registration
revocation. e.g. NAI extension.
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.
An example of the use of the revocation message is given in
section 4.4 below.
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:
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 16
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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's NAI in an NAI extension (appended).
0x20 Applies to all bindings with the same administrative domain
as the care-of address. (CoA-NAI present!?!)
0x40 Applies to all bindings with the same administrative domain
as the foreign agent. The issuing agent MUST include the
foreign agent NAI in an NAI extension (appended).
0x80 Applies to all bindings with the same administrative domain
as the home agent. The issuing agent MUST include the
home agent NAI in an NAI extension (appended).
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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 17
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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 [3]
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
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
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 18
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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 acknowledgement 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.
4.3 Registration Revocation Acknowledgement Message
The format of revocation acknowledgement message is analogous to
the revocation message, and hence registration request and
registration reply messages.
IP fields:
Source Address The destination address of the received
registration revocation message for which
this registration revocation
acknowledgement message is being generated.
Destination Address The source address of the received
registration revocation message for which
this registration revocation
acknowledgement message is being generated.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 19
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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|I| 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.
SHOULD be identical to the P bit in the registration
revocation message.
I Inform bit.
Set to '1' by the foreign agent to ask the home agent
if the mobile node should be informed of the
revocation.
Set to '1' by the home agent to request the foreign
agent inform the mobile node of the revocation.
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).
Other Extensions
Any relevent extensions for this registration
revocation. e.g. NAI extension.
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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 20
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
An example of the use of the revocation message is given in
section 4.4 below.
A registration revocation acknowledgement message MUST only be
sent in response to a registration revocation messages in which the
'A' bit was set to 1.
4.4 An Example of the New Messages in Use
For clarity, the following examples are meant to illustrate the
use of these messages in the registration phase, and the revocation
phase. In cases where there may be some question to the order of
processing, any order indicated by [1] MUST be followed.
4.4.1 The Registration Phase
A foreign agent that supports registration revocation, and has a
security association with a home agent to which it is forwarding a
registration request SHOULD include the revocation extension after the
Mobile-Home authentication. If the foreign agent wishes to receive a
revocation acknowledgement from the home agent in the event that the
registration for this mobile node is revoked, or if it is willing to
send a revocation acknowledgement message in response to a revocation
message from the home agent for this mobile node, it MUST set the 'A'
bit to '1'. Furthermore, if the foreign agent supports the use of the
'I' bit, and is willing to let the home agent decide if the mobile
node should be informed of the revocation of its registration, it
SHOULD set the 'I' bit to '1'. Additionally, the foreign agent MUST
append a Foriegn-Home authenticator to the registration request, and
include any other extension needed by the foreign agent to verify the
authenticator [1].
A home agent that supports registration revocation, and that
receives a registration request containing a revocation extension
SHOULD include a revocation extension in the registration reply after
the Home-Mobile authenticator. If the home agent wishes to receive a
revocation acknowledgement message from the foreign agent in the event
that the registration for this mobile node is revoked, or if it is
willing to send a revocation acknowledgement message in respone to a
revocation message from the foreign agent for this mobile node, it
MUST set the 'A' bit to '1'. Furthermore, if the home agent supports
the use of the 'I' bit, and wishes to determine whether the foreign
agent informs the mobile node that its registration has been revoked,
it SHOULD set the 'I' bit to '1'. Additionally, the home agent MUST
append a Home-Foriegn authenticator, to the registration request, and
include any other extension needed by the foreign agent to verify the
authenticator [1].
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 21
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
Upon receiving the registration reply, the foreign agent SHOULD
check the revocation extension. If none is present, the foreign agent
MAY presume the home agent doesn't understand revocation messages. If
a revocation extension is present, the foreign agent SHOULD check the
'A' bit to see if the home agent will provide revocation
acknowledgement services (if they were requested), and SHOULD also
check the 'I' bit to see if the home agent want's it to ask if the
mobile node should be notified of the revocation of this
registration.
4.4.2 The Revocation Phase
If a foreign agent wishes to revoke a mobile node's 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 an
acknowledgement, places 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. If it
supports the 'I' bit, the foreign agent MAY set the I bit to '1' to
indicate to the home agent that the 'I' bit setting in the revocation
acknowledgement SHOULD indicate whether the mobile node SHOULD be
informed of the revocation. The foreign agent MUST also choose a
Foreign Domain Identifier that has not previously been used with this
home agent. The foreign agent MUST also append a foreign-home
authenticator (and any additional information it needs to include for
the home agent to validate it, e.g. its NAI extension).
Upon receiving the above revocation message, the home agent
assures the revocation is protected with a Foreign-Home authenticator.
If not, the message MUST be silently discarded. If the Foreign-Home
authenticator is present, the home agent 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 verify 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(s) whose registration(s) is/are being revoked. If the
home agent supports the use of the 'I' bit, it MAY check to see if the
'I' bit is set to '1' in the revocation message, or it MAY set the 'I'
bit to '1' in the revocation acknowledgement if it wishes the foreign
agent to notify the mobile node of this revocation. The home agent
then builds an Acknowledgement (since the "A" bit was set), copies the
addresses, and the ID field into the reply; it MUST protect the
revocation acknowledgement with a Home-Foreign authenticator (and any
other extension necessary for the foreign agent to authenticate the
Home-Foreign authenticator, e.g. its NAI extension).
Upon receiving a valid revocation acknowledgement, the foreign
agent SHOULD check the 'I' bit, and if set, SHOULD notify the mobile
node of the revocation, or if the 'I' bit is not set, SHOULD NOT
notify the mobile node of the revocation.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 22
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
5. No New 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. If any
registration revocation fails authentication, or replay protection (as
described in section 4 above), it MUST be silently discarded, and
Mobile IP services MUST NOT be 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
registration, and hence can be treated as a separate case for
registration revocation. Consider the situation where a mobile node
has multiple care-of addresses registered with a single foreign agent
(either because the mobile node has multiple co-located care-of
addresses and the foreign agent has the 'R' bit set, or because the
foreign agent is multi-homed). Either agent can indicate the
revocation of all these bindings by setting the care-of address field
to 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
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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 23
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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 [1]. As registration
revocation, when performed, terminates Mobile IP services being
provided to the mobile node, it is crucial that all security and
replay protection mechanisms be verified before a mobility agent
recognizes that the other agent has revoked a mobile node's binding,
and frees up the resources it has reserved for this service. Messages
which are sent link-local (e.g. between mobile node and foreign agent)
MAY also be secured by methods outlined in [1], but have no relation
to the enhancement(s) described by this document.
[7] describes the use of the Network Access Identifier in Mobile
IP. Its relavent use here is for agents to be able to identify each
other in a revocation message. In cases where foreign and home
domains are going to approve registrations from co-located mobile
nodes (registering with the 'D' bit [1]), and in topologies where the
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 24
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
foreign agent is setting the 'R' bit in its agent advertisements [1],
if the agents are to use their NAI's to identify themselves, the
security association they share MUST include the IP address the
registration revocation messages are to be sent to (and will be sent
from).
Note that registration requests where the 'D' bit is set, and
which are relayed through a foreign agent due to the advertising of
the 'R' bit contain the foreign agent address as the source address of
the registration request as received by the home agent.
For a more involved discussion, see Appendix A below.
It has been recognized that agent advertisements as defined in [1]
(and [2]) provide a denial-of-service potential [8]. This is because
the agent advertisements as defined in [1] (and [2]) 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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 25
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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.
- 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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 26
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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
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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 27
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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 August 2002 Page 28
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
Acknowledgements
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 acknowledgement 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 August 2002 Page 29
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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] IP Mobility Support for IPv4
RFC 3220, January 2002
C. Perkins, Editor.
Obsoletes [2].
[2] IPv4 Mobility Support
RFC 2002, October 1996
C. Perkins, Editor.
Obsoleted by [1], provided for reference, and the
compatibility of this specification with it.
[3] Reverse Tunneling for Mobile IP, revisited
RFC 3024, January 2001
G. Montenegro, Editor.
[4] Mobility Support in IPv6
work in progress, revision 13, November 2000
D. Johnson and C. Perkins.
[5] 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.
[6] ICMP Router Discovery Messages
RFC 1256, September 1991
S. Deering, Editor.
[7] Mobile IP Network Access Identifier Extension for IPv4,
RFC 2794, March 2000
P. Calhoun, C. Perkins.
[8] Security Issues in Mobile IP,
work in progress
S. Glass.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 30
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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.
Expires September 2002 draft-ietf-mobileip-reg-revok-02.txt Page 31
Datatracker
draft-ietf-mobileip-reg-revok-02
Internet-Draft
