Several of the bits used in the registration process need special
consideration when using the revocation mechanism.
4.3.1. The 'R' Bit in Use
If the foreign agent wishes to be able to revoke a mobile node's
registration, it MUST set the 'R' bit in its agent advertisements.
(A foreign agent advertising the 'R' bit requests every mobile node,
even one that is co-located (and whose registration would otherwise
by-pass the foreign agent), to register with the foreign agent.)
However, in this case, the foreign agent SHOULD deny a registration
request as "Administratively Prohibited" from a mobile node that is
registering in a co-located fashion. The reason being that the
foreign agent will not be able to revoke the binding of a co-located
mobile node due to reasons outlined in Section 4.3.2.
How the foreign agent and/or foreign domain enforce the 'R' bit is
beyond the scope of this document.
4.3.2. The 'D' bit in Use
A mobile node registering directly with its home agent in a co-
located fashion with the 'D' bit set in its registration request is
supported in registration revocation. However, support for a co-
located mobile node (with the 'D' bit set in its registration
request) registering via a foreign agent is not supported for the
following reasons.
Registration requests where the 'D' bit is set, and which are relayed
through a foreign agent (e.g., due to the advertising of the 'R' bit)
should theoretically contain the foreign agent address as the source
address of the registration request when received by the home agent.
A home agent may conclude that the source address of this
registration request is not the same as the co-located care-of
address contained in the registration request, and is therefore
likely to be the address of the foreign agent. However, since there
is no way to guarantee that this IP source address is in fact an
address of the foreign agent servicing the mobile node, accepting a
revocation message from this IP source address may lead to a denial-
of-service attack by a man-in-the-middle on the mobile node.
Moreover, there is currently no method for the foreign agent
servicing the mobile node to identify itself to the home agent during
the Mobile IP registration phase. Even if a foreign agent could
identify itself, the co-located mobile node would also need to
authorize that this foreign agent is indeed the agent that is
providing it the Mobile IP services. This is to thwart a denial-of-
service attack on the mobile node by a foreign agent that has a
security association with the home agent, and is on the path between
the co-located mobile node and the home agent.
5. Error Codes
As the intent of a registration revocation message is not a request
to discontinue services, but is a notification that Mobile IP
services are discontinued, there are no new error codes.
6. Security Considerations
There are two potential vulnerabilities, one in the agent
advertisement mechanism, and one related to unauthorized revocation
messages.
6.1. Agent Advertisements
Although the mechanisms defined by this document do not introduce
this problem, it has been recognized that agent advertisements as
defined in [1] subject mobile nodes to a denial-of-service potential.
This is because the agent advertisement as defined in [1] may be
spoofed by other machines residing on the link. This makes it
possible for such nodes to trick the mobile node into believing its
registration has been revoked either by unicasting an advertisement
with a reset sequence number to the link-local address of the mobile
node, or by broadcasting it to the subnet, thereby tricking all
mobile nodes registered with a particular foreign agent into
believing all their registrations have been lost.
There has been some work in this working group and others (e.g.,
IPsec) to secure such router advertisements, though at the time of
this publication, no solutions have become common practice. To help
circumvent possible denial of service issues here, bringing their
potential for disruption to a minimum, mobile node implementors
should ensure that any agent advertisement which doesn't conform to a
strict adherence to [1], specifically those whose TTL is not 1, or
which do not emanate from the same link-address (when present) as
other agent advertisements supposedly from the same agent, or even
that of the last successful registration reply, be silently
discarded.
6.2. Revocation Messages
As registration revocation, when performed, terminates Mobile IP
services being provided to the mobile node, it is crucial that all
security and replay protection mechanisms be verified before a
mobility agent believes that the other agent has revoked a binding.
Messages which are sent link-local (e.g., between mobile node and
foreign agent) MAY also be secured by methods outlined in [1], namely
the use of mobile-foreign authenticators, but these have no direct
relation to registration revocation.
RFC3344 [1] defines a security mechanism that MUST be used between
home agents and mobile nodes, and MAY used between home agents and
foreign agents, namely the use of authenticators. All foreign and
home agents MUST support protection of revocation messages via the
foreign-home authenticators defined in [1]. They MAY implement other
mechanisms of equal or greater strength; if such mechanisms are known
to be available to both parties, they MAY be used instead.
Revocation messages are at least as secure as registration messages
passed between home and foreign agents and containing home-foreign
authenticators as defined in [1]. Thus, there are no new security
threats introduced by the revocation mechanism other than those
present in [1] with respect to the compromise of the shared secret
which is used to generate the home-foreign authenticators.
That said, there are two types of active attacks which use messages
captured "in flight" by a man-in-the-middle between the home and
foreign agents - "malicious repeaters" and "malicious reflectors".
In the case of a "malicious repeater", a man-in-the-middle captures a
revocation message, then replays it to the same IP destination
address at a later time. Presuming the authenticator of the original
packet was deemed valid, without replay protection, the home-foreign
authenticator of the replayed packet will (again) pass
authentication. Note that since datagrams are not guaranteed to
arrive unduplicated, a replay may occur by "design".
In the case of a "malicious reflector," a man-in-the-middle captures
a revocation message, then returns it to its originator at a later
time. If the security association between home and foreign domains
uses a security association involving a (single) shared secret which
only protects the contents of the UDP portion of the packet (such as
home-foreign authenticators as defined by [1]), without replay
protection, the sender of the packet will also believe the revocation
message to be authentic.
The replay protection mechanism used by the revocation messages
defined by this document is designed to protect against both of these
active attacks. As a benefit, by using a 32-bit timestamp it can be
more quickly determined if revocation messages are replays, though
the reader is advised to use caution in this approach. An agent
which receives an authenticated revocation message can compare the
Identifier field to that of a previously received revocation message,
and if the timestamp in the new message is found to have been
generated after that of the time-stamp in the last revocation message
received, it can immediately be determined as not being a replay.
Note however that since datagrams are not guaranteed to arrive in
order, it should not be presumed that because the values contained in
an Identifier field are timestamps that they will necessarily be
increasing with each successive revocation message received. Should
an implementor decide to base his replay detection mechanism on
increasing timestamps, and therefore increasing Identifier values, a
suitable time window should be defined in which revocation messages
can be received. At worst, ignoring any revocation message should
result in the retransmission of another revocation message, this time
with timestamp later than the last one received.
Note that any registration request or reply can be replayed. With
the exchanging of time-stamps by agents in revocation extensions, an
agent should have a belief that such messages have been delivered in
a timely manner. For purposes of registration revocation, the
timeliness of a registration packet is simply based on the
granularity of each registration. Since [1] provides a replay
mechanism for the home agent to use, it has a way to tell if the
registration request being presented to it is new. The foreign
agent, however, has no such mechanism in place with the mobile node.
Foreign agents are advised to continue to consider registrations
'outstanding' until the associated registration reply is returned
from the home agent before using the information in any of its
visitor entries. Even so, this leaves the foreign agent open to a
potential denial of service attack in which registration requests and
replies are replayed by multiple nodes. When this happens, the
foreign agent could be lead to believe such registrations are active,
but with old information, which can have adverse effects on them, as
well as to the ability of that agent to successfully use the
procedures outlined in this document. Sufficient protection against
this scenario is offered by the challenge-response mechanism [2] by
which a foreign agent generates a live challenge to a mobile node for
the purposes of making sure, among other things, that the
registration request is not a replay.
7. IANA Considerations
This document defines an additional set of messages between the home
and foreign agent specific to the services being provided to the same
mobile node, or sub-set of mobile nodes. To ensure correct
interoperation based on this specification, IANA has reserved values
in the Mobile IP number space for two new message types, and a single
new extension.
7.1. New Message Types
The following message types are introduced by this specification:
Registration Revocation: A new Mobile IP control message, using UDP
port 434, type 7. This value has been taken from the same number
space as Mobile IP Registration Request (Type = 1), and Mobile IP
Registration Reply (Type = 3).
Registration Revocation Acknowledgment: A new Mobile IP control
message, using UDP port 434, type 15. This value has been taken from
the same number space as Mobile IP Registration Request (Type = 1),
and Mobile IP Registration Reply (Type = 3).
7.2. New Extension Values
The following extensions are introduced by this specification:
Revocation Support Extension: A new Mobile IP Extension, appended to
a Registration Request, or Registration Reply. The value assigned is
137. This extension is derived from the Extension number space. It
MUST be in the 'skippable' (128 - 255) range as defined in RFC3344.
7.3. New Error Codes
There are no new Mobile IP error codes introduced by this document.
8. References
8.1. Normative References (Numerical)
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC3344,
August 2002.
[2] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response
Extensions", RFC3012, November 2000.
[3] Bradner, S., "Key Words for us in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
8.2. Informational References (Alphabetical)
[A] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
Authentication, Authorization, and Accounting Requirements", RFC
2977, October 2000.
[B] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil,
B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham,
S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B.,
Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and
E. Jaques, "Criteria for Evaluating AAA Protocols for Network
Access", RFC2989, November 2000.
[C] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised",
RFC3024, January 2001.
[D] Deering, S., Ed., "ICMP Router Discovery Messages", RFC1256,
September 1991.
[E] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier
Extension for IPv4", RFC2794, March 2000.
Appendix A: An Example of the Revocation Messages in Use
For clarity, the following example is meant to illustrate the use of
the new messages in the registration phase, and the revocation phase.
In this example, a foreign agent and home agent will negotiate
revocation during the registration phase. During the revocation
phase, the foreign agent will revoke the binding of a mobile node.
A.1. The Registration Phase
Consider a foreign agent that supports registration revocation, and
has a security association with a home agent to which it is
forwarding a registration request. The foreign agent will include
the revocation support extension after the mobile-home authenticator.
Assume that the foreign agent supports the use of the 'I' bit, and is
willing to let the home agent decide if the mobile node should be
informed of the revocation of its registration. Thus, the foreign
agent will set the 'I' bit to '1'. The foreign agent will append a
foreign-home authenticator to the registration request.
Upon receiving the registration request containing a revocation
extension, the home agent will include a revocation support extension
in the registration reply. Since the foreign agent set the 'I' bit
to '1' in its revocation extension, and the home agent supports the
use of the 'I' bit, the home agent will set the 'I' bit in its
registration extension to '1'. Additionally, the home agent will
append a home-foreign authenticator to the registration request.
Upon receiving the authenticated registration reply, the foreign
agent will check the revocation support extension and note that the
home agent wants to decide if the mobile node should be notified in
the event this registration is revoked, i.e., since the home agent
set the 'I' bit in the return revocation extension.
A.2. The Revocation Phase
The foreign agent revokes a mobile node's binding, and generates a
revocation message to be sent to the mobile node's home agent. Since
the 'I' bit was negotiated in the revocation extensions, and the
foreign agent is still willing to let the home agent indicate whether
this mobile node should be informed about the revocation, it will set
the 'I' bit to '1' in the revocation message. The foreign agent also
makes sure the 'A' bit is set to '0'.
The foreign agent will also place the address of the mobile node
whose registration it wishes to revoke in the home address field, the
address that the mobile node registered as the care-of address in the
foreign domain field, and the address registered as the home agent in
the home domain address field. The foreign agent will set the
Revocation Identifier to the current 32-bit timestamp, and append the
foreign-home authenticator.
Upon receiving the above revocation message, the home agent uses the
address identified as the foreign domain address to identify the
security association, and authenticate the revocation message. After
authenticating the message, the home agent will check to make sure
the 'A' bit and Identifier indicate that this revocation is not a
replay. The home agent then uses the mobile node home address,
foreign domain address, and home domain address to locate the mobile
node whose registration is being revoked.
Upon processing a valid registration revocation message, the home
agent generates a revocation acknowledgment message. Since the 'I'
bit was set to '1' in the revocation message and the home agent
wishes for the identified mobile node to be informed of the
revocation, it will set the 'I' bit in the revocation acknowledgment
to '1'. The home agent then copies the home address and the
Revocation Identifier field into the revocation acknowledgement. The
home agent protects the revocation acknowledgment with a home-foreign
authenticator.
Upon receiving a valid revocation acknowledgment (in which the
authenticator and Identifier fields are acceptable), the foreign
agent checks the state of the 'I' bit. Since the 'I' bit is set to
'1', the foreign agent will notify the mobile node of the revocation.
Appendix B: Disparate Address, and Receiver Considerations
Since the registration revocation message comes from a source address
that is topologically routable from the interface receiving the
datagram, the agents, by definition, are topologically connected (if
this were not the case, the initial registration mechanism would have
failed). If either are the ultimate hop from this topologically
connected region to one or more disparate address spaces, no problems
are foreseen. In order for the mobile node to have successfully
registered with its home agent, it MUST have provided to the network
(foreign agent) to which it is currently attached a routable address
of its home agent. Conversely, the care-of address being used by the
mobile node must also be topologically significant to the home agent
in order for the registration reply to have been received, and the
tunnel initiated. By definition, then, the home agent address and
the care-of address must each be significant, and either address must
form a unique pair in the context of this mobile node to both agents.
Another way of understanding this is that the tunnel endpoints are in
some way connected, and hence each are unique as far as the other end
is concerned. The address at the other end of the tunnel, in
combination with the address of the mobile node, must therefore form
a unique pair that can be identified by the agent receiving the
registration revocation message.
As an example, consider a mobile node who's home address lies in
disparate address space A behind its home agent. In the following
diagram, [*] indicates an interface of the entity in which it
appears.
MN[a]-----[c]FA[b]=====((()))=====[b]HA[a]-----[a]CN
Address Some topologically Address
Space C connected network Space A
We presume a binding for MN exists, and hence a tunnel between FA[b]
and HA[b] exists. Then, since the address assigned to MN[a] MUST be
unique in address space A, the pair {FA[b],MN[a]} is guaranteed to be
unique in the binding table of HA, and the pair {HA[b],MN[a]} is
guaranteed to be unique in the foreign agent's visitor list.
As a result, a home agent receiving a registration revocation message
and foreign-home authenticator for MN[a] from FA[b] is able to
determine the unique mobile node address being deregistered.
Conversely a foreign agent receiving a registration revocation
message and home-foreign authenticator for MN[a] from HA[b] is able
to determine the exact mobile node address being deregistered. For
this reason, if a foreign agent receives a registration revocation
message with the home domain field set to the zero address it MUST be
silently discarded. This is to prevent confusion in the case of
overlapping private addresses; when multiple mobile nodes are
registered via the same care-of address and coincidentally using the
same (disparate/private) home address, the home agent address
appearing in the home domain field is the only way a foreign agent
can discern the difference between these mobile nodes.
Acknowledgments
The authors would like to thank Rajesh Bhalla, Kent Leung, and Alpesh
Patel for their contributions to the concepts detailed in
draft-subbarao-mobileip-resource-00.txt, "Releasing Resources in
Mobile IP," from which the revocation support extension, and the
acknowledgment mechanism contained in this document were derived.
The authors would also like to thank Pete McCann for his discussions
on replay mechanisms, and security concerns, and Ahmad Muhanna for
pointing out a problem with the initial replay mechanism, which
eventually lead to the addition of a time stamp to the Revocation
Extension.
The authors would also like to acknowledge Henrik Levkowetz for his
detailed review of the document, and Michael Thomas for his review of
the replay mechanism described herein.
Authors' Addresses
Steven M. Glass
Solaris Network Technologies
Sun Microsystems
1 Network Drive
Burlington, MA. 01801
Phone: +1.781.442.0000
Fax: +1.781.442.1706
EMail: steven.glass@sun.com
Madhavi W. Chandra
IOS Technologies Division
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 27709
Phone: +1.919.392.8387
EMail: mchandra@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.