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
- [Mipshop] Review of draft-arkko-mipshop-cga-cba-04 Narayanan, Vidya
- Re: [Mipshop] Review of draft-arkko-mipshop-cga-c… Wassim Haddad
- RE: [Mipshop] Review of draft-arkko-mipshop-cga-c… Narayanan, Vidya
- [Mipshop] Review of draft-arkko-mipshop-cga-cba-04 Lakshminath Dondeti
- RE: [Mipshop] Review of draft-arkko-mipshop-cga-c… Narayanan, Vidya
- Re: [Mipshop] Review of draft-arkko-mipshop-cga-c… Christian Vogt
- Re: [Mipshop] Review of draft-arkko-mipshop-cga-c… Christian Vogt
- Flooding Attacks and MIP6 (was RE: [Mipshop] Revi… Narayanan, Vidya
- CGA-based HoA generation for MIP6 (was RE: [Mipsh… Narayanan, Vidya
- Re: Flooding Attacks and MIP6 (was RE: [Mipshop] … Jari Arkko
- RE: CGA-based HoA generation for MIP6 (was RE: [M… Narayanan, Vidya
- RE: Flooding Attacks and MIP6 (was RE: [Mipshop] … Narayanan, Vidya
- Re: CGA-based HoA generation for MIP6 (was RE: [M… Jari Arkko
- Re: Flooding Attacks and MIP6 (was RE: [Mipshop] … Vijay Devarapalli
- RE: Flooding Attacks and MIP6 (was RE: [Mipshop] … Narayanan, Vidya
- Re: Flooding Attacks and MIP6 (was RE: [Mipshop] … Christian Vogt
- Re: Flooding Attacks and MIP6 (was RE: [Mipshop] … Christian Vogt
- Re: CGA-based HoA generation for MIP6 (was RE: [M… Christian Vogt
- Re: CGA-based HoA generation for MIP6 (was RE: [M… Jari Arkko
- Re: CGA-based HoA generation for MIP6 (was RE: [M… Lakshminath Dondeti
- RE: CGA-based HoA generation for MIP6 (was RE: [M… Narayanan, Vidya
- RE: CGA-based HoA generation for MIP6 (was RE: [M… Wassim Haddad
- Re: CGA-based HoA generation for MIP6 (was RE: [M… Christian Vogt
- Re: CGA-based HoA generation for MIP6 (was RE: [M… Lakshminath Dondeti
- Re: Flooding Attacks and MIP6 (was RE: [Mipshop] … Jari Arkko
- Re: CGA-based HoA generation for MIP6 (was RE: [M… Christian Vogt
- Re: CGA-based HoA generation for MIP6 (was RE: [M… Christian Vogt
- Re: CGA-based HoA generation for MIP6 (was RE: [M… Vijay Devarapalli
- RE: Flooding Attacks and MIP6 (was RE: [Mipshop] … Narayanan, Vidya
- RE: Flooding Attacks and MIP6 (was RE: [Mipshop] … Christian Vogt
- RE: Flooding Attacks and MIP6 (was RE: [Mipshop] … Narayanan, Vidya