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

From: Thomas Narten <[email-masked]>
Date: Tue, 17 Dec 2002 11:26:47 -0500

On the "I" bit. The "I" bit seems to be related to whether the MN gets
informed about a revocation. The document has lots of words about how
it may be policy of (say) the Foreign Domain to NOT notify a MN if its
registration has been revoked. The I bit is used to communicate
between the mobility agents whether one entity will notify the MN, or
whether it won't, or whether it won't say and is leaving it up to
local policy. This is all confusing to me, and seems like a recipe for
lack of robustness.

That is, if either the home domain or the foreign domain stops
providing service to a MN, that MN needs to be notified ASAP. Anything
else just leads to failed communication and black holes. So, I would
have assumed that the desired semantics are that whenever a revocation
takes place, the MN MUST also be notified. But the current words don't
seem to support that at all. Indeed, they talk about local policy
perhaps forbidding such a notification. This seems weird to me. What
is the motivation for this feature and what is it intended to acheive?

My thinkin is that the I bit semantics as specified in the current
document aren't useful, because they can lead to situations where a
mobility agent doesn't really know whether the other mobility agent
will notify the MN of a revocation. I would have assumed that the
reason for having such a bit would be used to make it clear who has
responsibility for notifying the MN, to ensure that the MN was
notified promptly by one of the mobility agents.

What am I not understanding here?

Thomas

---

From: Mike Borella <[email-masked]>
Date: Tue, 17 Dec 2002 12:35:49 -0800 (PST)

> is the motivation for this feature and what is it

If the MN roams to a new FA, the session at the old FA
may still be active for some period of time.  When the
HA detects the new session it can send a MIP
revocation to the old FA.  In this case it makes no
sense to notify the MN be cause the MN is already at a
new FA.

Mike

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: "Steven M. Glass" <[email-masked]>
Date: Tue, 17 Dec 2002 16:55:29 -0500

Thomas,

     I'll tackle the easy one to explain first!

> What am I not understanding here?

     The 'I' bit applies to MN's that are NOT collocated, and are 
registered through a FA for the simple reason that collocated mobile 
nodes can receive revocation messages directly from their HAs, so this 
isn't necessary.  The thought process goes like this.  There are two 
scenarios - HA revoking, FA revoking.  In the former it would be 
possible for the HA to notify the MN before it notifies the FA of the 
revocation.  In the latter, thought, when the FA revokes the binding, 
by the time the HA receives the notification the binding is gone, and 
so there's no way for the HA to notify the MN.  This meant that the 
simplest solution would be to always have the FA notify the MN of these 
revocations, which it does quite easily through the mechanism described 
in the draft.

     In my first version (perhaps even pre -0) I had the mobile node 
always being notified.  However, some comments came in about an 
opportunity to invoke local policy.  The local [e.g. security] policy 
on the foreign domain could simply prohibit notifying a MN that the 
local domain is no longer providing it service.  Moreover, it may be 
the preference on the home domain to not let the MN know either.  Enter 
the 'I' bit.  If there's a policy in place on the Foreign domain, it 
wins, and it should win because the subnet to which the mobile node has 
joined belongs to the foreign domain and it MUST be able to enforce its 
own policies (yes, there are arguments that the home domain should be 
able to protect its property, too (e.g. data), but this is a basic 
connectivity issue, and before the MN can participate in any 
communication with the home domain, the foreign domain has to provide 
it service).**

     As for black-holing, I believe your saying in most other protocols 
when a node isn't being serviced, it knows (e.g. DHCP lease expires, 
IPCP goes down, whatever).  The nature of Mobile IP is a bit different, 
though, because the MN doesn't have service until it's registered.  
Already present in the core mobile IP draft, if an FA stops providing 
service it becomes the black hole to the mobile node, as well as for 
the forward tunnel, and if the HA stops providing service it becomes 
the black hole for the reverse tunnel; a significant part of the 
purpose of this mechanism is an attempt to provide feedback to the 
'other' agent so this doesn't happen [with the noted attention to local 
policies].

                               Cheers,
                                   Steve

     **(That is to say you MUST participate, and conform to layer 2 
policy, before you can participate in layer 3 policies.  [I'm not 
convinced that's extractable to {N, N+1}]).

---

     In case some of the details aren't clear in the draft, here's a 
summary.

     Registration 'I' bit summary.  Note the FA always gets the 
registration request first.  Packet flow:  MN->FA->HA->FA->MN

     case 1:
         There is a policy on the Foreign domain with regards to 
informing the MN (whether it's to inform or not inform the MN of the 
revocation is irrelevant).  In this case the FA doesn't set 'I' bit, 
saying "I don't care what the home domain policy is."

     case 2:
         There's either no policy on the foreign domain, or the policy 
is to do what the home domain would like with regards to informing the 
mobile node.  In this case the FA does set the 'I' bit: "The HA can 
tell me what to do."

         For case 2 there are two possible responses.

         case A:
             HA doesn't set the 'I' bit: "I don't care whether the MN is 
informed or not at revocation time."

         case B:
             HA does set the 'I' bit: "I'll tell you whether to inform 
the MN at revocation time."

     Note that the mechanism allows the decision to inform the mobile 
node to come at revocation time since that's when the policy will need 
to be applied, and in theory it could change between registration time, 
and revocation time.  Sure, the policy on the foreign domain could 
change from "we do what the home domain wants" to "we do what we want", 
but there mechanism is (admittedly) overloaded to handle this at 
revocation time.

     Revocation 'I' bit summary.  This only applies when the 'I' bit was 
negotiated in the registration (above).  Note: this is used in 
conjunction with the 'A' bit.

     Case 1: HA revoking
         Case A: does set the 'I' bit - "Please DO inform the MN"
         Case B: does NOT set the 'I' bit - "Please do NOT inform the MN"

     Case 2: FA revoking
         Case A: does set the 'I' bit - "Use the 'I' bit in the ACK to 
let me know" (see above)
         Case B: does NOT set the 'I' bit - "I'm not giving you the 
choice [any more]"

     Of course, once the registration lifetime expires, the MN will know 
it's without service, and the recommendation has always been to use 
short lifetimes (though 3344 [a.k.a. 2330, a.k.a. 2002 does define 
'infinite' lifetimes).  It does seem like a lot to go through, though I 
think it's better to design this in here rather than try to extend a 
revocation mechanism.

<fin>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 18 Dec 2002 16:36:57 -0500

> revocations, which it does quite easily through the mechanism described 

Makes sense to me so far.

> local domain is no longer providing it service.

I don't understand this at all. It doesn't make sense to me. A foreign
domain is no longer allowing the MN to use its facilities, but has a
policy of not telling it so? The MN will figure this out after a
while, so it's not like its hiding anything... Under what conditions
would it make sense for a policy to say "don't inform?"

So, I still don't understand the motivation for the current wording.

> Moreover, it may be 
> the preference on the home domain to not let the MN know either.

Again, the MN will eventually figure out it isn't getting service
anymore.  So not telling it (from a policy perspective) doesn't make
any sense to me.

Seems to me that whenever the HA or foreign domain discontinue
service, an attempt should make an attempt to notify the HA. This is
just about keeping things more robust (i.e., the MN can then attempt a
recovery). If it doesn't even know, it first has to time out, which
may take a while...

> Enter the 'I' bit.  If there's a policy in place on the Foreign
> domain, it wins, and it should win because the subnet to which the
> mobile node has joined belongs to the foreign domain and it MUST be
> able to enforce its own policies (yes, there are arguments that the
> home domain should be able to protect its property, too (e.g. data),
> but this is a basic connectivity issue, and before the MN can
> participate in any communication with the home domain, the foreign
> domain has to provide it service).**

Note: a foreign domain can always do whatever it wants (e.g, just
revoke service and not tell anyone). But I would hope that to be rare
in practice, and I see no reason for the protocol to have words to
support this, as having such support lends credence to the idea that
this makes sense or is useful. I'm still not convinced of the
latter. 

> IPCP goes down, whatever).

Actually, a basic principle I have is that blackholing is not
desirable in general and should be used as a last resort. For one
thing, distinguishing congestion or temporarary outages from something
more permanent (like revoked bindings) is hard. If you can have
additional (and reasonably) simple message exchanges that provide more
specific info than just blackholing, this provides MNs with more info
to attempt a timely recovery faster.

> The nature of Mobile IP is a bit different, though, because the MN
> doesn't have service until it's registered.  Already present in the
> core mobile IP draft, if an FA stops providing service it becomes
> the black hole to the mobile node, as well as for the forward
> tunnel, and if the HA stops providing service it becomes the black
> hole for the reverse tunnel; a significant part of the purpose of
> this mechanism is an attempt to provide feedback to the 'other'
> agent so this doesn't happen [with the noted attention to local
> policies].

So are you arguing that because MIP already had blackhole behavior  in
some situations, there is no need to try and do better when it is
possible?

Now, Mike Borella indicated that there are cases where it doesn't make
sense to notify the MN (i.e, it has moved and is not at the foreign
domain anymore). But in this case, wouldn't it make more sense for the
default to be that the FA does notify *unless* told by the HA that
there is no point in doing so, so you can skip this part?

Thomas

---

From: "Steven M. Glass" <[email-masked]>
Date: Mon, 23 Dec 2002 14:47:45 -0500

Thomas,

     Sorry for the reply-delay.  Blame it on my day job.  Also, Madhavi 
is away for the holidays, so this is running on my schedule!  (Due to 
my delay, I've included the entire email for context.  Feel free to 
omit whatever you feel is no longer needed for context).

> recovery). If it doesn't even know, it first has to time out, which

    I agree, actually.  I also agree telling the MN makes everything a 
lot more robust.  This functionality was included from some 
comments/requests I'd gotten.  The argument is who knows what sort of 
policy is going to be required for e.g. security/access, 
legal/contractual, etc?  If the local policy is to not inform, that's 
the policy and the agents need to conform to it.  The default can be to 
set the 'I' bit to 1.  I agree the option to not inform only introduces 
a delay, but that delay is seen as being directed at a now unauthorized 
node (think 'telnet' - this is akin to the delay in feedback when a 
user fat-fingers their password at a unix login prompt).

> revoke service and not tell anyone).

     Of course.  Note this is actually the only option without this 
draft.

> to attempt a timely recovery faster.

     I agree with everything you just said.  My decision to include this 
feature in the 'core' revocation draft rather than leave it to e.g. an 
extension to this draft was because I felt if the WG wanted this, I 
didn't want to have yet another extension to mobile ip (there's more 
than enough of those already).

> some situations, there is no need to try and do better when it is

     Of course not.  My point was this is an attempt to do better, and 
does do better if even from just the HA and FA tunnel endpoints.

> there is no point in doing so, so you can skip this part?

     I suppose this is the case where the HA noties an old FA the MN is 
no longer there.  While I agree this makes sense, to continue the 
'always notify the MN' point, is there any gross waste should the FA 
sends the directed-revocation notice to the MN anyway (which is in the 
form of a directed 'reset' advertisement, wasted since the MN is 
theoretically not there)?  This adds robustness, actually, should 
something have gone wrong and the MN happens to still be visiting that 
FA; it now has an opportunity to try to recover.

     If the 'I' bit were taken back out of the draft, then local policy 
on the foreign domain would always dictate what would happen (as you 
say, the FA could simply black hole the MN).  The only thing the 'I' 
bit gives is a way for the Home domain to ask the FA to do the "right" 
thing by it.  If we remove the 'A' bit by making revocation ACKs 
mandatory, we can remove the 'I' bit in the registration extension (not 
knowing if your peer did acks made the inform-functionality uncertain 
at revoke time).  This makes more sense when considering the fact that 
the only policy that really matters is the one at revocation time.  The 
'I' bit at revoke time would then be a lot simpler:

         FA revoking:
             'I' bit set to '0', HA has no options
             'I' bit set to '1', HA's ACK means:
             HA ack:
                 'I' bit set to '0', don't inform the MN
                 'I' bit set to '1', do inform the MN

         HA revoking:
             'I' bit set to '0', FA shouldn't inform the MN *
             'I' bit set to '1', FA should inform the MN
             FA ack:
                 'I' bit set to '0', I didn't inform the MN
                 'I' bit set to '1', I did inform the MN

         * note this case is the "MN no longer at your location"

     Does this make more sense to everyone?

                               Cheers,
                                   Steve

---

From: Mike Borella <[email-masked]>
Date: Mon, 23 Dec 2002 12:40:43 -0800 (PST)

> FA; it now has an opportunity to try to recover.

Whether or not there is wastage depends a lot on the
access technology.  For 802.11, its probably no big
deal.  For CDMA, there will be wastage since the FA
will have to hold the PPP session open for some period
of time.  If the traffic channel is not up and the
PDSN isn't smart enough to silently drop the session,
the MN will be paged and will bring up a traffic
channel.  Service providers will not like this because
it wastes precious airlink resources, and it will hold
the PPP session for at least 1, maybe as many as 10-12
more seconds.  The moral of the story is that the FA
should always make the final decision of whether or
not to notify the MN.  In this sense, the I bit is
most useful for the HA being able to tell the FA that
it definitely doesn't have to bother notifying the MN
(e.g., the HA knows that the MN is now served by a
different FA).

Mike

---

From: "Steven M. Glass" <[email-masked]>
Date: Mon, 23 Dec 2002 16:37:07 -0500

> (e.g., the HA knows that the MN is now served by a

     All true.  The decision then is based on local policy, so 
implementors will have demand to make it configurable.  Sounds like you 
agree with the option at the end of my email.

                               Cheers,
                                   Steve