Internet Engineering Task Force                               S. Glass
INTERNET DRAFT                                        Sun Microsystems
                                                            March 2001


                   Registration Revocation in Mobile IP
                   draft-ietf-mobileip-reg-revok-00.txt


Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   This document is a submission to the Mobile IP Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at:
        http://www.ietf.org/shadow.html.

   Distribution of this memo is unlimited.



Abstract

    During the original design of Mobile IP, the potential need for an
administrative domain to be able to actively revoke a current Mobile
IP registration was recognized.  Due to the lack of a specific
scenario requiring such a mechanism, it was decided that instead of
designing a mechanism explicitly for the purpos of registration
revocation, a passive mechanism, namely short registration lifetimes,
and the denial of a subsequent registration of a MN, would be sufficient
for this purpose.

    Investigations into requirements for a AAA protocol within the AAA
working group have forced reconsideration of a more pro-active Mobile IP
registration revocation feature.  Revocation MUST be possible from
either home or foriegn domains, so any registration revocation mechanism
being defined must also allow signaling to the mobility agent providing
Mobile IP functionality at the other end of the tunnel that the current
registration has been revoked.  Moreover, the MN whose registration is


S. Glass                 Expires September, 2001                [page i]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


being revoked MUST also be informed that such a revocation is occuring,
though the reasons for such a revocation should not necessarily be
relayed.  In some cases the current registration may be terminated to
simply force the MN to renegotiate its registration, and in other cases
the registration is terminated absolutely with no renegotiation allowed
by the terminating side.

   This document defines such a general use registration revocation
mechanism, meeting these requirements.



   Table of Contents:

   1.  Introduction................................................. 1
   2.  Motivation................................................... 3
   3.  Registration Revocation Details.............................. 3
     3.1  Mobie Node Notification................................... 3
     3.2  Registration Revocation Mechanism - Agent Notificiation... 5
       3.2.1  Home Domain Revoking a Registration................... 5
       3.2.2  Foreign Domain Revoking a Registration................ 6
       3.2.3  The Use of Bits....................................... 6
         3.2.3.1  The 'R' Bit in Use................................ 7
         3.2.3.2  The 'D' Bit in Use................................ 7
     3.3  Revocation Message Format................................. 8
       3.3.1  Revocation Mask...................................... 11
   4.  Replay Protection........................................... 12
   5.  No New Error Codes.......................................... 13
   6.  Multiple Binding Support.................................... 13
     6.1  Other Random Protocol Details............................ 14
   7.  Security Considerations..................................... 14

   Appendix A: Registration Revocation in 'R' and 'D' Bit Worlds... 15
   Appendix B: Disparate Address, and Receiver Considerations...... 16

   Where to Direct Comments........................................ 18
   References...................................................... 19
   Full Copyright Statement........................................ 20



   1.  Introduction

   During the original design of Mobile IP, the potential need for
either home or foreign administrative domain to be able to cancel a
current mobile ip registration was recognized.  Due to the lack of
specific need for such a mechanism, however, it was decided that a
passive mechanism, namely the denial of a subsequent registration from a
MN, in conjunction with the recommendation for short registration
lifetimes could be used, and was sufficient for this purpose.  Recently,
requirements for a AAA protocol have forced a requirement for a more
pro-active Mobile IP feature to revoke a mobile node's current


S. Glass                 Expires September, 2001                [page 1]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


registration [9], thereby informing the mobilty agent performing the mobile
ip services at the other end of the tunnel that a current registration
has been revoked, and also informing the mobile node that it's current
registration has been revoked.

   A general registration revocation mechanism is defined to handle
these situations.  The protocol is broken into two disjoint pieces.
First, a mechanism to inform the mobile node of the revocation of it's
current binding is described using a mechanism which already exists in
the base mobile ip protocol [1].  This means any mobile node which is
designed to comply with [1] will understand it's registration has been
revoked.  Next, a signaling mechanism between home and foreign agents is
described which allows either the home or foreign domain to inform the
the agent at the other end of the tunnel it has torn down the current
tunnel, allowing it to free up the resources associated with the
indicated mobile ip binding.

   In addition, revocation messages pass information between the
mobility agents as to whether the registration is revoked conditionally,
or absolutely.  A conditional revocation means the MN's current
registration is terminated, but may be renegotiated in subsequent
reregistration attempts.  Such revocations serve the purpose of forcing
the mobile node to renegotiate its mobile ip registration, thereby
either incorporating, or waiving some or all of the service
characteristics of its mobility binding (e.g. forcing multicast
services to be setup as soon as they are needed, or a forcing a reverse
tunnel to be torn-down as soon as the foreign domain decides it no
longer wishes to support it).  An absolute revocation, as the name
implies, means the mobile node's current registration is terminated and
no renegotiation [through the current foreign agent] will be allowed
(note that this may be desireable from either home or foreign
administrative domains).

    The methods described in [1] for deregistrations apply to situations
where the mobile node is playing the active roll in informing the home
agent of its location, and maintaining its care-of address(es).
Revocation messages are a logical addition to the messages defined in
[1] for generic mobile ip registration processing, and apply to
situations where mobility agent's need to play an active roll in
administering mobile ip registrations.  This document therefore
describes methods to be used only when mobility agents are initiating
the revocation of individual bindings for specific mobile nodes, and the
methods defined by this document are NOT to be applied to co-located
mobile nodes that are terminating their registration as deregistration
requests for such a [co-located] care of addresses is already sufficient
for this purpose.

   This reader is assumed to be familiar with the concepts and
terminology used in [1] and [5].  Knowledge of the concepts of [2] and
[3] is also be beneficial.




S. Glass                 Expires September, 2001                [page 2]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


  2.  Motivation

   Mobile IP [1], [3] defines registration of a mobile node's location
to provide connectivity between the mobile node and its home domain,
facilitating communication between a mobile node and any correspondant
node.  At any time either home or foreign agent MAY stop servicing a
mobile node, but no mechanism has been described to inform the mobility
agent providing Mobile IP services at the other end of the tunnel that
such services have been terminated.  Moreover, a mobile node may be
informed that a foreign agent has lost its binding if that agent has
reset, and is advertising with reset sequence numbers, but there is
currently no way for a mobile node to know when a home agent has done
the same thing.  If the home agent shuts down the tunnel, the foreign
agent will simply stop seeing tunnel packets for the MN, just as if a
route stopped functioning, or if there is simply no traffic for the
mobile node.  If the foreign agent shuts down the tunnel, the home
agent will continue sending tunnel packets, which will likely be
silently discarded.  An aware mobile node may notice the lack of
response to packets it is generating, eventually guessing it's binding
may have vanished, and may attempt to reregister.  Only at the time
when the mobile node attempts to reregister will it get a registration
denied error with some hint as to why it service was stopped, and by
whom.  Clearly a more active mechanism needs to be provided allowing
more timely communication between the three mobile ip entites in the
administrative domains.



    3.  Registration Revocation Details

    Registration revocation consists of two disjoint pieces, a
signalling mechanism between the tunnel endpoints, and a signalling
mechanism between the foreign agent and mobile node.  A colocated
mobile node, that is one which is decapsulating it's own tunnel
traffic, MAY implement the tunnel endpoint-signaling portion of this
protocol in order for its home agent to notify it if it's binding is
being terminated.  A mobile node that is colocated, however, SHOULD
NOT implement the tunnel endpoint signaling portion of this protocol
as deregistration messages as defined in [1] are sufficient for this
purpose.


    3.1  Mobile Node Notification

    A mechanism providing a foreign agent a way to activly notify a
mobile node that its binding has been reset already exists in [1],
though it has been overlooked for this purpose.  When a foreign agent
begins sending agent advertisements, it starts with a sequence number
of 0, and [monotonically] increments this sequence number with each
subsequent agent advertisement.  In order for a mobile node to be able
to distinguish between a foreign agent which has reset its state from
one which has simply exhaused it sequence number space, when the


S. Glass                 Expires September, 2001                [page 3]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


sequence number reaches the maximum allowed by the size of the
sequence number field, instead of being allowed to roll over to 0, the
foreign agent instead sets it to 256, and then continues to increase
it [monotonically].  In this way, for a mobile node to become confused
into believing its state was lost by the foreign agent, the mobile
node would have to believe it missed 256 agent advertisements from the
foreign agent it registered with.  The lifetimes advertised in an
agent advertisement should be configured in such a way that when a
mobile node hasn't seen one for the period of 3 agent advertisements
beacon periods, it should be soliciting, e.g. agent advertisement
beacon rate is every 5 seconds, the lifetime of each advertisement is
(at least, but not significantly more than) 15 seconds.  In this way
the mobile node will be soliciting this foreign agent long before it
could have missed 256 of its agent advertisements.

    Leveraging this mechanism, a foreign agent may consciously notify
all mobile node's currently bound to it that it has "reset" all their
bindings, even if the agent itself has not been reset, by simply
[re]setting the sequence number of an agent advertisement to 0
(technically anywhere in the range 0 - 253 inclusive, allowing room
for a mobile node to miss one or two beacons after the "reset").
Moreover, a foreign agent may inform all mobile nodes currently bound
to it they should reregister with a different foreign agent by
simultaneously setting the 'B' bit to 1 in these agent advertisement
in which the sequence number has been [re]set to 0 (or again anywhere
in the range 0 - 253 inclusive), indicating it is busy and is not
accepting new registrations.  In these situations, any mobile node in
compliance with [1] understands the FA has lost its binding, and must
reregister if they wish to reestablish tunnels, and Mobile IP
functionality with their home agent.

    By using this mechanism, a foreign agent may also notify a single
mobile node that it's binding has been reset by unicasting to it, as
described by [1] and [4] an agent advertisement with the sequence
number set to 0 (0 - 253 inclusive).  If such a foreign agent wishes
to indicate to the mobile node that it 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.  Note that such a foreign agent is likely
to not be advertising with the 'B' bit set to 1 in its
multicast/broadcast agent advertisements, so other mobile node's will
still register with it.  If upon hearing the multicast agent
advertisement, should a mobile node that has recently had it's
registration revoked by this FA attempt to [re]register with it, the
agent can simply deny the MN with an appropriate error code
(e.g. "administratively prohibited").  At this time, the mobile node
SHOULD use foreign agent fallback to attempt to register with a
different agent as described in [1].  If the mobile node decides to
send an agent solicitation, this foreign agent MAY ignore the mobile
nodes' solicitation, or MAY again unicast its agent advertisement to
the mobile node with the 'B' bit set to 1.



S. Glass                 Expires September, 2001                [page 4]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


    Agent Advertisements unicast to a mobile node MUST be sent as
described in [1], in addition to any methods currently in use on the
link to make them secure or authenticatable by the mobile node.


    3.2  Registration Revocation Mechanism  - Agent Notification

    Any active mechanism designed to be useful to both home and
foreign domains must contain a way for either side to securely revoke
the current binding.  This means the registration process must supply
the both home and foreign domains with enough information to be able
to inform the other side of a revocation.  Any information the foreign
agent appends to the registration request MUST therefore be protected
by a FA-HA authenticator, and therefore the registration reply MUST
contain a HA-FA authenticator.  Due to the nature of revoking a
registration, it is likely the authenticators would be required by
policy between the home and foreign domain anyway.  If a mobile node
is colocated, and a foreign agent is not involved in the registration
process, then a home agent MAY inform the colocated mobile node its
binding is revoked by sending it a revocation message protected by a
HA-MN authenticator.  A mobile node that is terminating (one of) its
own bindings, however, does not have to send a revocation message to
its home agent.  The method described in [1], namely deregistering a
care-of address, is sufficent, and the mechanism detailed in this
document is not meant to replace it.

    3.2.1  Home Domain Revoking a Registration

    In the case where the home agent is revoking a mobile node's
binding, the home agent SHOULD notify the care-of address it is
terminating the tunnel entry point.

    If the mobile node is not colocated (as indicated to the HA by the
setting of the 'D' bit in its registration request) a home-foreign
security association must exist, and MUST be included in the
registration revocation message.  Upon receiving such a notification,
the foreign agent MUST check the home-foreign authenticator, and if
the packet passes the authentication, the foreign agent SHOULD notify
the mobile node that its binding has been reset by using the method
described in section 3.1 above, and MAY free up any resources being
used by the former binding, and discontinue all Mobile IP services for
this mobile node.  The foreign agent MAY respond with a revocation
confirmation which MUST contain a foreign-home authenticator to be
verified by the home agent.  If a foreign agent receives a
registration revocation message that does not contain a home-foreign
authenticator, it MUST be ignored, and silently discarded.

    If the home agent is revoking the registration of a mobile node
which is colocated, a mobile-home autenticator MUST be used.  Upon
receiving such a notification, the mobile node MUST check the
mobile-home authenticator, and if the packet passes authentication,
the mobile node SHOULD terminate any reverse tunnel encapsulation it


S. Glass                 Expires September, 2001                [page5i]

Internet Draft    Registration Revocation in Mobile IP       March, 2001


is using to the home agent.  The mobile node MAY also free up any
other resources associated with the former binding.

    The cases where a mobile node is registered with it's home agent,
whether it is registered directly with its home agent (as in the case
of co-location), or registered via a foreign agent (if it is colocated
or not), and wishes to terminate it's own binding, the mobile node
SHOULD simply deregsiter its Care-of Address with its home agent as
described by [1] or [3].  If a colocated mobile nodes receives an
authenticated registration revocation from its home agent, a mobile
node MAY generate a revocation confirmation in response.  In this
scenario, the mobile node MUST include a mobile-home authenticator.

    3.2.2  Foreign Domain Revoking a Registration

    In the case where the foreign domain is revoking a mobile node's
binding, the foreign agent SHOULD notify the mobile node as described
in section 3.1 above.  In addtion, an foreign agent which is
terminating the binding of a mobile node SHOULD inform the home agent
the mobile node is registered with that it is shutting-down the tunnel
exit point (and reverse tunnel entry point).  This will allow the home
agent to stop generating tunnel packets from datagrams destined for
the mobile node, and also allow it to free resourses it is currently
reserving for the mobile node.  In this case, if the most recent
registraint request indicated the mobile node is using a colocated
care-of address, the foreign agent MUST include its NAI for
identification by the home agent.  A foreign-home authenticator MUST
be included at all times in the registration revocation message.  Upon
receiving a registration revocation message, the home agent MUST check
the foreign-home authenticator, and if the packet passes the
authentication, MAY free up any resources associated with the former
binding and discontinue all Mobile IP services for this mobile node.
It MAY at that time send a revocation confirmation to the address
identified as the care-of address in the registration revocation
message.  If a home agent receives a registration revocation message
that does not contain a foreign-home authenticator, it MUST be
ignored, and silently discarded.

    3.2.3  The Use of Bits

    Several of the bits used in the registration process play an
important roll in the topology of the binding.  The 'R' bit in the
agent advertisement is an effective way to assure the foreign domain
is provided with the binding information neccessary to revoke it,
especially important in the case of a colocated mobile node.  In
addition, the 'D' bit in the registration request is a sign to a home
domain that the foreign agent's address doesn't appear in the
registration request, and so the home agent may be missing the
necessary information to be able to notify the foreign agent in the
even of a registration revocation.  More information, and an example,
is provided in Appendix A: Registration Revocation in 'R' and 'D' Bit
Worlds.


S. Glass                 Expires September, 2001                [page 6]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


    3.2.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 to
be privy to the registration information of the mobile node.  A
foreign agent advertising the 'R' bit requests a mobile node, even one
that is colocated, to register [it's colocated address as its care-of
address] with a foreign agent, making the foreign agent then capable
of revoking the mobile node's registration as it is privy to the
information in the registration request, namely the mobile node's home
address, and the address of the mobile node's home agent, by sending a
Registration Revocation to the home agent, and unicasting an agent
advertisement to the mobile node as described in section 3.2.2, and
3.1 above.  This makes advertising the 'R' bit attractive in domains
that wish to have control over registered mobile nodes, and moreover,
revocation notification to the home domain may be a contractual
necessity.

    Enforcment of the 'R' bit is beyond the scope of this document,
and when the foreign domain wishes to be able force the revocation,
and/or to notify the home domain of revoked registrations, such an
enforcement mechnism is crucial.  A colocated mobile node sets the 'D'
bit in its registration request, and since by definition the colocated
address is topologically significant for the link the mobile node is
visiting, the registration request may be sent directly to the home
agent (though this is considered "bad form", and the 'R' bit is a
"hint" to the mobile node that such direct contact is policed in some
way).  In the event a foreign domain wishes to immediately revok the
registration of a colocated mobile node (which is not the same as
denying subsequent registrations from this mobile node), the foreign
domain MUST be able to control the flow of datagrams to, and/or from,
the mobile node.  The easiest way to do this is to not accept
registration requests from colocated mobile nodes, though there are
other mechanisms available.  A foreign agent that wishes to deny a
registration request from a mobile node because it is colocated SHOULD
return error 77 "invalid care-of address" whenever a mobile node
specifies a care-of address other than that of the foreign agent
and/or sets the 'D' bit in its registration requests [1].

    3.2.3.2  The 'D' bit in Use

    If the mobile node has set the 'D' bit in the registration
request, and the foreign agent determins it will accept the
registration from the mobile node, if the foreign domain wants to be
notified of registration revocations for this mobile node, the foreign
agent MUST append its NAI extension to the registration request, and
MAY also append the prefix length extension that appears in the agent
advertisements on the link the mobile node is registering.  The
inclusion of the prefix length extension is so the home agent
understands the topology of the link the mobile node is visiting in
the event it wants to issue a single registration revocation for
multiple mobile nodes visiting the same link. The foreign agent MUST


S. Glass                 Expires September, 2001                [page 7]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


then append a FA-HA authenticator.  If the home agent accepts the
registration request, registration revocation messages for this
binding MUST be sent to the foreign agent, and MAY also be sent the
mobile node's colocated care-of address.

    Home agents which receive a registration request with the 'D' bit
set, in which an NAI appears but no FA-HA authenticator is appended,
SHOULD deny the registration request with error 132 "foreign agent
failed authentication".  Moreover, if an FA-HA authenticator is
present, but no foreign agent NAI appears, the home agent SHOULD reply
with error 97, "Missing NAI" (note: the mobile node will be able to
tell this was returned by the home agent since it will be protected by
the HA-MN authenticator; if it was the mobile node's NAI that was
missing, the foreign agent would likely be returning this error, but
certainly the registration reply would not contain a HA-MN
authenticator).  A home agent that receives a registration request
with the 'D' bit set, and no foreign agent NAI, nor a FA-HA
authenticator SHOULD assume the registration request came directly
from a colocated mobile node, and therefore MUST send the registration
reply, and any registration revocation message to the colocated
care-of address.


    3.3  Revocation Message Format

    This section details the format of the signalling protocol between
home and foreign agents, or from a home agent to a colocated mobile
node.

    The format of revocation message(s) is nearly identical to
registration request and registration request messages.

    IP fields:

        Source Address       In the case of the home agent issuing the
                             Registration Revocation, the address
                             registered with the care-of address (and
                             therefore registered with the foreign
                             agent if one was privy to the
                             registration) as that of the home agent.

                             In the case of the foreign agent issuing
                             the registration revocation, if the
                             registration being revoked is NOT for a
                             colocated mobile node, the address
                             registered with the home agent as the
                             care-of address. In the case of the
                             revocation of a colocated mobile node,
                             any of the addresses of the foreign agent
                             associated with the NAI included in the
                             most recent registration request to the
                             home agent.


S. Glass                 Expires September, 2001                [page 8]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


        Destination Address  In the case of the home agent issuing the
                             registration revocation, if the 'D' bit
                             was set in the most recent registration,
                             the address associated with the NAI of
                             the foreign agent, if one was present.
                             If no NAI was present, or if the 'D' bit
                             was NOT set, then the address registered
                             as the care-of address of the mobile node
                             whose registration is being revoked
                             (note: this will either be the mobile
                             node's colocated care-of address, or the
                             address specified as the care-of address
                             by the foreign agent respectively).

                             In the case of the foreign agent issuing
                             the registration revocation, the home
                             agent address registered by the mobile
                             node whose registration is being revoked.

    UDP fields:              Source Port        434
                             Destination Port   434

   The UDP header is followed by the Mobile IP fields shown below
(the format of which is identical to registration requests in [1]):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-+-+-
   | Authenticator ...
   +-+-+-+-+-+-+-+-+-+-

    Type       7  (Registration Revocation)  (T.B.A.)

    Code       A set of flags indicating the applicability of the
               Registration Revocation.  See below for definitions.





S. Glass                 Expires September, 2001                [page 9]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


    Lifetime   The lifetime of the registration revocation, that is
               the amount of time the mobile node is to be denied
               reregistration.  A value of zero indicates the mobile
               node's current registration is terminated, but may be
               allowed reregistration attempts immediately.  A value
               of 0xffff indicates the current registration is revoked
               for an infinite time, and no further reregistration
               attempts will be accepted.

    Home Address
               The IP address of the mobile node whose registration is
               being revoked, or the subnet address indicating that
               all mobile nodes belonging to this subnet are having
               their registration revoked, or the zero address if all
               mobile nodes who are registered using this home agent
               and this care-of address are being revoked.

    Home Agent
               The IP address identified as that of the home agent of
               this binding, or the subnet address indicating that all
               mobile nodes using a home agent on the identified
               subnet are having their bindings revoked, or the zero
               address if all mobile node bindings using the
               identified care-of address are being revoked.

    Care-of Address
               The IP address identified as that of the care-of
               address of this binding, or the subnet address
               indicating that all mobile nodes using a care-of
               address on the identified subnet are having their
               bindings revoked, or the zero address if all mobile
               node bindings using the identified home agent address
               are being revoked.

    Identification
               A 32-bit number used for protecting against replay
               attacks.  See section 6 (below).

    Extensions
               Any relavent extensions for this registration
               revocation.  e.g. Vendor-specific extensions.

    Authenticator
               An authenticator as defined in [1] MUST be present.
               This is usually in the form of an HA-FA authenticator,
               or a HA-MN authenticator when the HA is revoking the
               registration of a mobile node which is using a
               colocated care-of address.






S. Glass                 Expires September, 2001               [page 10]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


    3.3.1  Revocation Mask

    The use of the revocation mask is optional.  If it is not used, it
MUST be set to zero.  The registration revocation message MAY use this
to indicate the "extent" of the revocation.  In all cases, the
revocation message indicates the current binding has been lost.  The
following codes are defined:

    Value   Meaning
    -----   -----------------------------------------------------------
     0x01   Apply to all bindings with the same subnet as the MN.
                Issuing agent inlcudes prefix-length extension.
     0x02   Applies to all bindings with the same subnet as the CoA.
                Issuing agent inlcudes prefix-length extension.
     0x04   Applies to all bindings with the same subnet as the FA
                Issuing agent inlcudes prefix-length extension.
     0x08   Applies to all bindings with the same subnet as the HA.
                Issuing agent includes prefix-length extension.
     0x10   Applies to all bindings with the same administrative domain
                as the mobile node.  (MN-NAI MUST be present)
     0x20   Applies to all bindings with the same administrative domain
                as the care-of address.  (CoA-NAI present!?!)
     0x40   Applies to all bindings with the same administrative domain
                as the foreign agent.  (FA-NAI MUST be present)
     0x80   Applies to all bindings with the same administrative domain
                as the home agent.  (HA-NAI MUST be present)

    In all cases, when the revocation mask is non-zero, the revoking
agent SHOULD include a prefix length extension in the revocation
message.  For authentication where domain bindings are being revoked,
the appropriate NAI MUST be included in the revocation message.  As
always, revocation messages MUST be authenticated, and the scope of
the revocation MUST only apply to the subset of bindings between the
revoking agent, and the agent receiving the revocation message.
E.g. foreign agent x.y.z.t sends a revocation message to home agent
a.b.c.d for mobile node a.b.c.x, sets the revocation mask to 0x01
The home agent MUST NOT revok all of its bindings for mobile nodes on
the same home link as the revoked mobile node, but only those mobile
nodes that are also visiting this foreign agent.

    Note: the distinction between bindings in the same subnet as the
CoA (0x02), and bindings in the same subnet as the FA (0x04) is to be
able to discern bindings which may be on different virtual links, that
is an FA may be servicing different CIDR subnets, or it may be
multihomed though using the same CoA for all these subnets.  See the
appendix on disparate address support in [2] for a related discussion.

    The code should be interpreted in conjunction with the lifetime.
For example, a code of 0 with a lifetime of 0 indicates the current
binding is revoked, and future registrations will be accepted
immediately.  A code of 0 with a lifetime of 10 indicates the current
registration is revoked, and future registrations will be accepted
after 10 seconds have passed.

S. Glass                 Expires September, 2001               [page 11]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


    If a mobile node attempts to reregister before the revocation
lifetime has expired, the foreign agent MAY simply reply with error
65, "Administratively prohibited" saving it from tying up resources
while the registration would otherwise be pending approval by the home
agent.



    4. Replay Protection

    As Registration Revocation messages are designed to terminate
service for a mobile node, replay protection is crucial to prevent
denial of service attacks by "malicious repeaters" - those who store
datagrams with the intent of replaying them at a later time (a form of
"man-in-the-middle" attack).  Such a packet, presuming it passed
authentication the first time, would pass subsequent times without a
replay protection mechanism to identify the datagram as a repeat,
would trick the receiving mobility agent to suspend its mobile ip
services for the mobile node itentified by the replayed packet.
Moreover, though it is rare, since datagrams are not guaranteed to
arrive unduplicated (that is datagrams may be duplicated in flight so
the receiver sees multiples of the same datagram), this may happen by
"design".

    Replay protection is handled through a 32-bit identification field
in the registration revocation message. After a registration
revocation message has been authenticated, the ID field MUST NOT match
that in any other authenticated registration revocation message from
the same mobility agent (foreign agent care-of address/home agent
address), and for the same mobile node home address.  If the ID field
is not unique, message MUST be silently discarded.

    Note: as it is possible for a mobile node to register at different
times with different home agents, and at different times with
different foreign agents, it is crucial that it not be required that
this ID field be unique in messages from different agents as there is
no method for this information to be communicated between agents.  For
example, if a mobile node has simultaneous bindingings with multiple
foreign agents, and these are being revoked, it is possible the
revocation message from one of the foreign agents may contain an ID
field that happens to match that of the other foreign agent's
registratoin revocation received before it.  This MUST NOT result in
the latter revocation message being ignored.  It is expected that an
agent may simply use a single number for replay protection, and
increment it whenever it revokes a binding to any other agent.  In
this case, the agent is limited to a number of revocations equal to
the length of the ID field.  A better approach is to have a unique
value for each agent, thereby greatly increasing the lifetime of this
feature.  The reader should note that the ID field used in replay
protection of registration requests (technically) suffers from the
same limitations.



S. Glass                 Expires September, 2001               [page 12]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


    5. No New Error Codes

    As the intent of a registration revocation message is not a
request, but essentially a notification that mobile ip services are
discontinued, there are no new error codes.  If any registration
revocation fails authentication, or replay protection (as described in
section 4 above), it MUST be silently discarded, and mobile ip
services are therefore not suspended.  Registration revocation
messages which are authenticated MUST be checked to make sure the
information they contain accurately identifies a current session.  If
so, the registration revocation message indicates the mobility agent
that sent the message has already terminated, or is about to
terminate, its mobile ip services for this mobile node.  The receiving
agent SHOULD free any resources currently being used for the binding
being revoked.

    Upon processing a registration revocation, a mobility agent MAY
repsond with its own Revocation message to indicate it has received
and processed the message, but is not required to do so.  A mobility
agent that sent a registration revocation messages MAY wait for a
revocation confirmation to discontinue mobile ip services to the
mobile node.



    6. Multiple Binding Support

    [1] allows a mobile node to register multiple care-of addresses
with its home agent.  Each one of these bindings is it's own discrete
tunnel, and hence can be treated as a separate case for registration
revocation.  Consider the situation where a mobile node has multiple
care-of addresses registered with a single foreign agent (either
because the mobile node has multiple colocated care-of addresses and
the foreign agent has the 'R' bit set, or because the foreign agent is
multi-homed).  Either agent can indicate the revocation of all these
bindings by setting the care-of address field to -1, indicating all
care-of addresses being used by the indicated mobile node that are
bound to the agent identifying itself by this revocation message.

    If a foreign agent revoks a particular mobile node's binding(s)
with it, the home agent MAY or MAY NOT revok 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 revok a single binding for a mobile node, the foreign agent
MAY decide to revok other bindings for the same mobile node as it sees
fit.

    The revocation mask is designed to make revoking multiple bindings
easier to specify, and where network topologies make revoiking
multiple mobile node bindings dificult.



S. Glass                 Expires September, 2001               [page 13]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


    6.1  Other Random Protocol Details

    If a foreign agent is revocing a specific registration for a
mobile node, it MUST include the registered care-of address, the home
address of the mobile node whose registration is being revoked, and
the home agent address of the current binding.  If a foreign agent is
revoking the bindings of all mobile nodes using a particular home
agent, it MAY set the home address field to the zero address.  If a
foreign agent is revoking multiple care-of address bindings for the
same mobile node, it MAY set the care-of address to the zero address.
However, if a home agent receives a registration revocation from a
foreign agent indicating the registration for a colocated mobile node
has been revoked, the home agent MUST verify this message is comming
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
colocated care-of addresses, and in addition has one or more bindings
using foreign agent provided care-of addresses (as in the case of
multi-homed foreign agent), each set of bindings must be revoked
separately.



    7. Security Considerations

    [1] defines a security mechanism that MUST bused by home agents
and mobile nodes, and optionally foreign agents.  All messages defined
in this document MUST use the security mechanisms defined in [1], and
are therefore as secure as those in the core mobile IP protocol.  As
registration revocation, when performed, terminates mobile IP services
being provided to the mobile node, it is crucial that all security and
replay protections mechanisms be verified before a mobility agent
recognizes that the other agent has revoked a mobile node's binding,
and frees up the resources it has reserved for this service.  Messages
which are sent link-local (e.g. between mobile node and foreign agent)
MAY also be secured by methods outlined in [1], but have no relation
to the enhancement described by this document.

    [5] describes the use of the Network Access Identifier in Mobile
IP.  It's use here is for the agent to identify each other in a
revocation message.  In the cases where the foreign and home domains
are going to approve registrations from a colocated mobile node ('D'
bit), and in topologies where the foreign agent is going to set the
'R' bit in its agent advertisements, the security association the home
agent shares with the foreign agent MUST somehow include the address
the home agent should send registration revocation messages to
(e.g. the source address of the relayed registration request [1], or a
more authoritative address), or the foreign agent that will be
relaying such registration requests MUST be able to authenticate the


S. Glass                 Expires September, 2001               [page 14]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


HA-NAI.  Note that registration request setting the 'D' bit, and which
are relayted through a foreign agent due to the advertising of the 'R'
bit contain the foreign agent address as the source address of the
registration request as received by the home agent.  See appendix A
below.

    It has been recognized that agent advertisements as defined in [1]
provide a denial-of-service potential [6].  This is because the agent
advertisements as defined in [1] may be spoofed by other machines
residing on the link.  This may make it possible for such nodes to
trick the mobile node into believing its registration has been revoked
either by unicasting such an advertisement to the link-local address
of the mobile node, or by broadcasting it to the subnet, thereby
tricking all mobile nodes registered with a particular foreign agent
into believing all their registrations have been lost.  There has been
some work in this working group and others (e.g. IPSec) to secure such
router advertisements, though at the time of this publication, no
solutions have become common practice.



    Appendix A: Registration Revocation in 'R' and 'D' Bit Worlds.

    Two things influence the registration of a mobile node on a
foreign subnet.  First is the mobile node's desire to colocate (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 colocate,
          and registers using a foreign agent's care-of address
          (regardless of the state of the 'R' bit in the foreign agent
          advertisements) to its home agent.  In this case, both
          mobility agents have the necessary information to revoke a
          mobile node's registration.  The security association
          between the agents can be based on IP address, or NAI.

        - Second is a mobile node that colocates, then registers
          directly to its home agent without registering through a
          foreign agent (FAs ignored, 'R' bit irrelavent).  In this
          case,  home agent, depending on the implementation at the
          mobile node, MAY notify the mobile node that its
          registration is being revoked, but it isn't possible through
          mobile ip for the foreign domain to revoke a mobile node
          registered in this way, nor is it possible for a foreign
          domain to suspend mobile ip services being provided to a
          colocated mobile node registered in this way as the mobile
          node is doing its own tunnel decapsulations.




S. Glass                 Expires September, 2001               [page 15]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


        - Lastly is a mobile node that colocates setting the 'D' bit,
          then due to the presence of the 'R' bit in the agent
          advertisement(s), registers through a foreign agent with its
          home agent.

    In this case, the mobile node has set MNaddr in the registration
request to it's home address, HAaddr to that of its home agent, and
COaddr to its colocated address.  Note that nowhere in this
registration request appears the IP address of any foreign agent.
Upon sending the registration request to a foreign agent, that foreign
agent processes the registration, remembering the information it
contains.  If the foreign agent shares a security association with the
identified home agent, it SHOULD append its NAI, and a FA-HA
authenticator.  The foreign agent then sends the registration request
to the identified home agent using its IP address as the source
address of the datagram.  Upon receiving the registration request, the
home agent MUST check the FA-HA authenticator, if present.  It does so
by using the NAI if present, or the source address of the request.
The registration reply the home agent sends MAY contain the home
agent's NAI, but it MUST contain an HA-FA authenticator if a FA-HA
autenticator was present in the registration request, and the home
agent MUST send the registration reply to the source address of the
registration request [1], in this case the IP address of the foreign
agent.

    In this way the foreign agent receives the registration reply, and
can confirm the validity of the information contained in the
registration request.  Furthermore, it is expected that such a foreign
agent has the power to control the revocation of a the mobile nodes
registration although tunnel datagrams are being delivered directly to
the colocated care-of address identified by the registration request
the same as it is assumed such a foreign agent can enforce the mobile
node from sending the registration request directly to the home agent.



    Appendix B: Disparate Address, and Receiver Considerations

    Since the registration revocation message comes from a source
address that is topologically routable from the interface receiving
the datagram, the agents, by definition, are topologically connected
(if this were not the case, the initial registration mechanism would
have failed).  If either are connecting this topologically connected
region to one or more disparate address spaces no problems are
forseen.  In order for the mobile node to have sucessfully registered
with its home agent, it MUST have provided to the network to which it is
currently attached a routeable address of its home agent.  Conversely,
the care of address being used by the mobile node must also be
topologically significant to the home agent in order for the
registration reply to have been received, and the tunnel initiated.
By definition, then, the home agent address and the care of address
must each be significant, and either address, when combined with the


S. Glass                 Expires September, 2001               [page 16]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


mobile node's home address, must for a unique pair to the entity on
the other end of the tunnel.

    Another way of understanding this is that the tunnel endpoint are
in some way connected, and hence are unique as far as the other end is
concerned.  The address at the other end of the tunnel, in combination
with the address of the mobile node, must form a unique pair that can
be identified by the agent receiving the registration revocation
message.

    As an example, consider a mobile node who's home address lies in
disparate address space A behind it's home agent.

    MN[a]-----[c]FA[b]-----((()))-----[b]HA[a]-----[a]CN

        Address      Some topologically      Address
        Space C       conected network       Space A

    If we assume there must be a tunnel in existence at the time of
the registration revocation, namely between FA[b] and HA[b], then the
pair {FA[b],MN[a]} is guaranteed to be unique in the home agent
bindings, and the pair {HA[b],MN[a]} is guaranteed to be unique in the
foreign agent's visitor list.

    As a result of this, a home agent receiving a regstration
revocation message and FA-HA authenticator for MN[a] from (IP source
address) FA[b] is able to determine the unique mobile node address
being deregistered (if one is provided).  Conversely a foreign agent
feceiving a registration revocation message and HA-FA authenticator
for MN[a] from HA[b] is able to determine the unique mobile node
address being deregistered (if one is provided).

    If a foreign agent receives a registration revocation
message with the home agent field set to the zero address it MUST be
silently ignored.  This is to prevent confusion in the case of
overlapping private addresses; when multiple mobile nodes are
registered via the same care-of address using the same
(disparate/private) home address, the home agent address is the only
way a foreign agent can discern these mobile nodes.















S. Glass                 Expires September, 2001               [page 17]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


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 author:

        Steven M. Glass
        Internet Engineering
        Sun Microsystems
        1 Network Drive
        Burlington, MA.  01801

        Phone:  1.781.442.0504
        Fax:    1.781.442.1706
        E-mail: Steven.Glass@Sun.COM


    The working group may also be contacted via the current chairs:

        Basavaraj Patil                     Phil Roberts
        Nokia Corporation                   Motorola
        6000 Connection Drive               1501 West Shure Drive
        M/S M8-540
        Irving, Texas 75039                 Arlington Heights, IL 60004
        USA                                 USA
        Phone:  +1 972-894-6709             Phone:  +1 847-632-3148
        Fax :   +1 972-894-5349
        eMail:  Basavaraj.Patil@nokia.com   eMail: phil.roberts@motorola.com






















S. Glass                 Expires September, 2001               [page 18]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


References

      [A] Mobile IP Authentication, Authorization, and Accounting
              Requirements
          RFC 2977, October 2000
          S. Glass, T. Hiller, S. Jacobs, C. Perkins.

      [B] Criteria for Evaluating AAA Protocols for Network Access
          RFC 2989, November 2000
          B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann,
              H. Shiino, P. Walsh, G. Zorn, G. Dommety, C. Perkins,
              B. Patil, D. Mitton, S. Manning, M. Beadles, X. Chen,
              S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, B. Lim,
              B. Hirschman, R. Hsu, H. Koo, M. Lipford, E. Campbell,
              Y. Xu, S. Baba, E. Jaques

      [1] IPv4 Mobility Support
          RFC 2002, October 1996
          C. Perkins, Editor.

      [2] Reverse Tunneling for Mobile IP, revisited
          RFC 3024, January 2001
          G. Montenegro, Editor.

      [3] Mobility Support in IPv6
          work in progress, revision 13, November 2000
          D. Johnson and C. Perkins.

      [4] ICMP Router Discovery Messages
          RFC 1256, September 1991
          S. Deering, Editor.

      [5] Mobile IP Network Access Identifier Extension for IPv4,
          RFC 2794, March 2000
          P. Calhoun, C. Perkins.

      [6] Security Issues in Mobile IP,
          work in progress
          S. Glass.















S. Glass                 Expires September, 2001               [page 19]


Internet Draft    Registration Revocation in Mobile IP       March, 2001


Full Copyright Statement

     "Copyright (C) The Internet Society (2001).  All Rights Reserved.

      This document and translations of it may be copied and furnished
      to others, and derivative works that comment on or otherwise
      explain it or assist in its implementation may be prepared, copied,
      published and distributed, in whole or in part, without
      restriction of any kind, provided that the above copyright notice
      and this paragraph are included on all such copies and derivative
      works.  However, this document itself may not be modified in any
      way, such as by removing the copyright notice or references to the
      Internet Society or other Internet organizations, except as needed
      for the purpose of developing Internet standards in which case the
      procedures for copyrights defined in the Internet Standards
      process must be followed, or as required to translate it into
      languages other than English.

      The limited permissions granted above are perpetual and will not
      be revoked by the Internet Society or its successors or assigns.

      This document and the information contained herein is provided on
      an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
      ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
      IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
      THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



























S. Glass                 Expires September, 2001               [page 20]