Subject: RE: [mobile-ip] alt-coa - Comments on Draft 16

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 5 Apr 2002 15:23:05 +0200

> "Hesham Soliman (ERA)" wrote:
  > 
  > >   > [Rajeev:] I don't believe that with FMIPv6, there are
  > >   > additional assumptions in this sense. The issue is
  > >   > whether old AR has forwarded packets to/from CoA-1.
  > >   > The question of whether that MN is "real" or bogus is
  > >   > a separate identity proving issue.
  > >
  > > => But this identity proving is needed to authorise
  > > the F-BU right?
  > 
  > Not really! With a CN, a MN does not prove its
  > identity. It only convinces the CN that it owns the CoA
  > and HoA using the common trust on routing infrastructure.
  > Thus, to authorize a BU, you don't need to prove the MN's
  > identity; it suffices to prove that the MN legitimately (in the
  > routing sense) owns the addresses in question.

=> Of course. The relevant identity here is the 
MN's address(es). 

  > 
  > BTW, this crucial point is also the basis of short-lived BSAs
  > using RR. A CN does not need to authenticate _who_ owns the
  > addresses as long as it can be sufficiently sure that it is dealing
  > with the same entity it did previously.

=> Yes, so the same question, how does the MN 
prove this to the oAR?

  > This draft has undergone revisions :-) In version-4,
  > 
  > - HI/HAck must be mandatory
  > "..At the same time the oAR MUST send the HI message to the nAR, .."
  > "..The nAR then MUST respond with a HACK, indicating .."
  > 
  > - AR-2 must ensure that CoA-2 is unique.
  > "Upon receipt of the HI message, the nAR MUST first 
  > establish whether
  >    the nCoA is a valid address on its subnet, performing checks to
  >    ensure that it is not a duplicate. If the nCoA is legal and
  >    acceptable to the nAR, the nAR MUST add the nCoA to the Neighbor
  >    Cache for a short time period so it can defend it"
  > 
  > - AR-2 maintains proxy ND cache until the MN
  >     declares its presence on AR-2 (using NA).  Text in
  >     above bullet can be made more specific to say proxy ND cache.

=> So I wonder what 6.1.1 is doing in the draft?
Also if AR-2 is doing these checks (MUST), then
is there a generic way that it can use to do that
without extending the handover time?
I mean without DAD. I know there is lots of handwaving
about this, but I always thought that if we mandate
something for all nodes in a transaction, we have
to show at least one way of achieving this.

  > >   > [Rajeev:] This is not possible with FMIPv6. Packets only
  > >   > goto new AR's proxy ND cache. Besides, once FBU is sent,
  > >   > old AR does not forward packets to MN. I described this in
  > >   > some detail to Erik's message..
  > >
  > > => So you're essentially saying that HI/Hack are always
  > > mandated? If so then we would have to mandate what
  > > the nAR should do (proxy NS ..etc) when it receives
  > 
  > > HI. There is also the chance that the MN might already
  > > move before the nAR sends an NS to verify the nCoA,
  > > and the MN might reply to that.
  > >
  > 
  > The last point is good. The MN would send an F-NA if it has
  > not received an F-BAck, without receiving which, the MN
  > must not assume that it already has CoA-2. So, it must not
  > respond to NS from AR-2.
  > The latest version of the draft should have this information.
  > I also did some analysis of scenarios last year
  > (cf. posting dated Mar 13, 2001). You might want to have
  > a look at both.
  > 
  > In any case, I agree that the draft needs a lot of editing, in
  > addition to clearly spelling out security considerations in
  > binding CoA-1 to CoA-2. Seems like I will have my hands
  > full :-)

=> Yep!

Hesham

  > Regards,
  > -Rajeev
  > > Hesham

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 05 Apr 2002 08:47:51 -0800

Hello Hesham,

> => Yes, so the same question, how does the MN

The same way RR does. AR-1 has received/sent packets
from/to CoA-1. In fact, the association is even stronger here;
AR-1 is the router for packets to/from CoA-1.

> to show at least one way of achieving this.

I have to take a look at 6.1.1.. Regarding DAD, I am
open for suggestions.

Regards,

-Rajeev