One document matched: draft-ietf-mobileip-reg-revok-05.txt
Differences from draft-ietf-mobileip-reg-revok-04.txt
Internet Engineering Task Force S. Glass
Mobile IP Working Group Sun Microsystems
Internet Draft M. Chandra
Cisco Systems
February 2003
Registration Revocation in Mobile IPv4
draft-ietf-mobileip-reg-revok-05.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@SUNROOF.ENG.SUN.COM mailing list.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Abstract
This document defines a Mobile IPv4 Registration Revocation mechanism
whereby either mobility agent participating in providing Mobile IP
services to the same mobile node can notify the other mobility agent
(or co-located mobile node) of the termination of either a single, or
multiple mobility bindings, and for this notification to be
acknowledged. A signaling mechanism already defined by the Mobile
IPv4 protocol [1] is leveraged as a way to inform the mobile node(s)
of the revocation of their binding.
S. Glass, M. Chandra Expires August 2003 [page i]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
Table of Contents
1. Introduction and Applicability................................... 1
2. Terminology...................................................... 2
3. Registration Revocation Extensions and Messages.................. 3
3.1 Advertising Registration Revocation Support.................... 3
3.2 Revocation Support Extension................................... 4
3.3 Registration Revocation Message................................ 7
3.3.1 Revocation Mask.............................................11
3.4 Registration Revocation Acknowledgment Message.................13
3.5 Replay Protection..............................................15
4. Registration Revocation Overview.................................17
4.1 Mobile Node Notification.......................................17
4.2 Registration Revocation Mechanism - Agent Notification.........19
4.2.1 Negotiating Revocation Support..............................19
4.2.2 Home Domain Revoking a Registration.........................20
4.2.2.1 Home Agent Responsibilities..............................20
4.2.2.2 Foreign Agent Responsibilities...........................22
4.2.2.3 Co-located Mobile Node Responsibilities..................22
4.2.3 Foreign Domain Revoking a Registration......................23
4.2.3.1 Foreign Agent Responsibilities...........................23
4.2.3.2 Home Agent Responsibilities..............................25
4.2.4 Mobile Node Deregistering a Registration....................26
4.3 The Use of Bits................................................26
4.3.1 The 'R' Bit in Use..........................................27
4.3.2 The 'D' Bit in Use..........................................28
5. Error Codes......................................................29
6. Multiple Binding Support.........................................29
7. Security Considerations..........................................30
7.1 Agent Advertisements...........................................30
7.2 Revocation Messages............................................30
Appendix A Registration Revocation in 'R' and 'D' Bit Worlds........34
Appendix B Disparate Address, and Receiver Considerations...........36
Appendix C Using Registration Revocation to Help Release Resources..38
Appendix D An Example of the New Messages in Use....................39
D.1 The Registration Phase.................................39
D.2 The Revocation Phase...................................40
Acknowledgments......................................................42
Where To Direct Comments.............................................42
References...........................................................43
Full Copyright Statement.............................................44
S. Glass, M. Chandra Expires August 2003 [page ii]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
1. Introduction and Applicability
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 cease
servicing a mobile node, or for administrative reasons may no longer
be required to service a mobile node.
A general registration revocation mechanism is defined for Mobile
IPv4, whereby a mobility agent can notify another mobility agent (or
co-located mobile node) of the termination of mobility bindings. A
mobility agent which receives a revocation notification no longer has
to provide services to the mobile node whose registration has been
revoked. A signaling mechanism already defined by the Mobile IPv4
protocol [1] is leveraged as a way to inform a mobile node
of the revocation of its binding.
The registration revocation protocol provides the following
advantages:
1. Timely release of Mobile IP resources. Resources being consumed
to provide Mobile IP services for mobile nodes that have 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
bindings to expire. This also applies to the case when mobile
nodes roam away from a foreign agent to another foreign agent.
Notification to the previous foreign agent would allow it to
reclaim resources.
2. Accurate accounting. This has a favorable impact on resolving
accounting issues with respect to the length of mobility bindings
in both domains, as the actual end of the registration is relayed.
3. Earlier adoption of domain policy changes with regards to services
offered/required of a Mobile IP binding. For example, the home
domain may now require reverse tunnels, yet there are existing
bindings that do not use them. Without a revocation mechanism,
new services can only be put in place or removed as bindings are
re-registered.
4. Timely notification to a mobile node that it is no longer
receiving mobility services, thereby significantly shortening any
'black-hole' periods to facilitate a more robust recovery.
The revocation protocol is an active, yet unobtrusive mechanism
allowing more timely communication between the three Mobile IP
entities in the various administrative domains. Since many mobile
S. Glass, M. Chandra Expires August 2003 [page 1]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
nodes may not understand the concept of revocation, care has been
taken to ensure that any mobile node that is designed in accordance
with [1] can continue to operate as described by [1].
The registration revocation protocol does not replace the methods
described in [1] for Mobile IP deregistration, as the purpose of both
mechanisms is fundamentally different. Deregistration messages are
used by a mobile node to inform its home agent that it has e.g. roamed
back to its home subnet, whereas revocation messages are used between
mobility agents to signal the termination of mobility bindings. More
specifically, the revocation message defined here is NOT for use by
co-located mobile nodes that are terminating their registration as
deregistration messages are already sufficient for this purpose. A
co-located mobile node, however, may wish to process revocation
messages as it is a useful mechanism to trigger the re-negotiation of
required services from the home domain.
2. Terminology
It is assumed that the reader is familiar with the terminology used in
[1]. In addition, the following terms are defined:
Mobile IP Resources - various functional elements allocated by a
mobility agent to support a Mobile IP binding,
e.g., memory.
Mobile IP Services - various responsibilities of a mobility agent in
supporting a mobile node as defined in [1], e.g,
encapsulation of packets addressed to a mobile
node by a home agent, decapsulation of these
packet by a foreign agent for delivery to a
mobile node, etc.
Mobility Agent - the home agent or foreign agent as specified in [1].
Revocation - termination of a mobility binding.
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].
S. Glass, M. Chandra Expires August 2003 [page 2]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
3. Registration Revocation Extensions and Messages
Registration revocation in Mobile IPv4 is accomplished via the
following messages:
- Revocation Support in Agent Advertisements (Section 3.1):
o A flag in the Agent Advertisement extension has been reserved
for agents to advertise their support of revocation messages.
- Revocation Support Extension (Section 3.2):
o This extension is appended to a registration request or
registration reply by a mobility agent to indicate its support
of registration revocation.
o This extension is appended to a registration request by a
co-located mobile node to indicate its understanding of
revocation messages.
- Revocation Message (Section 3.3):
o A message sent by a mobility agent to inform another mobility
agent, or co-located mobile node, that it has revoked the
binding of a[t least one] mobile node.
- Revocation Acknowledgment Message (Section 3.4):
o A message sent by mobility agents or co-located mobile nodes
to indicate the receipt of a revocation message.
3.1 Advertising Registration Revocation Support
Mobility agents can advertise their support of registration revocation
with a modification to the Mobility Agent Advertisement extension
described in [1]. An 'X' bit is introduced to indicate an agent's
support for Registration Revocation.
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |R|B|H|F|M|G|r|T|X| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
X The mobility agent supports Registration Revocation
S. Glass, M. Chandra Expires August 2003 [page 3]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
A foreign agent that sets the 'X' bit in an agent advertisement
extension MUST support registration revocation messages on that link,
specifically the Revocation Support Extension (section 3.2),
Revocation message (section 3.3), and Revocation Acknowledgment
(section 3.4). It is not required that all agents advertising on the
same link support registration revocation, nor is it required that an
agent advertise this support on all of its links.
Note that using this information, a mobile node can select a foreign
agent that supports registration revocation, e.g., should it be
required by home domain policy. Should a mobile node not understand
this bit, it simply ignores the bit as per [1].
As a bit in the agent advertisement, use of the 'X' bit has no impact
on other messages, such as e.g. Challenge-Response [9]. Security
issues, such as those deployers should be aware of with agent
advertisements, are covered in Section 7 of this document, and [5].
3.2 Revocation Support Extension
The Mobile IP revocation support extension indicates support of
registration revoction, and so MUST be attached to a registration
request or registration reply by any entity that wants to receive
revocation messages. Normally, this is either a foreign agent, or a
home agent, however a co-located mobile node MAY also include a
revocation support extension in its registration request. A foreign
agent advertising the 'X' bit on the link on which the registration
request was recieved, and who has a security relationship with the
home agent identified in the same registration request, MUST attach a
revocation support extention to the forwarded registration request.
A home agent that receives a registration request which does not
contain a revocation extension SHOULD NOT include a revocation support
extension in the associated registration reply.
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 | Timestamp ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Timestamp (continued) |I|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
S. Glass, M. Chandra Expires August 2003 [page 4]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
Type
Skippable. To be assigned by IANA.
Length
Length (in bytes, currently 8). Does NOT include Type
and Length fields(in accordance with section 1.9 of
[1]). This allows for a longer extension length
should more bits be required in the future.
Timestamp
Current 4-byte timestamp of the mobility agent. This
is used to identify the ordering of registrations as
they're forwarded by the agent, how they relate to the
sending of any revocation messages, and to identify
the approximate offset between the clocks of the
mobility agents providing support for this binding..
'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 (section 3.3).
When sent by a foreign agent in a registration request:
If set to 1, indicates to the home agent that the
foreign agent is willing to have the 'I' bit as set by
the home agent in the revocation process 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. The recommended default to maintain
protocol robustness is that the mobile node SHOULD be
informed.
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 the revocation process to indicate to the foreign
agent if the mobile node should be informed or not.
If set to 0, the home agent will not use the 'I' bit
in the revocation process, thereby yielding to the
foreign agent's default behavior with regard to
informing the mobile node. Again, the recommended
behavior to preserve protocol robustness is that the
mobile node SHOULD be informed.
S. Glass, M. Chandra Expires August 2003 [page 5]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
'M' Bit
This bit is set to '1' by a mobility agent to indicate
it supports the use of Masks in revocation messages.
See section 3.3.1.
When sent by a co-located mobile node, this bit MUST
be set to '0'.
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 either by a
foreign-home authentication extension, a mobile-home authentication
extension, or any other equivalent mechanism [1], e.g. via AAA [A],
[B], or perhaps IPSec. If the extension appearing in either of these
registration messages is NOT protected, the appropriate action as
described by [1] MUST be taken. This is due to the security risks as
described by Section 7.
Support of the 'I' bit is OPTIONAL. If a mobility agent does not
support the specified behavior, it MUST set the 'I' bit to zero. Note
that the home agent setting the 'I' bit to '1' in response to a
revocation extension from the foreign agent in which the 'I' bit was
set to '0' is undefined, and SHOULD NOT be done.
'I' bit support has been negotiated when both agents have set the 'I'
bit to '1' in their revocation support extensions.
Support of the 'M' bit is OPTIONAL. If a mobility agent does not
support the specified behavior, it MUST set the 'M' bit to zero.
Note that a mobility agent MUST NOT use the mask in a revocation
message it is sending to another agent unless
receiving a revocation extension from that agent in which the 'M' bit
was set to '1'. See Section 7 on security recommendations when using
the 'M' bit to revoke multiple MN bindings with a single revocation
message.
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
of the registration request. This is to prevent registration
black-holing. For example, a home agent which doesn't understand
registration revocation will continue to process the registration
request which has been forwarded to it, and reply as if the extension
was never included, rather than silently discarding it. This also
means if local policy in the foreign domain requires registrations to
be made only with home agents which support this feature, the foreign
S. Glass, M. Chandra Expires August 2003 [page 6]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
agent may actively deny the registration with this home agent (after
receiving a registration reply which doesn't contain a revocation
support extension), and indicate this to the mobile node (e.g. via 65
"administratively prohibited"). 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 as to why
this was occurring. In this way, use of registration revocation can
be negotiated for each registration, and each domain has a clear
understanding of what is expected.
3.3 Registration Revocation Messages
A revocation message is sent by a mobility agent to inform another
mobility agent, or co-located mobile node, that it is revoking the
binding of a[t least one] mobile node.
The format of revocation message is analogous to registration reply
messages from [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.
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.
S. Glass, M. Chandra Expires August 2003 [page 7]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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 |I| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Domain Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Domain Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Revocation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be assigned by IANA. (Registration Revocation)
Mask A set of flags indicating the applicability of the
registration revocation. See Section 3.2.1 for
definitions.
I Inform bit.
This bit MUST NOT be set to '1' unless 'I' bit support
was negotiated in the revocation extension messages
passed in the registration process, otherwise the
results can be unpredictable.
S. Glass, M. Chandra Expires August 2003 [page 8]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
When sent by the home agent to a foreign agent:
Set to '0' to request the mobile node SHOULD NOT be
informed of the revocation, or because the use of the
'I' bit was not agreed upon.
Set to '1' to request that the mobile node be informed
of the revocation.
When sending a revocation message to a co-located mobile
node, this bit is essentially irrelevant, but SHOULD be
set to '1'.
When sent by the foreign agent:
Set to '0' to indicate to the home agent that the
foreign agent is not asking the home agent whether the
mobile node should be informed of the revocation, or
because 'I' bit support was not agreed upon.
Set to '1' to ask the home agent if the mobile node
should be informed of the revocation.
reserved MUST be sent as 0, ignored when received.
Home Address
The home IP address of the mobile node whose
registration is being revoked, or a subnet address to
indicate bindings for all mobile nodes whose home
address belongs to the identified subnet are being
revoked, or the zero address to indicate all mobile
nodes registered using this home agent and this
care-of address are being revoked. See Section 3.3.1.
Foreign Domain Address
The relevant IP address in the foreign domain to
identify which bindings are being revoked. This is
one of the following: (i) the foreign agent's IP
address, (ii) the co-located care-of address, or (iii)
a subnet address of either (i) or (ii) indicating all
mobile nodes using a care-of address on the identified
subnet are having their bindings revoked. The zero
address MAY be used to indicate "all subnet addresses"
See Section 3.3.1.
S. Glass, M. Chandra Expires August 2003 [page 9]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
Home Domain Address
The IP address in the home domain to identify which
bindings are being revoked. This can be one of the
following: (i) the home agent's IP address, (ii) the
subnet address indicating that all mobile nodes using
a home agent on the identified subnet are having their
bindings revoked. See Section 3.3.1. The zero
address MUST NOT be used, as discussed in Appendix B.
Revocation Identifier
Protects against replay attacks. The revoking agent
MUST insert its current 4-byte timestamp running off
the same clock as it is using to fill in the timestamp
in its revocation extensions. See section 3.5.
A registration revocation message MUST be protected by either a valid
authenticator as specified in [1], namely a home-foreign authenticator
if the communication is between home and foreign agents, or a
mobile-home authenticator if the communication is being sent from a
home agent to a co-located mobile node, or another security mechanism
at least as secure, and agreed upon by the home and foreign domains,
e.g., IPSec and IKE. If any agent, or co-located mobile node receives
a registration revocation message that does not contain a valid
authenticator, and is not adequately protected, the revocation message
MUST be ignored, and silently discarded. See Section 7 for a
discussion on the security considerations involved with sending
revocation messages.
A revocation message MUST NOT be sent for any registration that has
expired, and MAY only be sent prior to the expiration of a mobile
node's registration. Note, however, due to the nature of datagram
delivery, this does not guarantee these messages will arrive before
the natural expiration of any binding.
An agent MUST NOT send more than one revocation message with the same
value in the home address field per second.
An agent MUST NOT send more than one revocation message or
registration message per second for the same binding. Note this
updates [1] by including revocation messages in the limit specified in
[1] that an agent MUST NOT send more than one registration message per
second for the same binding.
An example of the use of revocation messages is given in Appendix D.
S. Glass, M. Chandra Expires August 2003 [page 10]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
3.3.1 Revocation Mask
The use of the revocation mask in the revocation message is OPTIONAL.
The revocation mask MUST NOT be used unless the 'M' bit was set to '1'
in the last revocation extension received from the agent peer for all
bindings identified by the revocation message. When it is not being
used, the revocation mask MUST be set to all zeros. The registration
revocation message uses a non-zero mask to indicate the "extent" of
the revocation is more than a single binding. The mask is used in
combination with the address fields defined above to identify certain
special cases when multiple bindings can be revoked with a single
revocation message. The following bit-values are defined. Note the
four low-order bits apply to addresses, and the four high-order bits
apply to NAIs. For those applying to addresses, prefix length
extensions are required. For those applying to NAIs, NAI extensions
are required.
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
effected.
e.g. revoke: 10.1.1.128, prefixLen: 25 means all mobile nodes
whose addresses fall within the range 10.1.1.128 - 10.1.1.254
and revoke: 10.1.1.129, prefixLen: 25 has the same meaning,
but revoke: 10.1.1.0, prefixLen:25 means all mobile nodes
whose addresses fall within the range 10.1.1.0 - 10.1.1.127.
0x02 Applies to all bindings where the registration is using the
same home domain 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 effected.
(e.g. revoke: 10.1.1.240, prefixLen: 28).
Note that this address MUST NOT be the zero address, see
Appendix B.
S. Glass, M. Chandra Expires August 2003 [page 11]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
0x04 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. revok: 10.1.1.192, prefixLen: 26).
0x08 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. revoke: 10.1.1.224, prefixLen: 27).
0x10 Applies to all bindings within 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 home agent. The issuing agent MUST include the home
agent NAI in an NAI extension appearing after the
revocation message.
0x40 Applies to all bindings with the same administrative domain
as the care-of address. The issuing agent MUST include the
NAI from the care-of domain in an NAI extension, appearing
after the revocation message.
0x80 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.
When multiple flags are set, the corresponding prefix-length and NAI
extensions MUST appear in the same order as the flags appearing in the
mask field of the revocation message. This means NAI extensions MUST
proceed prefix length extensions. For example, if the 0x01 and 0x02
bits are set, the first prefix length extension identifies the prefix
to be used with the care-of address to identify the care-of address
S. Glass, M. Chandra Expires August 2003 [page 12]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
subnet, and the second prefix length extension is to identify the
prefix to be used with the home address to identify the home address
subnet. If the 0x01 bits and 0x20 bits are set instead, the home
agent NAI extension MUST proceed the home address prefix length
extension.
For authentication where domain bindings are being revoked, the
appropriate NAI extension MUST be appended to the revocation message.
For example, a foreign agent revoking all bindings 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 use an NAI containing "@home.domain" have been
revoked.
Note that 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 subnet
a.b.c.0, 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 the foreign agent sending the revocation message.
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, for example, bindings which may be on different
links but being served by the same foreign agent, e.g., a foreign
agent may be servicing different classless subnets [7], each with
their own NAI, or it may be multihomed but using the same CoA for all
its subnets (e.g. disparate address support). See Appendix B in [2]
on disparate address support for a related discussion.
See Section 7 for a discussion on security considerations when
revoking multiple MN bindings with a single revocation message.
3.4 Registration Revocation Acknowledgment Message
A revocation acknowledgment message is sent by mobility agents or
co-located mobile nodes to indicate the successful receipt of a
revocation message.
The format of revocation acknowledgment message is analogous to the
revocation message.
S. Glass, M. Chandra Expires August 2003 [page 13]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Revocation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be assigned by IANA. (Revocation Acknowledgment)
Length (in bytes) 10. The length of the revocation acknowledgment
message in octets, not including Type and Length fields.
I Inform bit.
The 'I' bit MUST NOT be set to '1' in the revocation
acknowledgment messages unless it was set to '1' in the
revocation message. If an agent receives a revocation
acknowledgment message in which the 'I' bit is set to '1',
but for which the revocation message being acknowledged
had the 'I' bit set to '0', the 'I' bit in the revocation
acknowledgment message MUST be ignored.
S. Glass, M. Chandra Expires August 2003 [page 14]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
When sent 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.
When sent by a foreign agent:
Set to '1' to indicate to the home agent that the mobile
node was informed.
Set to '0' to indicate to the home agent that the mobile
node was not informed.
reserved MUST be sent as 0, ignored when received.
Home Address
The home address copied from the revocation message
for which this acknowledgment is being sent.
Revocation Identifier
Copied from the Revocation Identifier of the revocation
message for which this acknowledgment is being sent.
See Section 3.5.
A registration revocation acknowledgment message MUST be sent in
response to a valid and authenticated registration revocation message.
A registration acknowledgment message MUST be protected by either a
valid authenticator as specified in [1], namely a home-foreign
authenticator if the communication is between home and foreign agents,
or a mobile-home authenticator if the communication is between home
agents and co-located mobile nodes, or another security mechanism at
least as secure and agreed upon by the home and foreign domains, e.g.,
IPSec and IKE.
An example of the use of the revocation messages is given in Appendix D.
3.5 Replay Protection
As registration revocation messages are designed to terminate service
for a mobile node, or multiple mobile nodes simultaneously, 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, or by "malicious reflectors" - those
who reflect packets back at their original source (both a form of
S. Glass, M. Chandra Expires August 2003 [page 15]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
"man-in-the-middle" attack). See Section 7 for a discussion of these
security considerations.
Replay protection is handled with a simple timestamp mechanism, using
a single 32-bit identifier field in the registration revocation
message, in conjunction with the home address field, to associate any
revocation acknowledgment messages with its revocation messages. To
do this:
- The revoking agent sets the Revocation Identifier field in the
registration revocation message to a valid 32-bit timestamp from
the same clock it is using to set the timestamp field of its
revocation extensions included in registration messages.
- Upon receipt of an authenticated revocation message, the
receiving agent MUST check the value of the Revocation Identifier
to make sure this revocation message is neither a replay of an
old revocation message received from the same agent, nor a
reflection of a revocation message it sent in relation to the
identified bindings. If the Identifier field implies this packet
is a replay, the revocation message MUST be silently discarded.
- When building a revocation acknowledgment message, the
acknowledging agent copies the values of the Home Address and
Revocation Identifier fields from the revocation message into the
Home Address and the Revocation Identifier of the revocation
acknowledgment message. This is so the revoking agent can match
this revocation acknowledgment to its corresponding revocation
message.
- Upon receiving a valid revocation acknowledgment, the revoking
agent MUST check the Home Address and Identifier fields to make
sure they match those fields from a corresponding revocation
message it sent to the acknowledging agent. If not, this
revocation acknowledgment message MUST be silently discarded.
Note that since the Identifier in an incoming revocation message is a
32-bit timestamp, it is possible for an agent to check the validity of
the Identifier fields without having to remember all identifiers sent
by that corresponding agent. Implementors are encouraged to see the
information in Section 7.
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
the Identifier fields be unique in messages from different agents as
there is no guarantee that clocks on different agents will be
synchronized. For example, if a mobile node has simultaneous bindings
with multiple foreign agents, and two or more are being revoked
S. Glass, M. Chandra Expires August 2003 [page 16]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
simultaneously, it is possible the revocation message from one of
these foreign agents may contain Identifier fields that happens to
match that of any or all the other foreign agents. This MUST NOT
result directly in either of these revocation message being ignored.
4. Registration Revocation Overview
Registration Revocation consists of two disjoint pieces: a signaling
mechanism between tunnel endpoints, and a signaling mechanism between
foreign agent and mobile node. A co-located mobile node MAY implement
revocation extensions and revocation acknowledgment in order to receive
and respond to revocation messages from its home agent, however, a
co-located mobile node MUST NOT send a revocation message 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.
A brief overview of the mechanics of the sequence number in agent
advertisement from [1] is given so that 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.
S. Glass, M. Chandra Expires August 2003 [page 17]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
Leveraging this mechanism, a foreign agent may consciously notify all
mobile nodes currently bound to it that it has "reset" all of their
bindings, even if the agent itself has not been reset, by simply 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 'B' bit in the advertisement to 1, indicating this foriegn
agent is busy and is not accepting new registrations [1]. In these
situations, any mobile node in compliance with [1] will presume the
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 in these
agent advertisements, indicating it is busy, and is not accepting new
registrations [1]. 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 can use
foreign agent fallback to attempt to register with a different foreign
agent as described in [1].
Mobile nodes which understand the revocation mechanism described by this
document may understand that a unicast agent advertisement with the
sequence number reset to 0 could indicate a revocation, and may attempt
to re-register with the same foreign agent, register with a different
foreign agent, or co-locate.
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. Such mechanisms are
highly desirable to protect from denial-of-service attacks.
Implementors and deployers may wish to see section 7 of this document,
and [5].
S. Glass, M. Chandra Expires August 2003 [page 18]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
4.2 Registration Revocation Mechanism - Agent Notification
A foreign agent that is currently supporting registration
revocation on a link MUST set the 'X' bit in its Agent Advertisement
Extensions being sent on that link. This will encourage mobile nodes
from domains wishing to use registration revocation to register with
those foreign agents advertising its support. Implementors and those
deploying registration revocation should read section 7 for an
understanding of security issues specific to registration revocation.
4.2.1 Negotiation of Revocation Support
During the registration process, if the foreign agent wishes to
participate in revocation messages with the home domain, it MUST have
an existing security association with the home agent identified in the
registration request, and append a revocation support extension
(defined in Section 3.2) to it. If the corresponding registration
reply from this home agent does not contain a revocation support
extension, the foreign agent SHOULD assume the home agent does not
understand registration revocation, or is unwilling to participate.
If this is unacceptable to the foreign agent, it MAY deny the
registration with e.g. "Administratively Prohibited." Note that in
this case where a security association exists, as specified in [1],
both registration request and registration reply MUST still contain
home-foreign authenticators.
If a home agent wishes to participate in revocation messages with the
foreign domain, it MUST have an existing security association with the
foreign agent who relayed the registration request, and it MUST append
a revocation support extension to the registration reply. If the
registration request from a foreign agent did not contain a revocation
support extension, the home agent SHOULD assume the foreign agent does
not understand registration revocation, or is unwilling to participate
specifically for this binding. If this is unacceptable to the home
agent, it MAY deny the registration with e.g. "Administratively
Prohibited" The home agent MAY include a revocation support extension
in the registration reply anyway.
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.
The 'I' bit in the revocation extension is used to indicate whether the
decision to inform the mobile node that its binding is terminated will
be left to the home agent. 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
S. Glass, M. Chandra Expires August 2003 [page 19]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
that it MAY leave the decision to inform this mobile node that its
registration is terminated up 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.
The 'M' bit in the revocation extension is used to indicate support of
the revocation mask in the registration revocation message. By
sending a revocation extension in which the 'M' bit is set to '1' that
agent is indicating it is willing to accept non-zero Mask values in
the revocation message. Thus, the agent is agreeing to revoke
multiple bindings by receiving a single revocation message. Note that
unlike the 'I' bit, it is not necessary for both sides to agree on
revocation mask support. A mobility agent MUST NOT send a revocation
message with a non-zero mask to an agent that did not set the 'M' bit
to '1' in its most recent revocation extension for that binding. If
an agent that did not set the 'M' bit to '1' in its most recent
revocation extension, receives a revocation message with a non-zero
mask, it MUST silently discard the revocation message.
Revocation support is considered to be negotiated for a binding when
both sides have included a revocation support extension during a
successful registration exchange.
4.2.2 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.2.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 care-of address, or a
co-located care-of address.
When a revocation message is being sent to a foreign agent, 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
foreign agent to inform the mobile node of the revocation. Conversely,
if the home agent does not want the mobile node notified, it MUST set
the 'I' bit to 0.
S. Glass, M. Chandra Expires August 2003 [page 20]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
If the 'M' bit was set to '0' in the last revocation extension from
the foreign agent, the home agent MUST set the Mask to 0x00. If the
'M' bit was set to '1' in the last revocation extension from this
foreign agent, the home agent MAY set the mask to a non-zero value as
described by section 3.3.1.
Whenever a home agent is sending a revocation message to a co-located
mobile node, the revocation mask MUST be set to 0x00.
Note also that if a reverse tunnel is in place, it may be necessary
for the home agent to keep the reverse-tunnel de-capsulation active in
order to receive the revocation acknowledgment from that mobile node.
The home agent MUST set the Identifier field as defined in Section
3.5, and MUST include a valid authenticator as specified in Section
3.3.
If the home agent does not receive a revocation acknowledgment message
within a reasonable amount of time, it MUST retransmit the revocation
message. How long the home agent waits to retransmit, and how many
times the message is retransmitted is only limited by the
requirements:
- every time the home agent is about to retransmit the revocation
message, it MUST update the value of the timestamp in the
revocation identifier with a current value from the same clock
used to generate the timestamps in the revocation extensions
sent to this foreign agent. Note that this also necessarily
means updating any fields derived using the revocation
identifier (e.g. a home-foreign authenticator).
- the home agent MUST NOT send more than one revocation per second
for a particular binding, or set of bindings,
- the time between retransmissions SHOULD fall-back in analogy
with the registration guidelines in [1], and
- the home agent MUST NOT retransmit revocation messages beyond
the normal life of the bindings identified by the revocation
message.
Note that if a co-located 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 mobile node and foreign agent. When a home agent is revoking the
binding of a co-located mobile node which is registered with a foreign
agent, the home agent SHOULD send the revocation message to the
co-located mobile node first so that the revocation acknowledgment has
S. Glass, M. Chandra Expires August 2003 [page 21]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
a chance of making it back to the home agent. The revocation message
to be sent to the foreign agent SHOULD be sent after receiving the
revocation acknowledgment from the mobile node.
Alternatively, if a home agent is revoking the binding of a co-located
mobile node which is registered with a foreign agent, the home agent
MAY simply send a revocation message to the foreign agent requesting
the mobile node be informed of the revocation by setting the 'I' bit
to '1'. In this way the mobile node will be informed should the
foreign agent agree to do so. If the foreign agent does not inform
the mobile node, however, it may be impossible for the home agent to
notify the mobile node of its revoked binding.
4.2.2.2 Foreign Agent Responsibilities
Upon receiving a registration revocation message, the foreign agent
MUST check that the validity of the authenticator, and of the home
address and identifier field against replay as defined by Section 3.5.
The foreign agent MUST then 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, the home domain address, any prefix and/or
NAI extensions, as well as the timestamp in the revocation message,
and also the timestamp in the last accepted registration message;
revocations are only valid for existing registrations, and so the
timestamp of a registration MUST proceed the revocation message (note
that both of those timestamps were set by the same home agent). Upon
locating such bindings, the foreign agent MUST revoke them, and MUST
respond with a revocation acknowledgment sent to the source address of
the revocation message. If the 'I' bit was negotiated, the foreign
agent MUST check the value of the 'I' bit in the revocation message
and act accordingly.
If notifying the mobile node by the methods described in Section 4.1,
the foreign agent MUST set the 'I' bit to '1' in the revocation
acknowledgment to be sent to the home agent, or if not notifying the
mobile node, the foreign agent MUST set the 'I' bit to '0'.
The foreign agent may discontinue all Mobile IP services, and free up
any resources that were being used by the former binding(s).
S. Glass, M. Chandra Expires August 2003 [page 22]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
The foreign agent MUST then generate a revocation acknowledgment,
setting the Home Address and Identifier field in the revocation
acknowledgment message as described by Section 3.5, and protect it
with a valid authenticator as specified in Section 3.3.
4.2.2.3 Co-located Mobile Node Responsibilities
Upon receiving a revocation message, the co-located mobile node MUST
validate the authenticator, and check the home address and identifier
specified in the revocation message for replay. If the packet passes
authentication, and the identifier reveals this revocation to be new,
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
first generate a revocation acknowledgment message which MUST be sent
to the IP source address of the revocation message. The mobile node
may then terminate any reverse tunnel encapsulation it is using to
this home agent, and consider its binding revoked, and free up any
other resources associated with the former binding.
4.2.3 Foreign Domain Revoking/Releasing a Registration
The following section details the responsibilities of each party
depending on the functionality negotiated in the revocation support
extensions when the foreign domain is revoking a registration.
4.2.3.1 Foreign Agent Responsibilities
If the use of the 'I' bit was negotiated, and the foreign domain
policy of informing the mobile node has not changed since the last
successful registration exchange, 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. If the policy on the foreign domain was to not notify the
mobile node, or if it has changed since the most recent successful
registration, and the foreign agent is no longer able to use the 'I'
bit, 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.
To preserve the robustness of the protocol, the recommended default is
that the foreign agent SHOULD inform the mobile node of its revocation
as described in Section 4.1 either 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.
S. Glass, M. Chandra Expires August 2003 [page 23]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
If the 'M' bit was set to '0' in the last revocation extension from
the home agent, the foreign agent MUST set the Mask to 0x00. If the
'M' bit was set to '1' in the last revocation extension from this
home agent, the foreign agent MAY set the mask to a non-zero value as
described by section 3.3.1.
Before transmitting the revocation message, the foreign agent MUST set
the revocation identifier as described by section 3.5, and MUST
include an authenticator as described by section 3.3.
If the foreign agent does not receive a revocation acknowledgment
message within a reasonable amount of time, it MUST retransmit the
revocation message. 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:
- every time the foreign agent is about to retransmit the
revocation message, it MUST update the value of the timestamp in
the revocation identifier with a current value from the same
clock used to generate the timestamps in the revocation
extensions sent to this home agent. Note that this also
necessarily means updating any fields derived using the
revocation identifier (e.g. a home-foreign authenticator).
- MUST NOT send more than one revocation per second for a
particular set of bindings,
- SHOULD set its retransmissions to fall-back in analogy with the
registration guidelines in [1], and
- MUST NOT retransmit revocation messages beyond the normal life
of any of the bindings identified by the revocation message.
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 was unlikely to 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. (Note: it
is presumed the foreign agent had the 'R' bit set when such a
co-located 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").
S. Glass, M. Chandra Expires August 2003 [page 24]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
4.2.3.2 Home Agent Responsibilities
Upon receiving a registration revocation message, the home agent MUST
check the authenticator, and identifier field. If the packet is
acceptable, the home agent MUST locate the binding(s) identified by
the foreign agent as being released using the information in the
revocation message, namely the addresses identified by the home
address, the foreign domain address, the home domain address fields,
any prefix-length or NAI extensions, as well as the timestamp in the
revocation message, and also the timestamp in the last accepted
registration message; revocations are only valid for existing
registrations, and so the timestamp of a registration MUST proceed the
revocation message (note that both of those timestamps were set by the
same foreignagent). 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 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 care-of addresses provided by this foreign agent (as in the case
of multi-homed foreign agent), each set of bindings must be revoked
separately.
Upon processing a valid registration revocation message, the home
agent MUST send a revocation acknowledgment to the IP source address
of the registration revocation message.
If use of the 'I' bit was negotiated, and the 'I' bit is set to '1' in
the revocation message, the home agent SHOULD decide if it wants the
mobile node informed of the revocation of this binding. If it does
want the mobile node informed, it MUST set the 'I' bit in the
revocation acknowledgment message to '1'. If it does not want the
mobile node informed, it MUST set the 'I' bit to '0'.
The home agent MUST set the Home Address, and Revocation Identifier
fields as described by Section 3.5, and protect the revocation
acknowledgment message with a valid authenticator as specified in
Section 3.3.
S. Glass, M. Chandra Expires August 2003 [page 25]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
4.2.4 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, or registered
via a foreign agent (and in either case may be co-located), and wishes
to terminate it's own binding, the mobile node MUST NOT send a
revocation message, but 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.
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, 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 likely 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 MAY check to see if that address is the care-of
address identified in the care-of address field of the registration
request (if not, the source address of the registration request is
likely that of the foreign agent). Alternatively, as any such NAI
S. Glass, M. Chandra Expires August 2003 [page 26]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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 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.3. 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. Since the co-located care-of
address is by definition topologically correct, the reader must
understand that a co-located mobile node may send the registration
request directly to the home agent, and perhaps receive a registration
reply from the home agent even in the presence of agent advertisements
in which the 'R' bit is set (though this is considered "bad form", and
the 'R' bit is a "hint" to the mobile node that such direct contact is
policed in some way). In the event a foreign domain wishes to 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 for local policy to
not provide a mechanism for co-location, or for the foreign agent to
simply not accept registration requests from co-located mobile nodes,
though there are enforcement mechanisms available which allow
co-location.
S. Glass, M. Chandra Expires August 2003 [page 27]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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 so the home agent may know how to validate the
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 MAY
verify that the source address of this registration request is not the
same as the care-of address contained in the registration request, and
is therefore likely to be the address of a foreign agent. The reader
should 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,
and/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.
This includes the time for any necessary retransmissions should a
revocation acknowledgment not be forthcoming. A revocation message
S. Glass, M. Chandra Expires August 2003 [page 28]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
MUST then be sent to the foreign agent. If a 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 most recently accepted
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. 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. Multiple Binding Support
RFC 3344 [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 on a single link, and the foreign agent has the 'R' bit set,
or because the foreign agent is multi-homed and the mobile node has
registered all these care-of addresses using multiple binding support
[1]). Either agent can indicate the revocation of all these bindings
by identifying the mobile node's home address, and home agent address,
and 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
identified by this revocation message.
If a foreign agent revokes a particular mobile node's binding(s), 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
easy to specify, be they for multiple mobile nodes, or
multiply-registered mobile nodes, even in situations where network
S. Glass, M. Chandra Expires August 2003 [page 29]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
topologies make revoking multiple mobile node bindings difficult to
specify numerically through the use of NAIs.
7. Security Considerations
There are two basic susceptibilities, one in agent advertisement
mechanism, and one relating to unauthorized revocation messages.
7.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 advertisements 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. For particulars regarding this issue,
the reader is referred to [5].
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 e.g. which
do not emanate from the same link-address (when present) as the last
successful registration reply, be silently discarded.
7.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 any bindings.
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.
S. Glass, M. Chandra Expires August 2003 [page 30]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
RFC 3344 [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. Revocation messages
defined in this document which are passed between home and foreign
agents in the revocation process MUST be protected by either the same
foreign-home authenticators defined in [1], or another authentication
mechanism at least as secure and agreed upon by the end agents, e.g.,
IPSec and IKE. It is important that domains using registration
revocation negotiate security associations commensurate with the level
of protection needed to secure these messages. When the mechanism to
revoke multiple mobile node bindings with a single revocation message
is employed (namely the revocation mask), it is advised that domain
policy allow for strong authentication such as IPSec and IKE between
the end agents to be used. This is recommended since the Mobile IP
authentication used to set up a MN binding is between a particular MN
and home agent, and may not be sufficient to authorize the revoking of
multiple MNs. Robust security policy between the end agents will
thwart denial-of-service attacks that may arise if multiple MN
bindings are revoked and cleared without proper authorization.
Revocation messages for single bindings 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
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 replay 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 protections 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" where 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.
S. Glass, M. Chandra Expires August 2003 [page 31]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
The replay protection mechanism used by the revocation messages
defined by this document is designed to protect against both of these
man-in-the-middle 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 either in 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 [9] 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.
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
S. Glass, M. Chandra Expires August 2003 [page 32]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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.
S. Glass, M. Chandra Expires August 2003 [page 33]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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
S. Glass, M. Chandra Expires August 2003 [page 34]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
home agent's NAI, but it MUST contain a home-foreign authenticator if
a foreign-home authenticator was present in the registration request,
and the home agent MUST send the registration reply to the source
address of the registration request [1], in this case the IP address
of the foreign agent.
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.
S. Glass, M. Chandra Expires August 2003 [page 35]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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 endpoint 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 it's 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(es) 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
S. Glass, M. Chandra Expires August 2003 [page 36]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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.
S. Glass, M. Chandra Expires August 2003 [page 37]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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 a 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
support extension is protected by the foreign-home 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.
S. Glass, M. Chandra Expires August 2003 [page 38]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
Appendix D: 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.
D.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 MAY include the revocation support extension
after the mobile-home authenticator. 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 MAY set the 'I' bit to '1'. If the foreign agent is willing to
process revocation messages with a non-zero mask, it SHOULD set the
'M' 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 MAY
include a revocation support extension in the registration reply. If
the foreign agent 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 MUST set the 'I' bit
in its registration extension to '1'. The home agent should note the
value of the 'M' bit, and if the home agent is willing to process
revocation messages with a non-zero mask, it SHOULD set the 'M' bit in
its revocation 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].
Upon receiving the authenticated registration reply, the foreign agent
MUST check the revocation support extension. If none is present, the
foreign agent SHOULD assume that the home agent doesn't understand
revocation messages, or is unwilling to participate. If a revocation
support extension is present, and if the foreign agent included the
revocation extension in the registration request with the 'I' bit set
to '1', the foreign agent MUST 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. The foreign agent SHOULD also
note the value of the 'M' bit as set by the home agent.
S. Glass, M. Chandra Expires August 2003 [page 39]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
D.2 The Revocation Phase
If a foreign agent wishes to inform a home agent that is is revoking a
mobile node's registration, it generates a revocation message. If the
'I' bit was 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
will set the 'I' bit to '1'. 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 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.
Alternatively, if the home agent set the 'M' bit to '1' in its most
recent revocation extension, the foreign agent MAY set any of the
addresses to a subnet-like value, and set the mask to a corresponding
non-zero value. The foreign agent MUST set the Revocation Identifier
to the current 32-bit timestamp. If the Mask was set to a non-zero
value, the foreign agent MUST attach the necessary prefix length or NAI
extensions as described by section 3.3.1. The foreign agent MUST also
append a foreign-home authenticator, and any additional information it
needs to include for the home agent to validate it (e.g. 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
MUST check to make sure the Identifier does NOT indicate this
revocation is a replay. The home agent then 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
Mask is set to a non-zero value, and the home agent is unwilling to
process multiple revocations, it MUST silently ignore the revocation
message.
Upon processing a valid registration revocation message, the home
agent MUST generate a revocation acknowledgment message. If the 'I'
bit was negotiated in the registration phase for the binding(s)
identified, the home agent will check to see if the 'I' bit is set to
'1' in the 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 acknowledgment 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
acknowledgment to '0'. The home agent then copies the home addresses,
S. Glass, M. Chandra Expires August 2003 [page 40]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
and the Revocation Identifier field into the reply. The home agent
MUST protect the revocation acknowledgment with either a home-foreign
authenticator (and any other extension necessary for the foreign agent
to authenticate the home-foreign authenticator, e.g. its NAI
extension), or any method deemed suitable by the home-foreign security
association.
Upon receiving a valid revocation acknowledgment (in which the
authenticator and Identifier fields are acceptable), if the foreign
agent set the 'I' bit in the revocation message to '1', it MUST check
the 'I' bit in the revocation acknowledgment, and if set to '1', MUST
notify the mobile node of the revocation, or if the 'I' bit is set to
'0' in the revocation acknowledgment, the foreign agent MUST NOT
notify the mobile node of the revocation.
S. Glass, M. Chandra Expires August 2003 [page 41]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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" from which the revocation support
extension, and the acknowledgment mechanism contained in this document
were derived. The authors would also like 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 the timestamp in the
Revocation Extension.
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
S. Glass, M. Chandra Expires August 2003 [page 42]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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
RFC2989, 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
RFC3344, August 2002
C. Perkins, Editor.
[2] Reverse Tunneling for Mobile IP, revisited
RFC3024, 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
[8] TIA/EIA/IS-835, Wireless IP Network Standard, June 2000.
[9] Challenge/Response in Mobile IPv4
RFC 3012, November 2000
C. Perkins, P. Calhoun
S. Glass, M. Chandra Expires August 2003 [page 43]
Internet Draft Registration Revocation in Mobile IPv4 February 2003
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.
S. Glass, M. Chandra Expires August 2003 [page 44]
| PAFTECH AB 2003-2026 | 2026-04-21 10:07:54 |