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

"Narayanan, Vidya" <vidyan@qualcomm.com> Mon, 14 August 2006 21:39 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCk9T-0003a3-3c; Mon, 14 Aug 2006 17:39:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCk9R-0003Zy-VR for mipshop@ietf.org; Mon, 14 Aug 2006 17:39:13 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCk9P-0004Oy-HL for mipshop@ietf.org; Mon, 14 Aug 2006 17:39:13 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7ELd9ei022138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Aug 2006 14:39:10 -0700
Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7ELcwlu011561; Mon, 14 Aug 2006 14:39:09 -0700 (PDT)
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 14:39:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Flooding Attacks and MIP6 (was RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04)
Date: Mon, 14 Aug 2006 14:38:55 -0700
Message-ID: <C24CB51D5AA800449982D9BCB903251311A61D@NAEX13.na.qualcomm.com>
In-Reply-To: <44E0D802.5090307@kolumbus.fi>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Flooding Attacks and MIP6 (was RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04)
Thread-Index: Aca/3/jzVB3roC9dRQGS+QTDsHtJCgAA3+SA
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: Jari Arkko <jari.arkko@kolumbus.fi>
X-OriginalArrivalTime: 14 Aug 2006 21:39:09.0072 (UTC) FILETIME=[131F7900:01C6BFEA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: Christian Vogt <chvogt@tm.uka.de>, Wassim Haddad <whaddad@tcs.hut.fi>, mipshop@ietf.org
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mipshop.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Errors-To: mipshop-bounces@ietf.org

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@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop