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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 4 Apr 2002 16:02:30 +0200

> [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?

  > > => But the transfer is based on some information
  > > received from the MN. So while the 2 ARs trust
  > > each other, the MN might have fooled the first
  > > AR. So unless preventing the MN from fooling
  > > the first AR is within the context of MIP
  > > signalling, the ultimate security level will
  > > depend on the circumstances in each network
  > > and the nature of links ...etc. This is unlike
  > > the security level in the base spec, which
  > > makes very little assumption about the operation
  > > environment.
  > >
  > 
  > [Rajeev:] Even if the MN could fool old AR to
  > believe that it is going to new AR, there is no
  > harm; the bad MN cannot bomb an innocent
  > node on new AR nor can it be fictitiously present
  > on the new link consuming resources. This is because
  > packets sent to CoA-2 goto new AR's proxy ND cache, which
  > is 1 or 2 packets big.

=> Well, I assume you're saying that because of 
the HI/HAck transfer? These messages were introduced
to avoid DAD, however, the draft is very vague about
whether the nAR will actually perform DAD on behalf
of the MN. In fact section 6.1.1 says that if the AR
doesn't then the MN may use the nCoA while performing
DAD. Which essentially means that there is a chance
that another node could already be using this address. 
And it also means that the nAR will not necessarily
wait for anything from the MN before forwarding the
traffic.
Last time we discussed this in the DT (a long time ago)
it was suggested that we don't mandate HI/HAck either
but I haven't read rev -03 (or -04 which is the same
thing) yet, so I don't know if this was made clearer. 

  > >   > Hmm - if the link bandwith at oldAR and newAR is X, can a
  > >   > misbehaving
  > >   > MN use up 2X of resources by pretenting to move to newAR
  > >   > (consuming resources
  > >   > at newAR by bombing) while in fact remaining at oldAR using
  > >   > the resources.
  > >
  > > => That's exactly on of my concern.
  > >
  > 
  > [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. 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 04 Apr 2002 10:32:40 -0800

hi Hesham,

> thing) yet, so I don't know if this was made clearer.

The way I read the drafts, HI/HACK messages are a MUST
since draft -01. The HI message always contains both
the oldCoA and newCoA. If the newAR is not able to 
determine that the newCoA is unique on the new link, 
it sets up a host route for the oldCoA. It also says 
newCoA is invalid in both the HACK (to the oldAR) and 
NAACK (to the MN). The MN can continue using the oldCoA 
on the new link

Vijay

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 04 Apr 2002 11:44:52 -0800

> => But this identity proving is needed to authorise

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.

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.

> thing) yet, so I don't know if this was made clearer.

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.

> 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 :-)

Regards,

-Rajeev