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

From: "Ahmad Muhanna"<[email-masked]>
Date: Fri, 12 Apr 2002 17:48:23 -0500

Hello Steve;
Thanks a lot.

Could you please see my comments inline.

Thanks;
Ahmad

> 
> 
> > Thanks for your reply.
> 
>     Not a problem!  (I hope you don't mind, but I've 
> forwarded a copy of this
> to the list mainly for archival reasons, but also to answer 
> the more general
> audience).
> 

No problem at all.

> 
> > I have been thinking about Registration Revocation for 
> sometimes, now. 
> > I like your approach, BUT I have been asking myself the 
> following question:
> > 
> > Why we do not think of something more secure and End-to-End 
> between the HA
> > and the MN.
> 
>     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.

>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.

>If the Home domain revoked 
> the registration,
> the home agent will respond that it is denying the 
> registration with some
> error code, e.g. administratively prohibited, and that IS 
> secure end2end with
> the HA-MN authenticator.  The other thing to consider is if 
> the FA revoked the
> registration, it may reply with an error [on the attempt to 
> re-register], or
> it may simply not repond if that's the policy in the foriegn domain.
> 
>     The key thing here is the relationship between home and 
> foreign policies,
> and we shouldn't design a revocation mechanism that shifts 
> the balance between
> the two.  As we get deeper in detail, local policies can be 
> enforced to
> 'squeeze' the correct thing out of the other domain.  E.g. if 
> the MN wants to
> get revocation notifications directly, it should attempt to 
> colocate, and will
> get revocation messages with the HA-MN authenticator.  If, 
> however, the
> foreign domain wants get these messages, it can set the 'R' 
> bit to suggest the
> MN register through it (though enforcing it is a topological 
> consideration
> beyond the scope of mobile ip, but simply preventing the MN 
> from getting a
> topologically correct IPsrc address for the foreign subnet is 
> sufficient).
> 
>                               Cheers,
>                                   Steve
> 
>

---

From: "Steven M. Glass" <[email-masked]>
Date: Fri, 12 Apr 2002 19:47:10 -0400 (EDT)

> Well, does this mean that MN can not receive a MIP RRQ message or any kind

    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).

> in case of rebooting the FA, to inform the MN that its registration is

    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