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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 3 Apr 2002 16:02:12 +0200

> > => I think that it ultimately comes down to the
  > > basis of the trust between the MN and the 
  > > old AR. Authenticating HI and HAck between
  > > the old and new ARs does not necessarily mean
  > > that the MN is not trying to bomb the new network
  > > does it ?
  > > 
  > > But everyone seems to assume that it is enough
  > > so what am I missing? 
  > 
  > When oldAR lets the MN get service from the domain
  > it is exposing the domain to traffic related to this MN - 
  > e.g. the MN
  > could decide to send or receive useless traffic just to create load.
  > But the domain can limit this "damage" by the link bandwith 
  > the MN is
  > using, and perhaps have ways of allocating cost based on 
  > usage (e.g. usage
  > based billing).

=> That's possible. But so far we've been making very few
assumptions, if any, about the 'supporting' functions
in the network or other components that can give useful
hints. For instance, the link might be a multiaccess
link where it might be a challenge to limit BW
consumption per node. 

  > 
  > The fact that this ability to consume resources can be 
  > transferred between
  > oldAR and newAR doesn't really add a new threat as far as I 
  > can tell -
  > oldAR and newAR trust eachother and there is a way to 
  > prevent others to
  > fake such transfers.

=> 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.

  > 
  > 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.

  > Could a malicious MN use this to pretend to be at more than 
  > 2 CoAs? (oldAR,
  > newAR1, newAR2, etc even though it has never left oldAR?)

=> Yep! In fact, if we take a couple of steps
back and look at the fact that a MN can not do
bombing attacks when a BU is sent e2e to a CN, 
having the AR as a temp HA might open up the 
door for malicious nodes to get around the restrictions
in the basic spec by letting the AR do the 
forwarding instead of the CN and getting away
without the CoA test. 

I admit though, I need to look into this in a lot
more detail, so if I'm on a tangent someone please
let me know :)

Hesham

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 03 Apr 2002 12:16:53 -0800

> link where it might be a challenge to limit BW

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

> makes very little assumption about the operation

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

> => 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..

> more detail, so if I'm on a tangent someone please

[Rajeev:] As I mentioned in my reply to Erik's message,
the reasoning (that packets can only go as far as new AR's
proxy ND cache) holds good for multiple CoAs as well.
In addition, the MN has to first obtain all the prospective
prefixes. Furthermore, proxy ND cache has a lifetime
within which the MN has to attach to _some_ AR and
declare its presence.

Hope this is useful..

Regards,

-Rajeev