RE: Flooding Attacks and MIP6 (was RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04)

["Narayanan, Vidya" <vidyan at qualcomm.com>]

Hi Jari,

<snip>

> >  
> >
> Yes -- but I believe for TCP this is hard, because it would 
> imply being able to guess the sequence numbers. Otherwise the 
> session won't even start. There are ways to guess the 
> sequence numbers, but at least some of those ways involve 
> additional cost for the attacker.
> 

I'd somewhat buy that :) I think spoofing the acks can be done, but it
does involve some cost. 

<snip>

> >
> That is the crux of the matter. Whatever arrangement exists 
> between the MN and its HA is invisible to the CN (under the 
> assumption of talking to a random Internet host). What the CN 
> sees with a home test is that the MN appears to be in control 
> of receiving traffic at the home address. This is sufficient 
> for agreeing to route traffic relating to that address 
> differently, but it does not say anything about the existence 
> of the node at the care of address.
> 
> Of course, if there's a problem, the CN can go and complain 
> to the home network's admin. The admin may be able to find 
> out the offending node and turn it off. But the victim 
> network admin needs to talk to both the CN network and then 
> indirectly the home network to get this started; during the 
> design of the original RR mechanisms it was felt that its 
> better to provide a mechanism that helps prevent these 
> situations -- even if the network admin and authorities could 
> sort out the situation later.
> 

I don't quite agree that the above situation is any different for home
registration vs. RO. Here's why - in both cases, let's assume that the
victim is some random node in the internet that does not have any
relationship with the home domain of the MN (attacker). In both cases,
the packets arriving at the victim has the CN IP address, the HoA and
the CoA (the victim's IP address, in this case) available to it. The
victim additionally has the HA IP address available to it in the HA
routed case. However, considering that the victim is a random node with
no relationship to the home domain, it needs to deduce the home domain
from the IP addresses and then complain. It can do this in both cases.
In both cases, deniability is also equally possible, since the home
domain could claim that the attacker is the CN in both cases. 

Given that a "complaint" has to take the form of an email or a phone
call or something tangible, this is equally feasible (or not, actually,
in my mind!) in both cases. The added availability of the HA IP address
really doesn't mean anything as far as I can see. 


<snip>

> >  
> >
> Let me first state that if I could redesign RFC 3775 today, I 
> would probably NOT include an administrative security 
> association relationship for the MN - HA. This would have 
> made deployment much easier (e.g. DHCP assigned home agents 
> without any of the bootstrapping complexity).
> And it would have gotten us rid of problem #3.
> 
> We have occasionally talked about this change, though not 
> very seriously -- and I would not hold it as a precondition 
> for doing RO enhancements. In any case, in the current 
> deployment model of Mobile IPv6 there is an administrative 
> relationship which can be used to shut down misbehaving nodes 
> or even send the authorities to catch the guilty. I still 
> like to have a stronger flooding amplification protection for 
> the MN - CN relationship -- particularly if it does not have 
> a cost in communications latency.
> 

The whole admin thing being some level of protection here is quite
bizzarre to me :) - but, even if I made the leap to embrace that, I
still feel there is equivalence as I've described above. What am I
missing? 

Vidya

_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop