Subject: RE: [mobile-ip] Question about the I Bit in the Revocation Acknow ledgement Messag e

From: "Ahmad Muhanna"<[email-masked]>
Date: Sun, 14 Apr 2002 22:43:44 -0500

Hello Steve;
Thanks again. 

But I am interested in keeping the discussion. 
I hope you do not mind.

Ahmad

> 
> > >     Ahmad,
> > > 
> > >    Actually, there is (but it's not what you expect).  
> Since there's a
> > > constraint in the base protocol that a home agent can't generate a
> > > 'registration request' that is NOT in response to a 
> > > 'registration reply' it
> > > means that the MN will not be in a state to receive any 
> > > registration messages. 
> > > I don't want this to change, since it means a significant 
> change in MN
> > > architecture.  
> > 
> > Well, does this mean that MN can not receive a MIP RRQ 
> message or any kind
> > of request.
> 
>     I presume you mean RRP, but at any rate it means the MN 
> is likely to
> discard anything it does receive (of course depending on the 
> implementation,
> but most I've seen use a state machine approach, and are only 
> listenning when
> they're expecting a RRP).  We could e.g. specify a different 
> port for these
> messages, and have the FA relay them to the MN (note the 
> colocated MN already
> gets these messages directly), but again this complicates 
> both FA and MN the
> implementations.  For the same functionality, I see it as 
> unnecessary (see
> below).
>

I am sure that legacy MN is listenning when expecting RRP, ONLY. 
But MN could listen to for example some kind of Revocation request. 
It seems that the current approach requires the Co-located MN to do 
almost the same work as FA while it receives a secure information. 
However, MN registered with FA COA is not supposed to implement 
any thing but the messaging is not secure.

I agree, if FA needs to forward a revocation request all the way to the
MN, it would complicate the FA functionality a little bit more than what 
the current proposal has.

However, there are two points that can be mentioned here:

1. This process is (relatively speaking) rarely used. In other words,
It is not as expensinve as the MIP Registration.
2. The current approach requires the FA for example to remember
those MN which are permanently revoked and this is very expensive
for the FA to keep track with too.

> 
> > >As I said, there is more secure end2end 
> > > solution, and that is
> > > what happens after the revocation.  If the FA notifies the MN 
> > > its binding has
> > > been lost, or certainly when the binding would normally 
> > > expire, the MN will
> > > [likely] attempt to reregister.  
> > 
> > Would not be nice if we inform the MN why it lost its binding?
> > It seems to me that we are using a mechanism that was meant 
> to be rarely
> > used, 
> > in case of rebooting the FA, to inform the MN that its 
> registration is
> > revoked.
> 
>     Well, rarely used or not, it serves this communication 
> purpose (without
> the 'why').  Yes, I'd prefer if the unicast 'I lost your 
> binding' messages
> were secure, but someone could already forge these, and if 
> they are forged, if
> the MN immediately reregisters, it'll get its registration 
> back; this solution
> doesn't leave the MN more prone to these attacks.
> 
>     Note that there could be reasons for the FA or the HA to 
> want the MN
> informed that its binding is lost, but not tell it why (e.g. 
> a simple 'minimal
> information' approach, or perhaps 'feign outage', etc).  
> [Re]using this
> mechanism does that initially, and if there's more 
> information to be had by
> the MN, it gets provided at reregistration time.  Note also 
> that colocated MNs
> that support registration revocation can get the information 
> directly from the
> HA, so if this is what you want, it's motivation to support 
> colocation!  There
> are usually multiple approaches to a solution, and I'm not 
> sure this is
> something significantly lacking in this particular approach.
> 
>                               Cheers,
>                                   Steve
> 

I am sure it is a good idea to offer an end-to-end solution MN to HA which
can be used for this revocation just as the co-located and may be those 
legacy MN can expect to recieve AA message with sequence number rolling back
to 0 or they have the option to discard the message. 

Thanks,
Ahmad

---

From: "Steven M. Glass" <[email-masked]>
Date: Mon, 15 Apr 2002 18:24:06 -0400 (EDT)

> But I am interested in keeping the discussion. 

    Hey - this is why we're all here!

> But MN could listen to for example some kind of Revocation request. 

    Already deployed MNs never will.  Note also that revocations are never
requests!  They're provided only if the policy on the other side
allows/requires the update on the binding (e.g. for billing reasons).

> almost the same work as FA while it receives a secure information. 

    This is a byproduct of the colocation, not because of anything this
document outlines for revocation support.  MNs are their own FAs in terms of
obtaining a CoA, decapsulation, and encapsulation in the case of a reverse
tunnel.

> any thing but the messaging is not secure.

    The signal from the FA is not secure.  Any follow up response (if
provided) from the HA will be, as will be any from an FA with which the MN has
a SA (FA-MN authenticator).

     Would you feel better with the draft if it said "upon receiving an agent
advertisement sent to the MNs unicast address from a foreign agent with which
it has a current binding in which the sequence number is set to 0, the MN
SHOULD attempt to reregister, either with "?  This is the presumed behavior of
all MNs anyway whenever they receive an agent advertisement with sequence
number implying a loss of state from the FA through which they have a binding.

> It is not as expensinve as the MIP Registration.

    I don't see the relevance here.  Added complexity is arguably worse when
the feature is used more rarely and a simpler mechanism is availabl.  I would
argue that this is more expensive than the MIP deregistration (because it
potentially requires the FA to unicast an advertisement after receiving the
equivalent of "deregistration" notice), but I don't see the relevance there,
either.

> for the FA to keep track with too.

    I presume you only mean the 'unconditional' revocations, those where I say
the binding is consider revoked unconditionally, and thereby no reregistration
will be allowed.  In actuallity, remembering this is actually up to the
implementation.  It's true to say more generally that whomever made the
decision to revoke needs to remember, but that doesn't mean it's the FA. 
Perhaps this comes down to just a wording change in the document, making the
idea of "state" clearly implementation specific.  There are two possiblities:

    Revok came from the home subnet.  In this case the FA could remember
because if the MN reregisters, it can either know to just deny the
registration, or it can keep state for the pending registration.  Either way,
there is no risk of the MN getting a binding, because the decision to revok
was not made here.  Defering to the 'authority' which revoked the binding is
perhaps the right thing to do anyway.

    Revok came from the foreign subnet.  In this case the FA got an indication
to "suddenly" revoke this registration either from another authority in its
domain, or it's done this itself (e.g. user-intervention, the MN repeatedly
failed authentication, etc).  In the former case, the FA could remember
because if the MN reregisters it can either deny, or keep state for the
pending registration.  In the later case, note it implies there's already
state in the FA.

    Since it's up to the implementation, would you prefer if I either
specified where these decisions are implementation-specific, or would you
prefer if I lost the notion of 'unconditional' revocation altogether?  Note
that all revocation messages MUST be secured using an HA-FA authenticator, or
equivalent mechanism, so there's "no" (added) risk that someone could get the
FA to continue to deny registrations by pretending to be the HA revoking
unconditionally.

> to 0 or they have the option to discard the message. 

    They should never be discarding these.  They can if they want, but if the
FA has actually lost its state, it *will* be ignoring any encapsulated packets
for the MN.  The MN needs to reclaim its binding if it wants to see any of
them!

                              Cheers,
                                  Steve