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

"Narayanan, Vidya" <vidyan@qualcomm.com> Tue, 15 August 2006 05:17 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCrJC-0007q2-U2; Tue, 15 Aug 2006 01:17:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCrJC-0007px-5T for mipshop@ietf.org; Tue, 15 Aug 2006 01:17:46 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCrJA-00068A-QU for mipshop@ietf.org; Tue, 15 Aug 2006 01:17:46 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7F5HgTI030686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Aug 2006 22:17:42 -0700
Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7F5Hf9E005612; Mon, 14 Aug 2006 22:17:41 -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 22:17:41 -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 22:17:45 -0700
Message-ID: <C24CB51D5AA800449982D9BCB903251311A67B@NAEX13.na.qualcomm.com>
In-Reply-To: <44E10B4F.6060907@azairenet.com>
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/++G3Eux0EwXlSuiRZ2ZbBI+wOQALcZ2Q
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: Vijay Devarapalli <vijay.devarapalli@azairenet.com>, Jari Arkko <jari.arkko@kolumbus.fi>
X-OriginalArrivalTime: 15 Aug 2006 05:17:41.0031 (UTC) FILETIME=[21874370:01C6C02A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: 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

> Vijay Devarapalli wrote: 

> Jari Arkko wrote:
> 
> >> 3. Using MIP6 home subscription to redirect traffic to the 
> victim. Of 
> >> course, the risk here is that of authenticated nodes 
> registering the 
> >> victim's IP address as its CoA.
> 
> > 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 could add a return routability check for the home agent to 
> check if the mobile node is at the CoA it is claiming in the 
> BU. but AFAIK, it has not been seen as an issue so far.
> 

I don't think adding a RR test for the CoA for home registration is a
good thing - this has to be repeated every time the CoA changes. Also,
I'm not saying this is needed. However, I am saying that there is
equivalence in home and CN registrations when CGA is used to create the
HoA and hence the RR test for CoA is NOT needed for the CN registrations
:) 

If this is seen as a huge problem, then it must be addressed for home
and CN registerations alike. I think that, for now, we can note the
issue and stop at that. 

> regarding the "administrative security association 
> relationship", things are no longer so rigid (RFC 3775 ties 
> an SA to the home address) with the bootstrapping specs. the 
> mobile node can be assigned any random home agent as long as 
> there is a way to authenticate each other.
> 

Agreed. 

Vidya

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