Subject: [mobile-ip] Registration revocation issues

From: Steven Glass - Solaris Software <[email-masked]>
Date: Wed, 11 Jul 2001 19:21:29 -0400 (EDT)

I'm just about done updating the revocation draft, and I have a few 
questions to ask the group:
    
    1) How do people feel about an "I understand revocations" registration 
extension?
    
    It would be a skippable type (if not understood), and would be added to 
either a registration request by the FA, or to a registration reply by the HA, 
to tell the mipagent-peer it understands revocation messages (for future 
reference).  
    
    The idea here is to know when a mipagent can send a revocation message to 
its mipagent-peer.  The good thing is with this knowledge it potentially cuts 
down processing time/bandwidth utilization, etc.  The problem I see with it is 
(e.g.) if I'm an HA, even if I don't receive this extension, if I'm revoking the 
MN's binding I may as well send a revocation message to the FA anyway, and ditto 
if I'm an FA.  Since these messages are likely to get sent regardless, why do we 
need it?  If the working group wants this, there's an extention to the argument 
(which I'm not saying I agree with) that we may as well use the [last] bit in 
the becon to advertise revocation support (thereby allowing the MN to chose the 
FA which supports revocation from others which do not), then include another bit 
in the registration request itself (to indicate the FA I'm registering with 
supports revocations) without adding the overhead of the extension.  My thoughts 
are if enough people want it, it'll be supported as 'core' mobile-ip, and along 
with the fact that revocation is basically just "FYI: I've revoked my side of 
the tunnel", adding an extension may be more overhead than we get functionality.
    
    2) I'm removing the lifetime field. 
    
    It can cause confusion - e.g. if a MN has 1 hour left on it's binding, and 
is then revoked for 20 minutes, does it's binding get 'resurected' after 20 
minutes (for 40 more minutes).  If no, why bother with it, and if yes, how do 
you keep the MN "happy" in the mean time, and notify it when it's binding is 
back?  Seems better just to remove it, but ->  since people like the idea of 
conditional and unconditional revocation, in it's place I'm putting a 'P' bit 
for "permanent" meaning "this binding is permanently revoked."   When not set, 
the binding can be renegotiated, and when it is set, the implication is the 
mipagent peer will not allow the binding to be renegotiated.  Any discenting 
oppinions from those who like a revocation lifetime better?
    
                              Cheers,
                                  Steve

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 11 Jul 2001 16:26:01 -0700

>     1) How do people feel about an "I understand revocations" registration 

I prefer this than simply assuming it does.

> the tunnel", adding an extension may be more overhead than we get functionality.

The way I see it, I see no reason to send a new message type to an FA that
may not recognize it. Chances are that an implementation will simply drop the
message, causing the HA to retransmit, and eventually give up.

If an FA advertises itself as supporting this extension, then you know that
lack of response means that FA is really not reachable.

Further, revocations MUST NOT be sent upon a binding expiration, right? It's
only sent if a binding is revoked prior to lifetime expiration.

> oppinions from those who like a revocation lifetime better?

lifetimes are out, IMHO. A revocation means the session is terminated. If the
MN wants to renew service, it can send a new registration request.

PatC