Subject: RE: [mobile-ip] some comments on the FMIP draft

From: "Muhammad Jaseemuddin" <[email-masked]>
Date: Fri, 4 May 2001 10:39:29 -0400

> -----Original Message-----
> From:	Hesham Soliman (ERA) [SMTP:[email-masked]]
> Sent:	Thursday, May 03, 2001 9:04 PM
> To:	[email-masked]'
> Subject:	RE: [mobile-ip] some comments on the FMIP draft
> 
> > 3) As I've said before, it would be nice to decouple 
> >    the need to do the HI/HACK from the rest of this
> >    draft. The mobile node should be able to just 
> >    ask the old access router to buffer its packets
> >    while it's in transition. In fact, this has the
> >    positive side effect if the oldAR doesn't know
> >    anything about the newAR, 
> > 
> 	=> I agree with you. But when we discussed the 
> 	alternative (MN performs DAD in parallel with 
> 	sending and receiving packets) we found that 
> 	it may not work in all cases. Also there were 
> 	some open issues with ND. I would prefer 
> 	that approach (my technical bias) if it 
> 	can work. So if you think it can work when
> 	considering it in detail, I don't see why not.
> 
> > the mobile node can
> >    still register on the newAR 
> > 
> 	=> What do you mean by the "MN
> 	registers with the new AR" ?
> 	This is not MIPv6. This is a MIPv4 
> 	scenario.
> 
> > as if it were just
> >    booting up, and when it's ready, send the BU
> >    to the oldAR to start flowing the buffered 
> >    packets. Another benefit is that if, for some
> >    reason, the MN can't attach to the ARnew, it
> >    can abandon the handoff and still get the 
> >    buffers from ARold (assuming it is still 
> >    in range, but if not you're really hosed
> >    anyway).
> > 
> 	=> Doesn't sound like a real time friendly 
> 	approach though.
> 
	[MJ]  It seems will increase the handover latency. It may be a good
approach if the two ARs belong to two different ADs, but most likely MIPv6
will be used there.

> > 4) I don't think anything prevents the MN from
> >    going through normal DAD procedures on the
> >    new AR. If we eliminate the need for the newAR
> >    to do the buffering, we can make the HI/HACK
> >    completely optional.
> > 
> 	=> See above.
> 
> > 5) Is the FBU/FBACK really a different kind of BU?
> >    It looks the same as a normal BU. That would 
> >    actually be rather nice if it were the same
> >    since we're probably need to consider the
> >    security aspects of them, and it would be nice
> >    to have exactly one kind of BU to modify if
> >    necessary. Same goes for HMIP as well.
> > 
> 	=> It would be the same from a security 
> 	poin of view. I don't see why not. Same 
> 	for HMIPv6. The F-BU will include the 
> 	M flag to ensire coexistence with HMIPv6.
> 
> 	The reason for having a different type is 
> 	the HI/HACK messages. We need to know 
> 	if the BU should trigger HI/HACK or not.
> 
	[MJ]  Hesham, this point is not clear. I don't think that as the
draft stands today there is no scenario described where Bu is triggering
HI/HACK? or may be I have missed some subtle issues. I will appreciate your
response.

	Don't you think that F-BU may not have the same security requirement
as BU if it is used within LMM? I think we should review Fast Handover draft
in light of new LMM understanding and requirements.

> 	Hesham
	- Muhamma Jaseemuddin

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 7 May 2001 00:08:21 +0200

>    Can you outline some of the problems?
> 
	=> This is going back a long way now, but 
	from memory ND mandates that the O flag 
	is sent in Neighbour advertisements. If there 
	is a collision in addresses the MN will 
	overwrite someone else's entry in the 
	Neighbour Cache (unless you use security). 
	Of course back then we hadn't discussed 
	creating a new type for the NA. But maybe that 
	would solve it. 
	Some people in the team also wanted to avoid 
	ND when the MN first moves. So they wanted 
	the nAR to have all the MN's info and that
	was one of the main reasons for HI/HAck.

	I am one of the people who has always wanted
	it to be optional or removed and proposed doing DAD in 
	parallel. I don't know what others in the WG think.

>    No, of course not. I view this in %*! happens sense,
>    as in if the MN tries to move to some place it finds
>    out was a mistake. If the packets were buffered back
>    at ARold, it could potentially minimize some of its
>    loss. Not a huge benefit, I'll agree, but it sort of
>    plays off of the old "bird in the hand is worth two in
>    bush" principal :-)
> 
	=> Sure. I don't think buffering will solve the problem
	but if we have to do it then it should be done 
	in the old AR. Currently the draft doesn't support 
	the MN to request buffering.

>    Could this not be done with a flag in the RS?
>    As far as I can tell, what I'm proposing would
>    require the following flags:
> 
> Router Solicit (and RA, I suspect):
> 
> BUFFER: buffer the packets until you see a Binding Update
> HANDOVER: execute the HI/HACK
> 
> BU: nothing special since it executes once the MN arrives
> BACK: nothing special since it's just a BU
> F-NA: deprecate since it's not necessary
> 
> Two new flags in the RS and RA seems a lot cleaner in
> my mind than 3 new messages.
> 
	=> Yup. That is if buffering should be supported at all.

	Hesham

---

From: Alper Yegin <[email-masked]>
Date: Mon, 7 May 2001 19:58:49 -0700 (PDT)

...

> Also: one other thing that folks are missing in
> the current draft is that the arrival of MN on AR
> and then sending the F-NA is a security hazard
> unless MN can cryptographically prove that it is
> the same node on on ARold that is pressing the
> "go" button. There would need to be some sort of
> identity that is transfered in the HI/HACK and
> a new security association at ARnew in order to
> prevent this attack.

But at that level (bad guy on the link) network is already vulnerable to other
kind of attacks. For example even after handoff is over, bad guy can overwrite 
the neighbor cache on newAR and steal rest of the traffic.

Maybe secure ND is the solution.

alper

> 
> If you let ARold buffer the packets, you don't run
> into this hazard (and time sink) because ARold
> could have demanded credentials well in advance to
> determine the legitimacy of the BU.
> 
> 	      Mike
> 
> James Kempf writes:
>  > One of the problems with requiring signalling from the MN after L2 has 
indicated 
>  > handoff is imminent is that, depending on the particulars of the radio link 
>  > protocol, the signalling has a much higher probability of being dropped or 
>  > corrupted. The reason that handoff typically occurs is because there
>  > is a drop in the radio signal quality or power below what the radio 
protocol
>  > deems sufficient for low error rate communication having the contracted
>  > quality of service from the mobile node to the current base station. 
>  > We went through this discussion once several months ago on the IPv4 design 
team. 
>  > I don't know whether it surfaced in the IPv6 discussion at all. 
>  > 
>  > Because this may not necessarily be the case for all radio protocols (for
>  > example, a nanocell protocol), the IPv4 design team decided to offer
>  > the choice of either having the L3 handoff signalling
>  > originate from the mobile node or having the network do the L3 handoff
>  > signalling. The IPv6 design team chose to combine the two techniques and 
require
>  > both in all cases. IMHO, the need for low latency handoff is poorly
>  > served by this design, because it requires more signalling than if
>  > the two techniques were separated, but I won't try to second guess
>  > the IPv6 design team without more carefully reading the draft.
>  > 
>  > In any case, I don't think it would be wise to eliminate the network 
assisted 
>  > part of the handoff. This would assure that the protocol would work
>  > poorly for radio protocols where degraded radio quality of service 
>  > accompanies an L2 handoff decision, because the MN would be forced
>  > to retransmit if packet loss occured.
>  > 
>  > 		jak
>  > 
>  > 
>  > 
>  > 

alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 8 May 2001 21:46:19 -0700 (PDT)

> Alper Yegin writes:
>  > Regular BU changes the routing as soon as it's received. But F-BU cannot 
change 
>  > routing by itself. The receiving newAR also needs to wait for a successful 
HACK. 
>  > And on top of this, if the L2 supports, newAR might even wait for "MN 
detached" 
>  > signal from its L2 to start tunneling packets to newCoA.
> 
>    I thought the scenario was:
> 
>    MN          ARold        ARnew
> 
>    RS------------>
>                   HI---------->
>                   <--------HACK 
>    <------------RA
>    BU------------>
>    <--------BU_ACK
> 
>    Ie, MN knows everything it needs to know once
>    it gets the RA and ARnew is ready.

Check out the figure in 3.1.1. HACK may arrive after BU arrives at newAR.

> 
>  > Therefore F-BU is really different than BU.
> 
>    Even with the above said, I don't see why this
>    requires that F-BU be a different BU
>    though. Why couldn't there just be a flag in
>    the BU which explicitly controls this behavior?

I remember discussing this, but can't remember why we chose a new type. Maybe 
other members of the design team can comment on this.

alper

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 9 May 2001 04:54:43 -0400

Mike,

-As I said I have lost a number of e-mails so apologies if this is already
out of context-

The scenario you describe is only one of the possible ones...Here is another
one...

   MN          ARold        ARnew

   RS------------>
   <------------RA
                HI---------->
   BU------------>
                 <--------HACK 
   <--------BU_ACK

The oldAR can send the RA to the MN before it receives the HACK (which saves
a bit of time...). The MN will send the F-BU immediately and the possibly
move...The oldAR in this case SHOULD NOT change routing before it receives
the HACK (which will validate the forwarding address for the MN...)

We also discussed at length the issue of how to identify the F-BU (I had to
check the archive for this...)...We actually examined weather a normal BU
can be identified as F-BU from what state the oldAR has on the source...(has
it sent a PrRtAdv to it or not...etc) but we realized that that was not
enough and we decided to go for a flag. Then there was some concern about
using up valuable BU Flags (there are only a few left) when we have a big
code space available to us and that I think was the reason of a new
type...F-BU...

George

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Tuesday, May 08, 2001 10:48 AM
To: [email-masked]
Subject: RE: [mobile-ip] some comments on the FMIP draft

change 
 > routing by itself. The receiving newAR also needs to wait for a
successful HACK. 
detached" 

   MN          ARold        ARnew

   RS------------>
                  HI---------->
                  <--------HACK 
   <------------RA
   BU------------>
   <--------BU_ACK

	  Mike