Subject: RE: [mobile-ip] Risks of not verifying the care-of address <draf t-roe-mobileip-updateauth-01>

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 12 Dec 2001 09:26:20 -0600

Claude,
 
Another approach would be to somehow use the routers close to the MNs to
ensure that the MN is using COA's they are supposed to be using. Ingress
Filtering can restrict such abuses to just the originating subnet being
spoofed. Control Lists would offer more protection against this. I think
this threat is the same threat that ingress filtering was trying to deal
with on non-mobile nodes. 
 
Thanks,
 
Glenn

-----Original Message-----
From: Claude Castelluccia [mailto:[email-masked]]
Sent: Wednesday, December 12, 2001 4:49 AM
To: [email-masked]
Cc: [email-masked]; Erik Nordmark; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [mobile-ip] Risks of not verifying the care-of address
<draft-roe-mobileip-updateauth-01>

Jari Arkko wrote: 

Claude Castelluccia wrote: 

>     The prevention of this attack is another reason why CAM-DH runs BAKE/2

>     at the bottom: the return routability tests ensure that the attackers 
>     can't claim to be from X if they really aren't from there (or on 
>     the path to it). 
> 
> In SUCV, the 4 SUCVp messages are exchanged between the CN and the 
> MN (the CoA). 
> So the MN has to be in the X network (or on the path to it) for the SUCV 
> exchange to succeed... 

Ah yes, but in my attack above X was the prefix of the home network and 
it was assumed to be different from Y, the prefix of the CoA network. 

> The only weakness (i think) is that this exchange might succeed even if 
> the attacker is on the path to X but 
> return routability does not solve this problem. In fact what prevents, 
> in this case, an attacker to choose 
> a HomeAddress that is also on the path from the CN to X??? 
> 
> I think that return routability might only be useful against an attacker 
> trying to redirect a "legitimate" HomeAddress... 
> but SUCV/CAM also solves this issue... 

Here's the attack: 

1. Invent a new SUCV-address (you can do it) of the form X:<HoA> 

2. Go to network Y and get an address Y:<CoA> 

3. Run SUCV against any CN. This will succeed, because the 
    attacker generated the address by himself. 
4. Start some session with the CN, using Route Optimization 
5. Send a BU to the CN with lifetime 0. This will kill the BCE. 
6. CN continues to send a number of packets towards X:<HoA> 
    on the open session (e.g. RTP videostream). 
7. The packets arrive at network X, and do not hit any 
    specific node because in step 1 we obviously can't 
    pick any existing address. However, the network will 
    be full of packets, and X's Internet pipe may be full. 

This attack has a relatively high amplification factor.

Ok that should work but 
steps 1, 2 and 3 is SUCV...5,6,7 is IPSec.... 
IPSec (i.e. BU authentication part) seems to be the problem here ;-) 

but anyway you can do much better than that ;-) 
Most of the proposed schemes, except BU3WAY, (correct me if i am wrong) 
propose a solution to establish a SA between the MN and the CN...then 
BU are securized using the generated SKEY.... 

So what someone could do is: 
1- establish a SA with a CN using SUCV/CAM, Bake.... 
2- Start some session with the CN using route optimization 
3- register X  (the network or host target) as your CoA... 
..packets will be sent to X!! 

I believe that most of the schemes will fail against this attack...(note
that in SUCV you won't 
be able to attack a host address but a network). 

If we really want to solve these problems, the requirements are then: 
1- How to avoid the initial messages to go through the HA before the MN is
authenticated 
to avoid "3rd party reflection" (that was the start of this thread)? 
2- How to avoid someone generating a fake Home Address and redirect msg to
it (this is the 
attack you've described)? 
3- How to avoid someone registering someone'else address as CoA (this is the
attack that i've 
described above).... 
4-+ the initial requirements (i.e. How to avoid MiTM + how to avoid HoA
redirection....) 

One solution would be: 
1- establish the SA between the MN and CN using something like SUCV (i.e.
without going through 
the HA). 
2 - secure BU using a protocol combining  BU3WAY and the previously
establish SA. For example, 
we could have the following mesg exchange each time the MN moves: 
  a- MN-> CN : BUR authenticated with SKEY 
  b- CN-> HA: BUC authenticated with SKEY 
  c- HA->MN: BUC authenticated with SKEY 
  d- MN->CN:  BU authenticated  with SKEY.. 

Comments? 
thanks. 

Claude. 

-- 

----------------------------------------

Claude CASTELLUCCIA, INRIA Rhone-Alpes  

ph:  +33 4.76.61.52.15 (fax: 52.52)

http://www.inrialpes.fr/planete/ <http://www.inrialpes.fr/planete/>