Subject: RE: [mobile-ip] AD question on the "I" bit in draft-ietf-mobileip -reg-revok-04.txt

From: "Kuntal Chowdhury" <[email-masked]>
Date: Fri, 3 Jan 2003 10:40:38 -0600

Steven M. Glass wrote:
> 
>      I guess we're going to have to hash this out...
> 
> 
> > I think having a code field in the revocation message will 
> help to let 
> > the mobility agents convey/know why the I-bit was set to 0.
> 
>      Do you mean if the FA revokes, the HA revokes, or for both (I'm 
> presuming you feel such a field would be useful for both)?  
> Looking at 

Yes, I mean both FA and HA may set these codes. Of course not all the 
codes will be set by both the agents.

> the scenarios:
> 
> 
> > The code filed can be 1 octet long:
> >
> > Code                    Reason
> > 1                       Local policy prohibits notification
> 
>      This is one that's probably useful for both sides (note, though, 
> this may already have been found out via the SA the agents share, but 
> certainly could be found out through AAA - yes, if it's 
> revealable, but 
> if it isn't this code is not useful to the sender, so we have to add 
> "code 255 - reason unrevealed" which is clearly useless).
> 

Since you brought up the point with AAA, I think, it is possible with
DIAMETER, but not sure how it works for RADIUS. In certain scenarios
the FA and the HA are not required to authenticate and authorize users
with RADIUS servers. Also, I don't think this code (about local policy)
should be part of accounting messages either. This code can be part of 
the Revocation Support Extension (I-bit in this extension).
We need to clarify that when a mobility agent sets I=0 in the Revocation 
Support Extension, it means that the mobility agent shall not notify the
MN due to local policy.

> 
> > 2                       Link already disconnected.
> 
>      This would be a code only the FA would be sending.  Why 
> does the HA 
> care that the FA's freed a link?
> 

Yes, this code will be used by the FA to convey the reason (why it cannot 
notify the MN) to the HA.

> 
> > 3                       MN did not respond.
> 
>      Respond to what?  How exactly should the MN respond?  How is it 
> even involved in revocation?
> 

When an MN's MIP session is being revoked, it is possible that the MN is 
in a dormant state (i.e. no active traffic channel over the air/ sleep 
mode). Now, to notify the MN, the FA/Access network needs to initiate a
paging process. If the MN in the dormant state moved into an RF fade
zone, the MN would fail to respond to page from the access network. The
access network and the FA will give up trying to notify the MN after a
configurable number of retries. This is what I mean by "MN did not respond".
We can say "MN did not respond to page" if that helps clarify the scenario.

> 
> > 4                       MN's movement detected.
> 
>      This is a code only the HA would be sending.  Does it 
> matter to the 
> FA that the MN moved, or just went away?
> 

This is important. It matters to the FA to know that the MN for which
it has a mobility binding has moved out of it's area. To me the language
is not that important i.e. movement detected -> went away, if you like.
The important point is, after receiving this code, the FA shall clear the
MN's mobility binding without trying to notify the MN.

>      I don't see why any of these matter to the agent receiving the 
> code.  I agree it may be good for accounting reasons, but it's better 
> to convey that through AAA.  

I think, these codes makes sense to HA and FA. If some implementation
wants to add these reason codes in Accounting messages for information
purpose,
then it is alright as well. Note that, in most of the mobile IP deployments
the accounting is done at the FA. Therefore if we rely solely on accounting
messages, the reason codes known to HA only (such as movement detected) will
not be captured. By exchanging the reason codes both the agents will know
the reason code for MN notification, therefore either of them can insert the

info into accounting record (if HA does accounting in future).

Note that the *revoking* agent is likely 
> to be the one updating its AAA server, which will then be 
> informing the 
> other domain's AAA server.  Telling the agent seems unnecessary.

Not true. If the revoking agent is HA, it is not bound to inform the AAA
server. In most of the MIP deployments, the HA does not do accounting.
>                                 Cheers,
>                                     Steve