Internet Engineering Task Force S. Glass
Mobile IP Working Group Sun Microsystems
Internet Draft M. Chandra
Cisco Systems
July 2002
Registration Revocation in Mobile IP
draft-ietf-mobileip-reg-revok-03.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.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page i
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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 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 can be made aware that the service is being suspended.
In the ideal model, revocations must be possible from either home
or foreign domains, so any registration revocation mechanism being
defined must provide a signaling mechanism between the two that
identify registration(s) being released, implying that since Mobile IP
services are no longer being provided on one side of the registration,
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 renegotiation may not
be allowed. Either one of these reasons is sufficient to justify this
mechanism.
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 immediately
relayed. This mechanism would ideally be independent of the
signaling mechanism between the agents identified above so as to
leave actual notification of the mobile node up to a separate policy
of the domains in question.
This document defines such a general use registration revocation
mechanism meeting these requirements.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page ii
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
Table of Contents:
1. Introduction................................................... 1
2. Motivation..................................................... 2
3. Revocation Messages Formats..................................... 3
3.1 Revocation Support Extension................................ 4
3.2 Revocation Message.......................................... 6
3.2.1 Revocation Mask......................................... 9
3.2.2 Replay Protection....................................... 12
3.3 Revocation Acknowledgment Message........................... 13
4. Registration Revocation Overview............................... 15
4.1 Mobile Node Notification.................................... 15
4.2 Registration Revocation Mechanism - Notification............ 17
4.2.1 Home Domain Revoking a Registration..................... 19
4.2.1.1 Home Agent Responsibilities......................... 19
4.2.1.2 Foreign Agent Responsibilities...................... 20
4.2.1.3 Co-located Mobile Node Responsibilities............. 20
4.2.2 Foreign Domain Revoking a Registration.................. 21
4.2.2.1 Foreign Agent Responsibilities...................... 21
4.2.2.2 Home Agent Responsibilities......................... 22
4.2.3 Mobile Node De-registering a Registration............... 23
4.3 The Use of Bits............................................. 23
4.3.1 The 'R' Bit in Use...................................... 24
4.3.2 The 'D' Bit in Use...................................... 25
5. An Example of the New Messages in Use.......................... 26
5.1 The Registration Phase...................................... 26
5.2 The Revocation Phase........................................ 27
6. No New Error Codes............................................. 28
7. Multiple Binding Support....................................... 28
7.1 Other Random Protocol Details............................... 29
8. Security Considerations........................................ 29
Appendix A: Registration Revocation in 'R' and 'D' Bit Worlds...... 31
Appendix B: Disparate Address, and Receiver Considerations......... 32
Appendix C: Using Registration Revocation to Help Release Resources 33
Acknowledgments.................................................... 35
Where to Direct Comments........................................... 35
References......................................................... 36
Full Copyright Statement........................................... 37
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page iii
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 domain providing mobile ip services for the
mobile node whose binding is being revoked, and potentially also have
the mobile node informed that it is no longer receiving mobile ip
services.
A mobility agent which receives a revocation notification no longer
has to provide services to the mobile node whose registration has been
revoked. This means resources being consumed to provide mobile-ip
services for a mobile node that has stopped receiving mobile-ip
services by one agent can be reclaimed by the other agent in a more
timely fashion than if it had to wait for the binding to expire. This
has a favorable impact on resolving accounting issues with respect to
this binding in both domains as the actual lifetime of the
registration is more accurately relayed. Moreover, should foreign
domain policy allow for it, informing the mobile node that it is no
longer being provided mobile ip services enables that mobile node to
react faster than if it had to discover this for itself (e.g. by
waiting to have its attempt to re-register denied). This is crucial
as revocation messages are also useful when it is desireable to prompt
a mobile node to reregister. For example, if reverse tunnels are now
required by home domain policy, revoking registrations that don't use
reverse tunnelings prompt reregistration, which can be denied with
error 138: "reverse tunnel is mandatory, and 'T' bit not set" [2].
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 other it has torn down the current tunnel, allowing both to free
up the resources associated with the identified Mobile IP binding, and
to acknowledge this understanding.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 1
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
The mechanism described in this documennt is intended for mobility
agents playing the active role in ending a mobile node's service, and
is relayed between them. The revocation/release messages defined here
are a logical addition to the messages defined in [1] for the generic
Mobile IP registration process, and apply to situations where mobility
agents need to play an active role in administering Mobile IP
registrations. This document therefore describes methods to be used
only when mobility agents are initiating, and/or coordinating the
release of mobile ip services.
The mechanism described in this document do not replace the methods
described in [1] for de-registration messages as those apply to
situations where the mobile node is playing the active role in
informing the home agent of its location when it has roamed e.g. back
to its home subnet. This is to say the revocation message defined by
this document is NOT for use by colocated mobile nodes that are
terminating their registration as deregistration requests are already
sufficient for this purpose. A co-located mobile node, however, may
wish to process the messages defined in this document as it is a
useful mechanism to trigger the renegotiation of required services
from the home domain.
This reader is assumed to be familiar with the concepts and
terminology used in [1], and [3]. Knowledge of the concepts of [4]
and [5] are also be beneficial. The keywords "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in RFC2119 [6].
2. Motivation
Mobile IP [1] defines registration of a mobile node's location to
provide connectivity between the mobile node and its home domain,
facilitating communication between mobile nodes and any correspondent
node. 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. However, 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.
If the home agent stops providing mobile ip services (for a mobile
node), 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 prematurely
shutting down a binding, the home agent is capable of sending a
revocation message to the foreign agent, both the foreign agent and
the mobile node get earlier indication, and the mobile node may need
to renegotiate another binding.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 2
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 silently
discarded. An aware mobile node may notice the lack of response to
packets it is generating, eventually guessing its binding may have
vanished, and provoking an attempt to re-register. Only at that time
will the mobile node get a registration denied error with some hint as
to why its service was stopped, and by which agent.
A more common scenario occurs when a mobile node roams away from a
foreign agent, which now no longer needs to provide Mobile IP services
to it. Notification of this state-change by a home agent could be
useful to it (see Appendix C).
A revocation protocol is also useful in scenarios where a timely
release of resources is desirable, regardless of whether the mobile
node's binding was administratively revoked or terminated for another
reason.
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. Revocation Message Formats
This section details the format of the signaling protocol between
home and foreign agents, or from a home agent to a co-located mobile
node. The following message-types are introduced by this document for
relaying revocation information:
- Revocation Support Extension: An extension appended to a
registration request or registration reply by a mobility agent
indicating its support of registration revocation. This message is
also used to indicate whether an agent will acknowledge receipt of a
revocation message, and/or convey its wishes as to the notification of
a mobile node regarding termination of its registration. This
extension may also be appended to a registration request by a
colocated mobile node to indicate its understanding of revocation
messages.
- Revocation Message: A message sent by a mobility agent to inform
another mobility agent, or colocated mobile node, that it is revoking
the binding of a[t least one] mobile node. These messages are not
sent by mobile nodes, but may be received by colocated mobile nodes.
- Revocation Acknowledgment Message: A message to indicate the
successful receipt of a revocation message. These messages are sent
by mobility agent, or colocated mobile nodes.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 3
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
3.1 Revocation Support Extension
The Mobile IP revocation support extension MUST be attached to a
registration message by any entity that wants to receive revocation
messages. Normally, this is either a foreign agent, or a home agent,
however a colocated mobile node MAY also include a revocation support
extension in its registration request. In all cases, the extension
MUST be protected by the appropriate authenticator [1].
The foreign agent MAY also attach a revocation extension to an
agent advertisement to indicate to the link upon which it is
advertising that 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 (unlike support of the 'R' bit as described by
[1]). The user is referred to Section 8, and [5] for a discussion
surrounding security issues of agent advertisements.
The format of the revocation support extension is based on the
Type-Length-Value Extension Format given in [1] and is defined as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |A|I| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA - Skippable (e.g. 135). See below.
Length
Length (in bytes). Does NOT include Type and Length
(in accordance with [1]).
'A' Bit
When this bit is set to '1', the mobility agent is
specifying that it will send a revocation
acknowledgment in receipt of a registration revocation
message for this registration if the other side agrees
to do the same (see Sections 3.2 and 4.2).
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 4
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
'I' Bit
This bit is set to '1' by a mobility agent to indicate
it supports the use of the 'I' bit in revocation
messages (see Sections 3.2 and 4.2). Note that in all
revocation scenarios the use of the 'I' bit requires
acknowledgment, so if the 'I' bit is set to 1 in a
revocation extension, the 'A' bit MUST also be set to
'1'.
When sent by a foreign agent:
If set to 1, indicates to the home agent that the
foreign agent is willing to have the 'I' bit in the
revocation process (as set by the home agent) determine
whether the mobile node is informed of the revocation,
or not.
If set to 0, indicates to the home agent that the
foreign agent will follow its own policy with regards
to informing the mobile node in the event of a
revocation.
When sent by a home agent, in response to a revocation
extension in which the 'I' bit was set to 1:
If set to 1, the home agent agrees to use the 'I' bit
in either the revocation message, or the revocation
acknowledgment to indicate to the foreign agent whether
the mobile node should be informed.
If set to 0, the home agent will not use the 'I' bit in
either the revocation message, or the revocation
acknowledgment, yeilding to the foreign agent's default
behaviour.
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 support 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 appropriate 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 doesn't understand
this extension, it MUST skip it, and continue processing the remainder
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 5
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
of the registration request. This is so a home agent can continue to
process 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, or isn't willing to participate in
registration revocation for this particular binding. In this way, if
local policy in the foreign domain requires registrations to be made
only with home agents which support this feature, the foreign agent
may actively deny the registration with this home agent, and indicate
this to the mobile node (e.g. via 65 "administratively prohibited").
In this way, use of registration revocation can be negotiated for each
registration, and each domain has a clear understanding of what is
expected. In contrast, if this extension were not skippable, a home
agent which doesn't understand the revocation extension would silently
discard the registration, and there would be no feedback to either the
foreign agent, or the mobile node.
3.2 Revocation Message
The format of revocation message is analogous to registration
request and registration reply messages [1].
IP fields:
Source Address In the case of the home agent issuing the
registration revocation, the address
registered with the care-of address as
that of the home agent.
In the case of the foreign agent issuing
the registration revocation:
If the registration being revoked is NOT
for a co-located mobile node, the address
registered with the home agent as the
care-of address.
In the case of the revocation of a
co-located mobile node, any of the
addresses of the foreign agent associated
with the foreign agent NAI which MUST
have been included in the most recent
registration request to the home agent.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 6
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
Destination Address In the case of the home agent issuing the
registration revocation:
In the case where the revocation is not
for a co-located mobile node, the address
identified as the care-of address of the
mobile node,
In the case where the home agent is
notifying the foreign agent servicing a
co-located mobile node, any of the
addresses associated with the NAI of the
foreign agent included in the most recent
approved registration request.
In the case of the foreign agent issuing
the registration revocation, the address
registered as that of the home agent by the
mobile node whose registration is being
revoked.
UDP fields:
Source Port variable
Destination Port 434
The UDP header is followed by the Mobile IP fields shown below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Mask |A|I| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Domain Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Domain Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Domain Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Domain Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBA e.g. 7 (Registration Revocation)
Mask A set of flags indicating the applicability of the
registration revocation. See Section 3.2.1 for
definitions.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 7
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
A Acknowledge bit.
This bit MUST only be used if acknowledgment support
was negotiated in the last successful registration of
at least one of the mobile nodes whose registration is
being revoked. If not, the results can be
unpredictable.
Set to '0' when the revoking agent does NOT want an
acknowledgment for this revocation message.
Set to '1' when the revoking agent is expecting an
acknowledgment of this revocation message.
I Inform bit.
This bit MUST only be used if 'I' bit support was
negotiated in the revocation extension messages passed
in the registration process. If not, the results can
be unpredictable.
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. Note that in
this case the foreign agent MUST also set the 'A' bit
to indicate to the home agent that it needs to
acknowledge this revocation message.
reserved MUST be sent as 0, ignored when received.
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. See
Section 3.2.1.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 8
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
Foreign Domain Address
The IP address identified as being in the foreign
domain. This is either the foreign agent's IP
address, or the co-located care-of address, or the
subnet address of either of these 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 Domain Address are being revoked. See
Section 3.2.1.
Home Domain Address
The IP address identified as being in the home domain.
This is either the home agent's IP address, or the
subnet address indicating that all mobile nodes using
a home agent on the identified subnet are having their
bindings revoked. See Section 3.2.1.
Home Domain 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 3.2.2.
An example of the use of revocation messages is given in Section 5.
3.2.1 Revocation Mask
The use of the revocation mask is OPTIONAL. If it is not used, it
MUST be set to all zeros. The registration revocation message MAY use
this to indicate the "extent" of the revocation, and is used in
combination with the address fields defined above. The following bit-
values are defined. Note the low-order bits apply to addresses, and
the high-order bits apply to NAIs.
Value Meaning
----- -----------------------------------------------------------
0x01 Applies to all bindings where the mobile node home address
belongs to the same subnet as the address appearing in the
home address field. The address appearing in the home
address field MUST either be that of a registered mobile
node, or a subnet address. The issuing agent MUST include
a prefix-length extension defined by [1] appearing after
the revocation message to indicate the bits of address
being effected (e.g. 10.1.1.128, prefixLen=25).
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 9
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
0x02 Applies to all bindings where the care-of address belongs
to the same subnet as the address appearing in the foreign
domain address field. The address appearing in the foreign
domain address field MUST either be the co-located address
belonging to a mobile node, or a subnet address. The
issuing agent MUST include a prefix-length extension as
defined by [1] appearing after the revocation message to
indicate the bits of address being effected
(e.g. 10.1.1.192, prefixLen=26).
0x04 Applies to all bindings where the registration is using the
same foreign address appearing in the foreign domain
address field. The address appearing in the foreign domain
address filed MUST either the address registered as the
foreign agent address, or a subnet address in which case
the issuing agent MUST include a prefix-length extension as
defined by [1] appearing after the revocation message to
indicate the bits of address being effected
(e.g. 10.1.1.224, prefixLen=27).
0x08 Applies to all bindings where the registration is using the
same home agent address appearing in the Home Domain
Address field. The address appearing in the Home Domain
Address field MUST either be the address registered as the
home agent address, or a subnet address. The issuing agent
MUST include a prefix-length extension as defined by [1]
appearing after the revocation message to indicate the bits
of address being effected (e.g. 10.1.1.240, prefixLen=28).
Note that this address MUST NOT be the zero address, see
Appendix B.
0x10 Applies to all bindings with the same administrative domain
as the mobile node. The issuing agent MUST include the NAI
of [one of] the mobile nodes whose registration is being
revoked in an NAI extension, appearing after the revocation
message.
0x20 Applies to all bindings with the same administrative domain
as the care-of address. The issuing agent MUST include the
care-of domain's NAI in an NAI extension, appearing after
the revocation message.
0x40 Applies to all bindings with the same administrative domain
as the foreign agent. The issuing agent MUST include the
foreign agent NAI in an NAI extension appearing after the
revocation message.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 10
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
0x80 Applies to all bindings with the same administrative domain
as the home agent. The issuing agent MUST include the home
agent NAI in an NAI extension appearing after the
revocation message.
When multiple flags are set, the corresponding prefix-length and
NAI extensions MUST appear in the same order, "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.
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 mask to 0x01, and
includes the prefix length extension for that subnet. When the
foreign agent receives an authenticated message in which the mask is
set to 0x01, 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. For
example, a foreign agent revoking all binding from the same NAI domain
as mn@home.domain would set the mask to 0x10, and include an NAI
extension after the revocation message including the NAI
mn@home.domain. When the foreign agent receives an authenticated
message in which the mask is set to 0x10, it understands that all
mobile nodes that used an NAI containing @home.domain have been
revoked.
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. For example, if foreign agent x.y.z.t sends a revocation
message to home agent a.b.c.d for mobile node a.b.c.x, and sets the
revocation mask to 0x01, the home agent MUST NOT revoke all of its
bindings for mobile nodes on the same home link as the revoked mobile
node, but only those mobile nodes that are also visiting 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
links and being served by the same foreign agent, i.e., a foreign
agent may be servicing different classless subnets [7], or it may be
multihomed though using the same CoA for all these subnets. See the
Appendix B on disparate address support in [2] for a related
discussion.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 11
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
3.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, and not be
discrigarded without a replay protection mechanism to identify the
datagram as a repeat. Moreover, since datagrams are not guaranteed to
arrive unduplicated, a replay may occur by "design". The same caveat
applies to reflected packets (which may be indistinguishable from
"malicious repeaters").
Replay protection is handled in direct analogy with the mechanism
defined by [1], through two 32-bit identifier fields in the
registration revocation message.
- The agent revoking a registration sets its Identifier field to a
valid timestamp, and sets the other Identifier field to 0. The
revoking agent MUST append an authenticator. Upon receipt of an
authenticated revocation message, the agent checks the other
agent's Identifier field to make sure it is not a replay of an
old revocation message received from the same agent. If the
agent Identifier field implies this packet is a replay, that
revocation message MUST be silently discarded.
- When building a revocation acknowledgment message (in response to
a revocation message in which the 'A' bit is set), the
acknowledging agent copies the Identifier field of the other
agent from the revocation message into the revocation
acknowledgment packet, and sets its identifier field to a valid
timestamp. The revocation acknowledgment message MUST be
protected with a valid authenticator.
- Upon receiving a valid revocation acknowledgment, the revoking
agent checks its Identifier field to make sure it matches its
identifier from the revocation message it sent, and also checks
the other agent's Identifier field, which MUST be non-zero.
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. This MUST NOT result in one of these revocation message being
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 12
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
ignored. As agents are useing timestamps for replay protection, they
will natually be incremented with each revocation. With the use of
timestamps only one revocation attempt per second may be made for any
registration, or set of registrations with each agent peer. The
reader should note that the ID field used in the replay protection of
registration requests in [1] suffers from the same limitations.
3.3 Revocation Acknowledgment Message
The format of revocation acknowledgment message is analogous to the
revocation message.
IP fields:
Source Address Copied from the destination address of
the received registration revocation
message for which this registration
revocation acknowledgment message is
being generated.
Destination Address Copied from the source address of the
received registration revocation message
for which this registration revocation
acknowledgment message is being
generated.
UDP fields:
Source Port 434 (copied from the destination port of
the revocation message)
Destination Port Copied from the source port of the
revocation message.
The UDP header is followed by the Mobile IP fields shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |I| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 13
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
Type TBA, e.g. 9 (Registration Revocation)
Length 10. The length of the revocation acknowledgemnt
message, not including Type and Length fields.
I Inform bit.
The 'I' bit MUST only be used in revocation
acknowledgment messages if it was set to '1' in the
revocation message.
If used by a foreign agent:
Set to '1' to indicate to the home agent that the mobile
node was/will be informed of the revocation.
Set to '0' to indicate to the home agent that the mobile
node was/will not be informed of the revocation
Set to the OPPOSITE of what the home agent set the 'I'
bit to in the revocation message to indicate the foreign
agent is NOT revealing whether the mobile node was
informed or not. See Section 4.1.1.2 for an example.
If used by the home agent:
Set to '1' by the home agent to request the foreign
agent inform the mobile node of the revocation.
Set to '0' by the home agent to request the foreign
agent not inform the mobile node of the revocation.
reserved MUST be sent as 0, ignored when received.
Identification Fields
A 32-bit number used for protecting against replay
attacks. See Section 3.2.2.
An example of the use of the revocation messages is given in
Section 5.
A registration revocation acknowledgment message MUST only be sent
in response to a registration revocation messages in which the 'A' bit
was set to 1.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 14
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
4. Registration Revocation Overview
Registration Revocation consists of two disjoint pieces, a
signaling mechanism between the tunnel endpoints, and a signaling
mechanism between a foreign agent and a 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 messages from its home
agent. However, a co-located mobile node does not have to implement
the sending of revocation messages as deregistration messages defined
in [1] are sufficient for this purpose.
4.1 Mobile Node Notification
A mechanism which provides a foreign agent a way to actively notify
a mobile node that its binding has been reset already exists in [1],
though it has been overlooked for this purpose.
The following paragraph contains a brief overview of the mechanics
of the sequence number in agent advertisement from [1] so the
mechanism by which the foreign agent 'implies' to the mobile node that
its binding is no longer active is clearly understood.
When a foreign agent begins sending agent advertisements, it
starts with a sequence number of 0, and [monotonically] increments the
sequence number with each subsequent agent advertisement. In order
for a mobile node to be able to distinguish between a foreign agent
that has simply exhausted the sequence number space from one which has
been reset, and thereby lost the mobile node's binding information, a
foreign agent sets the sequence number to 256 instead of rolling to 0.
In this way, a mobile node would have to miss, at that time, 256
advertisements in a row to mistake a reset as a roll-over. Moreover,
the lifetimes contained within an agent advertisement should be set in
such a way that when a mobile node believes it has missed 3 beacons,
the entry for this foreign agent should time out, and if the mobile
node is registered there, it should send an agent solicitation [1].
If, however, an agent is somehow reset, it will begin advertising with
a sequence number of 0, and the mobile node can presume this foreign
agent has lost its binding, and the mobile node SHOULD re-register to
make sure it is still obtaining Mobile IP services through this
foreign agent.
Leveraging this mechanism, a foreign agent may consciously notify
all mobile nodes currently bound to it that it has "reset" all their
bindings, even if the agent itself has not been reset, by simply
[re]setting the sequence number of the next agent advertisement to 0.
Moreover, a foreign agent may inform all mobile nodes currently bound
to it they should re-register with a different foreign agent by
simultaneously setting the sequence number to 0, and also setting the
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 15
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
'B' bit [1] in the advertisement to 1, indicating this foreign agent
is busy and is not accepting new registrations. In these situations,
any mobile node in compliance with [1] will presume this foreign agent
has lost its binding, and must re-register if they wish to
re-establish Mobile IP functionality with their home subnet.
To indicate to any registered mobile node that its binding no
longer exists, the foreign agent with which the mobile node is
registered may unicast an agent advertisement with the sequence number
set to 0 to the mobile node [1], [3].
Moreover, if such a foreign agent wishes to indicate to the mobile
node that its binding has been revoked, and that the mobile node
should not attempt to renew it's registration with it, the foreign
agent MAY also set the 'B' bit to 1 [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 optionally
remember the mobile node's binding was revoked, and respond to the
solicit in the same way, namely with the 'B' bet set to 1. It should
be noted, though, that since the foreign agent is likely to not be
setting the 'B' bit to 1 in its broadcasted agent advertisements (sent
to the entire link), the revoked mobile node, upon hearing this
agent's multicast agent advertisement without the 'B' bit set may
attempt to [re]register with it. If this happens, depending of
foreign domain policy, the foreign agent can simply deny the mobile
node with an appropriate error code (e.g., "administratively
prohibited"). At this time, a mobile node MAY use foreign agent
fallback to attempt to register with a different foreign agent as
described in [1]. Mobile nodes which understand this revocation
mechanism may understand that a unicast agent advertisement with the
sequence number reset to 0 could indicate a revocation, and may
attempt to register, or co-locate (e.g. if the mobile node is in
multiple coverage areas with a single, or multiple interfaces). In
any case, a mobile node must be able to continue to operate as
described by [1], 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 [5].
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 16
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
4.2 Registration Revocation Mechanism - Notification
Any active mechanism designed to be useful to both home and foreign
domains must contain a way to securely revoke a current binding. This
means the registration process must supply both home and foreign
domains with enough information to be able to inform the other side of
any revocation. Moreover, a revocation message MUST NOT be sent for a
registration that has expired, and MUST only be sent prior to the
expiration of a mobile node's registration.
As in [1], any information the foreign agent appends to the
registration request MUST be protected by a Foreign-Home
authenticator, as MUST any information outside the Mobile-Home
authenticator in the corresponding registration reply. Due to the
nature of a 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, all such signaling MUST (continue to be) protected by the
Mobile-Home authenticator. However, a mobile node that is terminating
any of its own bindings MUST 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 registration 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 if
there exists an applicable authentication mechanism, and that
mechanism is in-use), and MUST append a revocation support extension
(defined in Section 3.1) to the registration request. If the
corresponding registration reply from this home agent does not contain
a revocation support extension, the foreign agent MAY assume the home
agent/domain does not understand registration revocation, or is
unwilling to participate. Note that in this case, as specified in
[1], both registration request and registration reply MUST still
contain a home-foreign authenticator.
If a home agent wishes to participate in revocation messages with
the foreign domain, it MUST share a security relationship with the
foreign agent which sent the registration request (or with the foreign
domain if there exists an applicable authentication mechanism, and
that mechanism is in-use), and MUST append a revocation support
extension to the registration reply. If the registration request from
a foreign agent does not contain a revocation support extension, the
home agent MAY assume the foreign agent/domain does not understand
registration revocation, or is unwilling to participate specifically
for this mobile node. The home agent MAY include a revocation support
extension in the registration reply anyway.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 17
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
If a co-located mobile node wishes to be informed of a released
binding by the home agent, it MUST insert a revocation support
extension into the registration request which MUST be protected by the
mobile-home authenticator.
If the revocatation extension is not included in any registration
message, either by a foreign agent or co-located mobile node in a
registration request, or by a home agent in a registration reply, the
receiver of such a registration message SHOULD assume the sender does
not understand revocation messages.
Revocation support is considered to be negotiated when both sides
have included a revocation support extension during a successful
registration exchange.
The 'A' bit in the revocation extension is used to indicate the
desire to use acknowledgment messages in response to revocation
messages for the binding to which they are attached. The use of
acknowledgment messages for this registration is negotiated, this is
offered by the foreign agent, and agreed to by the home agent. More
precisely, by sending a revocation extension in which the 'A' bit is
set, the foreign agent is indicating it would like the home agent to
resend any revocation message for this registration for which it does
not receive a revocation acknowledgment message, and is offering to do
the same for the home agent with regards to this registration. The
home agent then can disagree, in which case it simply does not set the
'A' bit, or agree by setting the 'A' bit to 1 in the revocation
extension appearing in the registration reply.
The 'I' bit in the revocation extension is used to indicate that
the decision to inform the mobile node that its binding has gone away
will be left to the home agent. As with the 'A' bit, this
functionality is offered by the foreign agent, and accepted by the
home agent. More precisely, by sending a revocation extension
attached to a registration request in which the 'I' bit is set to 1,
the foreign agent is indicating to the home agent that it MAY leave
the decision to inform this mobile node that its registration has gone
away to the home agent. The term "MAY" is used here because it is
recognized that domain policy may change during the lifetime of any
registration. The home agent can acknowledge that it wishes to do
this by setting the 'I' bit to 1, or it can indicate it will not do so
by setting the 'I' bit to 0 in the revocation extension appearing in
the registration reply.
All revocation messages and revocation acknowledgement messages
MUST contain valid authenticators, namely home-foreign authenticators
if the communication is between home and foreign agents, or
mobile-home authenticators if the communication is between home agents
and co-located mobile nodes.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 18
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
If any agent, or co-located mobile node receives a registration
revocation message that does not contain a valid authenticator, namely
a home-foreign authenticator if the revocation message is between home
and foreign agents, or a mobile-home authenticator if the message is
from home agent to co-located mobile node, the revocation message MUST
be ignored, and silently discarded.
4.2.1 Home Domain Revoking/Releasing a Registration
The following section details the responsibilities of each party
depending on the functionality negotiated in the revocation support
extension when the home domain is revoking a registration.
4.2.1.1 Home Agent Responsibilities
In the case where a home agent is revoking/releasing a mobile
node's binding, and revocation support has been negotiated, the home
agent MUST notify the foreign domain address it is terminating the
tunnel entry point by sending a revocation message. Note that the
foreign domain address can either be the foreign agent's care-of
address, or a co-located care-of address. Note that if a colocated
mobile node included a revocation support extension in its
registration request, and passed it to a foreign agent (because the
'R' bit was set) which also included a revocation support extension,
there may be a need to send a revocation message to both.
If the 'A' bit was negotiated because it was set to '1' in both
revocation extensions passed in the registration process, the home
agent MUST set the 'A' bit in the revocation message and expect a
revocation acknowledgment in return. If the home agent does not
receive a revocation acknowledgment message with in a reasonable
amount of time, it MUST retransmit the message. How long the home
agent waits to retransmit, and how many times the message is
retransmitted is only limited by the specification that the home agent
MUST NOT send more than one revocation per second for a particular
binding, SHOULD fall-back in analogy with the registration guidelines
in [1], and MUST NOT retransmit revocation acknowledgement messages
beyond the normal life of the revoked binding.
If the mobile node whose registration is being revoked is NOT
co-located, and the use of the 'I' bit was negotiated in the
registration process, the home agent MUST set the 'I' bit to 1 if the
home agent would like the mobile node informed of the
revocation. Conversely, if the home agent does not want the mobile
node notified, it MUST set the 'I' bit to 0. A Home-Foreign
authenticator MUST be included in the registration revocation message.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 19
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
If the mobile node whose registration is being revoked is
co-located (the 'D' bit was set in the most recently approved
registration request), and indicated in the registration process that
it wishes to receive revocation messages from the home agent, the
revocation message MUST be protected by a Home-Mobile authenticator.
4.2.1.2 Foreign Agent Responsibilities
Upon receiving a registration revocation message, the foreign
agent MUST check the Home-Foreign authenticator in analogy to [1], and
if the packet passes authentication, the foreign agent MUST identify
the binding(s) described by the home agent as being released using the
information in the revocation message, namely the addresses identified
by the mobile node address, the foreign domain address, and the home
domain address. Upon locating such bindings, if the 'A' bit was
negotiated in the registration phase, and the 'A' bit is now set in
the revocation message, the foreign agent MUST respond with a
revocation acknowledgement sent to the source address of the
revocation message. If the 'I' bit was also negotiated, the foreign
agent MUST check the value of the 'I' bit in the revocation message,
and if it is set to 1, MUST notify the mobile node that it's binding
has been revoked by the methods described in Section 4.1, and MUST set
the 'I' bit to 1 in the revocation extension to be sent to the home
agent. If however, since the negotiation of the 'I' bit in the most
recent registration, the policy on the foreign domain has changed so
that use of the 'I' bit is no longer allowed, the foreign agent MUST
abide by the new policies with regards to notification of the mobile
node, and MUST set the 'I' bit in the revocation acknowledgement to
the OPPOSITE of what was sent by the home agent. This indicates to
the home agent that its wishes were not necessarily followed, and the
setting of the 'I' bit does not indicate whether the moblile node was
notified or not. The foreign agent may also free up any resources
that were being used by the former binding(s), and discontinue all
Mobile IP services for the identified mobile nodes.
4.2.1.3 Co-located Mobile Node Responsibilities
Upon receiving a revocation message, the co-located mobile node
MUST check the Mobile-Home authenticator, and if the packet passes
authentication, the mobile node MUST verify that the information
contained in the revocation messages identifies the home agent with
which it has a current binding, that this binding identifies correctly
this mobile node and any foreign domain address it is currently using.
If the mobile node is able to identify such a binding, the mobile node
SHOULD immediately terminate any reverse tunnel encapsulation it is
using to this home agent. The mobile node may also free up any other
resources associated with the former binding. In addition, if the 'A'
bit was negotiated in the registration process, and the 'A' bit was
set in the revocation message, the mobile node MUST immediately
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 20
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
generate a revocation acknowledgment message in response. The
revocation acknowledgment message MUST be sent to the IP source
address of the revocation message, and it MUST be protected by a
Mobile-Home authenticator for authentication by the home agent.
4.2.2 Foreign Domain Revoking/Releasing a Registration
The following section details the responsibilities of each party
depending on the functionality negotiated in the revocation support
extension when the foreign domain is revoking a registration.
4.2.2.1 Foreign Agent Responsibilities
In the case where the foreign domain is revoking/releasing a mobile
node's binding, if revocation support has been negotiated, the foreign
agent MUST inform the home agent 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 to provide mobile-ip services to the mobile node.
If the most recent registration request indicated the mobile node
is using a co-located care-of address (the 'D' bit was set), and hence
the registration request 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 appended in the registration
revocation message. (Note: it is presumed the foreign agent had the
'R' bit set when such a colocated mobile node last registered, but
even if not, obviously the foreign agent is aware of this binding. In
this case, the foreign agent is implying to the home agent this it
and/or the foreign domain in general have some way of controlling
communications between the mobile node and home agent, and therefore a
revocation message in this case implies to the home agent that such
lines of communication are going away. See Section 4.3.1 "Use of the
'R' bit").
If the 'A' bit was negotiated in the revocation extension, the
foreign agent SHOULD set the 'A' bit to 1 in the revocation message.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 21
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
If the use of the 'I' bit was negotiated, the foreign agent MUST
NOT inform any mobile node of its revocation at this time. Instead,
the foreign agent MUST set the 'I' bit to 1 in the revocation message,
thereby asking the home agent to use the 'I' bit in the revocation
acknowledgment to indicate if it should notify the effected mobile
nodes. As an exception to this, the only time the FA may choose to
not set the 'I' bit is in the case where policy on the foreign domain
has changed since the most recent sucessful registration, and the
foreign agent is no longer able to use the 'I' bit. In this case the
foreign agent MUST set the 'I' bit to 0, and follow the policies of
the foreign domain with regard to notifying the mobile node..
Note, when setting the 'I' bit to 1, the 'A' bit necessarily needs
to also be set to 1.
If the use of the 'I' bit was not negotiated, the foreign agent MAY
inform the mobile node of its revocation as described in Section 4.1,
before sending the revocation message to the home agent, just after
sending the revocation message to the home agent, or after it receives
a revocation acknowledgment message from the home agent.
If the 'A' bit was set in the revocation message, the foreign
agent SHOULD wait for a revocation acknowledgment message from the
home agent. How long the foreign agent waits to retransmit, and how
many times the message is retransmitted is only limited by the
specification that the foreign agent MUST NOT send more than one
revocation per second for a particular binding, SHOULD fall-back in
analogy with the registration guidelines in [1], and MUST NOT
retransmit revocation acknowledgement messages beyond the normal life
of the revoked binding.
4.2.2.2 Home Agent Responsibilities
Upon receiving a registration revocation message, the home agent
MUST check the Foreign-Home authenticator. If the packet passes
authentication, the home agent MUST locate the binding(s) identified
by the home agent as being released using the information in the
revocation message, namely the addresses identified by the mobile node
address, the foreign domain address, and the home domain address.
Since these bindings are no longer active, the home agent can free up
any resources associated with the former bindings and discontinue all
Mobile IP services for them. If the 'A' bit was set in the revocation
message, the home agent MUST send a revocation acknowledgment to the
IP source address of 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, the
registration revocation message MUST be ignored, and silently
discarded.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 22
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
4.2.3 Mobile Node Deregistering a Registration
The cases where a mobile node is registered with its home agent,
whether it is registered directly with its home agent (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 the appropriate care-of Address
with its home agent as described by [1].
Note that when a co-located mobile node includes a revocation
extension in its registration request, it will expect to see a
revocation extension in the registration reply from the home agent
acknowledging that the home agent is willing to send revocation
messages to such a mobile node. However, the home agent should
understand that it will not receive revocation messages from such a
mobile node, so the decision to include a revocation extension in the
registration reply MUST NOT be made based on the home agent's desire
to see such messages. A co-located mobile node, and home agent MAY
negotiate the use of the 'A' bit, and use it in the revocation
process.
4.3 The Use of Bits
Several of the bits used in the registration process play an
important role in the topology of the binding, and therefore the
revocation.
The 'R' bit in the agent advertisement is an effective way to
assure that the foreign domain is provided with the binding
information necessary to revoke it. This is especially important in
the case of a co-located mobile node whose registration request may
otherwise by-pass the foreign agent. How the foreign domain enforces
this policy is beyond the scope of this document, but a few examples
are through either restricted access to topologically correct
addresses with which to co-locate, or some form of access control
lists on the routers, etc.
The 'D' bit in the registration request is a sign to a home domain
that a foreign agent address does NOT appear in the registration
request, and so the home agent may be missing the necessary
information to be able to notify the foreign domain in the event of a
registration revocation. A home agent that receives a registration
request in which the 'D' bit is set SHOULD look for a foreign agent
NAI extension appearing after the Mobile-Home authenticator indicating
the foreign agent to which any revocation messages are to be sent.
Note that if the registration request came from a foreign agent
(e.g. the 'R' bit was set), then the source address of the
registration request could be that of the foreign agent. The home
agent SHOULD check to see if that address is not the care-of address
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 23
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
identified in the care-of address field of the registration request.
Alternatively, as any such NAI extension MUST be secured via a
foreign-home authenticator [1], the security association identified by
the foreign agent's NAI MAY be used to identify an IP address to which
any revocation message is to be sent.
More information, and an example, is provided in "Appendix A:
registration revocation in 'R' and 'D' Bit Worlds."
4.3.1 The 'R' Bit in Use
If the foreign agent wishes to be able to revoke a mobile node's
registration, it MUST set the 'R' bit in its agent advertisements. A
foreign agent advertising the 'R' bit requests every mobile node, even
one that is co-located, to register [the 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 the mobile
node's link address, home IP address, and the address of the mobile
node's home agent. The foreign agent will then be capable of
unicasting an agent advertisement to the mobile node, and sending a
registration revocation message to the home agent, as described in
Sections 4.1 and 4.2.2. This makes advertising the 'R' bit attractive
in domains that wish to have control over registered mobile nodes, and
moreover, sending revocation notification to the home domain may be a
contractual necessity.
Enforcement of the 'R' bit is beyond the scope of this document,
and when the foreign domain wishes to be able to enforce the
revocation, and/or to notify the home domain of revoked registrations,
such an enforcement mechanism is crucial. 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. Even so, nothing may be preventing the mobile
node from trying to register directly with its home agent. In the
event a foreign domain wishes to enforce the revocation of a
co-located mobile node's registration, the foreign domain MUST be able
to control the flow of datagrams to, and/or from, the mobile node.
The easiest way to do this is to not accept registration requests from
co-located mobile nodes, though there are other mechanisms available
which allow co-location.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 24
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
4.3.2 The 'D' bit in Use
If the mobile node has set the 'D' bit in the registration request,
and forwards the registration via a foreign agent (see Section 4.3.1),
and the foreign agent determines it will accept the registration from
the mobile node, then the foreign agent MUST append a revocation
extension if it wants to be notified of registration revocations for
this mobile node (in addition to any already included by the mobile
node and protected by the mobile-home authenticator). The foreign
agent MAY also append the prefix length extension [1] that appears in
the agent advertisements on the link from which the mobile node is
registering. The inclusion of the prefix length extension is so the
home agent understands the topology of the link the mobile node is
visiting in the event it wants to issue a single registration
revocation for multiple mobile nodes visiting the same link. In order
to authenticate these extensions, the foreign agent MUST append its
NAI extension, which MUST be followed by a Foreign-Home authenticator.
Note that registration requests where the 'D' bit is set, and which
are relayed through a foreign agent due to the advertising of the 'R'
bit can contain the foreign agent address as the source address of the
registration request as received by the home agent. A home agent MUST
verify that the source address of this registration request is not the
same as the care-of address contained in the registration request;
note that according to [1] the home agent is required to send the
registration reply to the source IP address of the registration
request.
If the home agent wishes to support registration revocation for
this binding, which can be conveyed to either the co-located mobile
node, or the foreign agent whose NAI appears in the registration
request, it MUST include a revocation support extension in the
mobile-home portion of the registration reply if it agrees to notify
the mobile node of a release of this registration, and/or MUST include
a revocation support extension in the foreign-home portion of the
registration reply if it agrees to notify the foreign agent of a
release of this registration. Note that, as determined by the
security association with the foreign agent, it may be necessary for
the home agent to include its NAI extension for use by the foreign
agent in authenticating the registration reply.
Upon release of this registration, if revocation support was
negotiated with BOTH the co-located mobile node, and the foreign
agent, revocation messages for this binding MUST be first sent to the
mobile node's co-located care-of address to ensure that they reach it.
A revocation message MUST then be sent to the foreign agent. If the
revocation message was sent to the foreign agent first, there may be
no way for a revocation message to then reach the mobile node. Also,
in order for the home agent to be able to send a revocation message to
the foreign agent, it is presumed that the source IP address of the
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 25
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
registration request is that of the foreign agent, or that the
security association between the home and foreign agents contains
(among other things) the NAI and IP addresses of the foreign agent.
5 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.
5.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 support extension
after the Mobile-Home authenticator. If the foreign agent wishes to
receive a revocation acknowledgment from the home agent in the event
that the registration for this mobile node is revoked, and/or if it is
willing to send a revocation acknowledgment message in response to a
revocation message from the home agent for this mobile node, it MUST
set the 'A' bit to '1'. Furthermore, if the foreign agent supports
the use of the 'I' bit, and is willing to let the home agent decide if
the mobile node should be informed of the revocation of its
registration, it SHOULD set the 'I' bit to '1'. Additionally, the
foreign agent MUST append a Foreign-Home authenticator to the
registration request, and include any other extension needed by the
foreign agent to verify the authenticator [1].
Upon receiving a registration request containing a revocation
extension, a home agent that supports registration revocation SHOULD
include a revocation support extension in the registration reply. If
the 'A' bit is set in the revocation extension sent by the foreign
agent, a home agent that wishes that foreign agent to retransmit lost
(unacknowledged) revocation message, and agrees to do the same, MUST
set the 'A' bit in its revocation extension to '1'. Furthermore, if
the foreign agent set the 'A' bit to 1, and also set 'I' bit to 1 in
its revocation extension, and the home agent supports the use of the
'I' bit, and wishes to determine whether this mobile node is to be
informed in the event that its registration has been revoked, the home
agent SHOULD set the 'A' bit, and the 'I' bit in its registration
extension to '1'. Additionally, the home agent MUST append a
Home-Foreign authenticator to the registration request, and include
any other extension needed by the foreign agent to verify the
authenticator [1].
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 26
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
Upon receiving the authenticated registration reply, the foreign
agent should check the revocation support extension. If none is
present, the foreign agent MAY presume the home agent doesn't
understand revocation messages, or is unwilling to participate. If a
revocation support extension is present, and since the foreign agent
included the revocation extension in the registration request with the
'A' and 'I' bit set, the foreign agent MUST check the 'A' bit to see
if the home agent will provide revocation acknowledgment services (if
they were requested), and should also check the 'I' bit to see if the
home agent wants to decide if the mobile node should be notified in
the event this registration is revoked.
5.2 The Revocation Phase
If a foreign agent wishes to revoke a mobile node's registration,
it generates a revocation message. If the 'A' bit was negotiated in
the revocation extension for this registration, the foreign agent
SHOULD set the 'A' bit in the revocation message to 1. If the 'A' bit
and 'I' bits were negotiated in the revocation extensions, and the
foreign agent is willing to let the home agent indicate whether this
mobile node should be informed that its registration has been revoked,
it SHOULD set both the 'A' bit and the 'I' bit to 1; it MUST NOT set
the 'I' bit to 1 without setting the 'A' bit to 1. The foreign agent
MUST also place the address of the mobile node whose registration it
wishes to revoke in the home address field, the address that mobile
node registered as the care-of address in the foreign domain field,
and the address the mobile node registered in the home domain address
field. The foreign agent MUST also insert the Foreign Domain
Identifier, and set the home domain Identifier to 0. The foreign
agent MUST append a foreign-home authenticator, and any additional
information it needs to include for the home agent to validate it
(e.g. if the care-of address is not its own, it can use its NAI
extension).
Upon receiving the above revocation message, the home agent assures
the revocation is protected with a valid Foreign-Home authenticator.
The home agent uses either the foreign agent NAI if present, or the
address identified as the foreign domain address to identify the
security association, and authenticate the revocation message. If the
authenticator is bad, the home agent MUST ignore, and silently discard
the revocation message. If the authenticator is good, the home agent
uses the mobile node home address, foreign domain address, and home
domain address to locate the mobile node(s) whose registration(s)
is/are being revoked. If the 'A' bit was negotiated in the
registration phase for the binding(s) identified, and set to 1 in the
revocation message, the home agent MUST generate a revocation
acknowledgement message. If the 'I' bit was negotiated in the
registration phase for the binding(s) identified, the home agent MUST
check to see if the 'A' bit and 'I' bit are both set to '1' in the
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 27
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
revocation message. If so, and the home agent wishes for the
identified mobile node(s) to be informed of the revocation, it MUST
set the 'I' bit in the revocation acknowledgement to 1, or if the home
agent does not wish the identified mobile node(s) to be informed of
the revocation, it MUST set the 'I' bit in the revocation
acknowledgement to 0. The home agent then copies the addresses, and
the foreign agent identifier field into the reply, and inserts its own
timestamp into the home agent identifier field. The home agent MUST
protect the revocation acknowledgment with a Home-Foreign
authenticator (and any other extension necessary for the foreign agent
to authenticate the Home-Foreign authenticator, e.g. its NAI
extension).
Upon receiving a valid revocation acknowledgment, if the foreign
agent set the 'I' bit in the revocation message to 1, it MUST check
the 'I' bit in the revocation acknowledgement, and if set to 1, MUST
notify the mobile node of the revocation, or if the 'I' bit is set to
0 in the revocatoin acknowledgement, the foreign agent MUST NOT notify
the mobile node of the revocation.
6. 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), 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 the identified registrations. Hence, the
receiving agent can free any resources currently being used for the
registrations being revoked.
7. Multiple Binding Support
RFC 3220 [1] allows a mobile node to register multiple care-of
addresses with its home agent. Each one of these bindings is it's own
discrete registration, and hence can be treated as a separate case for
registration revocation. Consider the situation where a mobile node
has multiple care-of addresses registered with a single foreign agent
(either because the mobile node has multiple co-located care-of
addresses and the foreign agent has the 'R' bit set, or because the
foreign agent is multi-homed). Either agent can indicate the
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 28
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
revocation of all these bindings by setting the care-of address field
to the zero address (and their addresses in the correct places),
indicating all care-of addresses being used by the indicated mobile
node that are bound to the agent identifying itself by this revocation
message.
If a foreign agent revokes a particular mobile node's binding(s)
with it, the home agent MAY or MAY NOT then revoke any of the mobile
node's other bindings (with other foreign agents). If a home agent is
revoking one of a mobile node's bindings, it MAY revoke none, or all
of the mobile node's other bindings as it sees fit. If a home agent
decides to revoke a single binding for a mobile node, the foreign
agent MAY decide to revoke other bindings for the same mobile node as
it sees fit.
The revocation mask is designed to make revoking multiple bindings
easier to specify, and in situations where network topologies make
revoking multiple mobile node bindings difficult to specify
numerically through use of NAIs.
7.1 Other Random Protocol Details
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.
8. Security Considerations
RFC 3220 [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 [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
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 29
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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 enhancements described by this document.
RFC 2794 [4] describes the use of the Network Access Identifier in
Mobile IP. Its relevant use here is for agents to be able to identify
each other in a revocation message. In cases where foreign and home
domains are going to approve registrations from co-located mobile
nodes (registering with the 'D' bit [1]), and in topologies where the
foreign agent is setting the 'R' bit in its agent advertisements [1],
if the agents are going to use their NAIs to identify themselves, the
security association they share MUST include the IP address the
registration revocation messages are to be sent to, and will be sent
from. For a more involved discussion, see Appendix A.
It has been recognized that agent advertisements as defined in [1]
provide a denial-of-service potential [5]. 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.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 30
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
Appendix A: Registration Revocation in 'R' and 'D' Bit Worlds.
Two issues influence the registration of a mobile node on a foreign
subnet. First is the mobile node's desire to co-locate (use of the
'D' bit). Second is whether the foreign domain is requiring
registration through foreign agents (the infamous 'R' bit). This
leads to several different registration topologies in Mobile IP (note:
cases where the mobile node is using a private address are considered
in Appendix B):
- The most generic is the mobile node that doesn't co-locate,
and registers using a foreign agent's care-of address
(regardless of the state of the 'R' bit in the foreign agent
advertisements) to its home agent. In this case, all the
necessary information to revoke a mobile node's registration
is contained in the registration. The security association
between the agents can be based on IP address, or NAI.
- Second is a mobile node that co-locates, then registers
directly to its home agent without registering through a
foreign agent (foreign agents ignored, 'R' bit irrelevant).
In this case, the home agent MAY notify the mobile node that
its registration is being revoked, but it isn't possible
through Mobile IP for the foreign domain to revoke a mobile
node's registration in this way, nor is it possible for a
foreign domain to suspend Mobile IP services being provided
to a co-located mobile node as the mobile node is doing its
own tunnel decapsulations.
- Lastly is a mobile node that co-locates setting the 'D' bit,
then due to the presence of the 'R' bit in the agent
advertisement(s), registers through a foreign agent with its
home agent.
In the last case, the mobile node has set MNaddr in the
registration request to it's home address, HAaddr to that of its home
agent, and COaddr to its co-located address. Note that nowhere in
this registration request appears the IP address of any foreign agent.
Upon sending the registration request to a foreign agent, that foreign
agent processes the registration, remembering the information it
contains. If the foreign agent shares a security association with the
identified home agent, it MUST append its NAI, and a Foreign-Home
authenticator. The foreign agent then sends the registration request
to the identified home agent using its IP address as the source
address of the datagram. Upon receiving such a registration request,
the home agent MUST check the Foreign-Home authenticator. It does so
by using the NAI if present, or perhaps the source address of the
request. The registration reply the home agent sends MAY contain the
home agent's NAI, but it MUST contain an Home-Foreign authenticator if
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 31
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
a Foreign-Home authenticator was present in the registration request,
and the home agent MUST send the registration reply to the source
address of the registration request [1], in this case the IP address
of the foreign agent.
Note that in cases where a Foreign Agent is able to revoke the
registration of a co-located mobile node, it is expected that such a
foreign agent has the power to control the data-flow of a co-located
mobile node even though tunnel datagrams are being addressed directly
to the mobile node. This is akin to how such a foreign agent would
enforce the 'R' bit, preventing the mobile node from sending the
registration request directly to the home agent.
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 must for
a unique pair in the context of this mobile node to both agents.
Another way of understanding this is that the tunnel endpoint are
in some way connected, and hence 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
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 32
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
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 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 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.
Appendix C: Using Registration Revocation to Help Release Resources
When a mobile node moves out/around a foreign domain from where it
had registered, relevant resources at a previous foreign agent may be
consumed until its visitor entry for the mobile node expires. For
example, consider a cdma2000 network deployment using Mobile IP. The
Wireless IP Network Standard [8] defines foreign agent/Packet Data
Servicing Node (PDSN) procedures for managing the PPP session for a
mobile node, i.e., when the Radio Network opens an R-P session for an
mobile node, the foreign agent/PDSN initiates establishment of a PPP
session. As an mobile node moves from one foreign domain serviced by a
foreign agent/PDSN (source PDSN) to another PDSN (target PDSN) during
an inter-PDSN handoff, a Mobile IP registration is sent to the home
agent and a new PPP session is established at the target PDSN. The
PPP session at the source PDSN remains exhausted until the PPP
inactivity timer expires. Maintaining these PPP sessions may consume
valuable resources at the source PDSN that could otherwise be used to
support additional mobile nodes.
Registration revocation messages can be used to help identify
resources that could be released (without actually having an
administrative revocation).
To accomplish this, the revocation support extension would need to
be appended to a registration request as it is forwarded by a foreign
agent that supports registration revocation. Note that the revocation
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 33
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
support extension is protected by the FA-HA authenticator. When a
home agent that supports registration revocation receives such a
registration request, as required by this specification it MUST record
the capability of this foreign agent. The home agent may then use a
registration revocation message to notify this foreign agent if the
mobile node's care-of address changes, e.g., when the mobile node
moves from one foreign agent to another, or when the mobile node
deregisters with the home agent. As a result, upon receipt of an
authenticated revocation message, the foreign agent can delete the
visitor entry for this mobile node, thereby releasing the resources
being used to support it.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 34
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
Acknowledgments
The authors would like to thank Rajesh Bhalla, Kent Leung, and
Alpesh Patel for their work on draft-subbarao-mobileip-resource-00.txt
"Releasing Resources in Mobile IP" of which the revocation support
extension, and the acknowledgment mechanism are contained in this
document.
Where to Direct Comments
Questions and comments about this draft should be directed at the
Mobile IP working group:
mobile-ip@sunroof.eng.sun.com
Questions and comments about this draft may also be directed to the
authors:
Steven M. Glass Madhavi W. Chandra
Solaris Network Technologies IOS Technologies Division
Sun Microsystems Cisco Systems
1 Network Drive 7025 Kit Creek Road
Burlington, MA. 01801 Research Triangle Park,
NC 27709
Phone: 1.781.442.0504 Phone: 1.919.392.8387
Fax: 1.781.442.1706
E-mail: Steven.Glass@Sun.COM E-mail: mchandra@cisco.com
The working group may also be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Megisto Systems, Inc.
6000 Connection Drive 20251 Century Blvd
M/S M8-540 Suite 120
Irving, Texas 75039 Germantown, MD 20874
USA USA
Phone: +1 972-894-6709 Phone: +1 301-444-1700
Fax : +1 972-894-5349 Fax: +1 301-515-3675
E-Mail: Basavaraj.Patil@nokia.com E-Mail: proberts@megisto.com
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 35
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.
[2] Reverse Tunneling for Mobile IP, revisited
RFC 3024, January 2001
G. Montenegro, Editor.
[3] ICMP Router Discovery Messages
RFC 1256, September 1991
S. Deering, Editor.
[4] Mobile IP Network Access Identifier Extension for IPv4
RFC 2794, March 2000
P. Calhoun, C. Perkins.
[5] Security Issues in Mobile IP
draft-glass-mobileip-securities-issues-02.txt
S. Glass.
[6] Key Words for us in RFCs to INdicate Requirement Levels
RFC 2119, March 1997
S. Bradner
[7] CIDR and Classful Routing
RFC 1817, August 1995
Y. Rekhter
CIDR: an Address Assignment and Aggregation Strategy
RFC 1519, September 1993
V. Fuller, T. Li, J. Yu, K. Varadhan
An Architecture for IP Address Allocation with CIDR
RFC 1518, September 1993
Y. Rekhter, T. Li
[8] TIA/EIA/IS-835, Wireless IP Network Standard, June 2000.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 36
Internet Draft Registration Revocation in Mobile IP Glass, Chandra
Full Copyright Statement
"Copyright (C) The Internet Society (2001 - 2002). All Rights
Reserved."
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to
the Internet Society or other Internet organizations, except as
needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate
it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Expires December 2002 draft-ietf-mobileip-reg-revok-03.txt Page 37
Datatracker
draft-ietf-mobileip-reg-revok-03
Internet-Draft
