RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04
"Narayanan, Vidya" <vidyan@qualcomm.com> Tue, 08 August 2006 00:31 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAFVS-0002Fj-LF; Mon, 07 Aug 2006 20:31:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAFVR-0002B0-3Z for mipshop@ietf.org; Mon, 07 Aug 2006 20:31:37 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAEMu-0004FT-K5 for mipshop@ietf.org; Mon, 07 Aug 2006 19:18:44 -0400
Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAE9T-0006rd-Rf for mipshop@ietf.org; Mon, 07 Aug 2006 19:04:59 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k77N4m56007666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <mipshop@ietf.org>; Mon, 7 Aug 2006 16:04:48 -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 k77N4lZJ009282 for <mipshop@ietf.org>; Mon, 7 Aug 2006 16:04:47 -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, 7 Aug 2006 16:04:47 -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: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04
Date: Mon, 07 Aug 2006 16:04:51 -0700
Message-ID: <C24CB51D5AA800449982D9BCB90325130A1FA9@NAEX13.na.qualcomm.com>
In-Reply-To: <C24CB51D5AA800449982D9BCB90325130A1F93@NAEX13.na.qualcomm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04
Thread-Index: Aca6aZgTCUklQawUS12bJgwD1f9MJAAC+R6w
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: mipshop@ietf.org
X-OriginalArrivalTime: 07 Aug 2006 23:04:47.0500 (UTC) FILETIME=[E0F91CC0:01C6BA75]
X-Spam-Score: -2.4 (--)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
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
A minor correction inline below. > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Monday, August 07, 2006 2:37 PM > To: mipshop@ietf.org > Subject: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04 > > > Summary: > --------- > Overall, I do believe that MIP6 RO needs to be revised for > better security and optimization. I think using CGAs to > generate HoAs is a good step towards that. From that > perspective, this draft is good. I do, however, think that we > don't need any CoA tests (more on that in the details below). > By using CGAs and signed proof to verify HoAs and an initial > HoA test, the CN gets the same assurance about the addresses > of an MN as the HA. That alone is sufficient to generate a > binding and optionally exchange a symmetric key. Hence, I > think the "cga" part of the draft is useful, while the "cba" > part is non-essential. > > Having said that, I think it would be best if this document > actually takes a two-step process, going through experimental > track first. That would give us the opportunity to mature the > concept and have a solid proposal for MIP6 RO. I don't think > we should target a proposed standard right away - I think in > this case, going to an experimental RFC first is useful (as > we've done before with mobility optimizations such as FMIP and HMIP). > > Detailed comments > ----------------- > > (I've limited these to sections 1 to 3, since that captures > the concept) > > Major: > ------ > > 1. After some thought, I think we don't need CoA tests (and > consequently, CBA) at all here. In MIP6, CoA test makes > sense, since an attacker has to be present both on the link > between the MN and the CN and on the link between the MN and > HA to successfully arrive at the Kbm. > Without the HoTi/HoT or CoTi/CoT, this becomes easier for the > attacker, since presence is required only on one link. > However, if the MN's HoA can be cryptographically verified > and the initial HoA test can be done to (indirectly) prove > the existence of a valid registration at the HA, there should > be no need for CoTi/CoT. For e.g., the HA today does not do a > CoA verification - it goes to the same point as in 1 above I meant the same point as in 3 below (I did some re-numbering and forgot to correct this). Thanks, Vidya > that if the MN wants to flood another node by claiming a > wrong CoA, it can do that anyway by other means. > > 2. The text under "Initial home address tests" in section 3 > is confusing. I'm not sure I understand the flooding attack > as described. > If the goal is to flood any network, as I said in my first > point above, it doesn't need to be done with MIP6. What is > more important is ensuring that an MN that does not have a > binding with its HA doesn't end up creating a binding with a > random CN. The fact that the MN has a valid binding with its > HA implies a couple of things - that it has been > authenticated and authorized for MIP6 use and that it is not > claiming another node's HoA. > > Given that, the initial home address test will achieve this - > it is just that the motivation seems to differ in my mind. > > Not-so-major (not-so-minor :)) > ------------------------------ > > 3. Section 2.2 talks about redirection of an MN's > communications to a third party, thereby flooding the victim > (2nd bullet). In my view, this is not a threat that MIP6 > brings. If a malicious node has a goal of flooding a given > node, it doesn't need MIP6 to achieve that. It can send > packets to that IP address and those will do. There isn't a > real need to set up a bogus MIP6 binding to realize that > attack. So, I think that paragraph should be removed. > > 4. Also, the point about DoS attacks may stay - but, it is > probably worth mentioning that DoS attacks are achieved by a > variety of other means, some of them, much simpler than > engaging in expensive computations. > > 5. Section 3 talks about cryptographically generated home > addresses providing authentication - CGAs provide address > ownership validation, but not really authentication. In order > to authenticate a node (i.e., to verify the node is "who" it > claims to be), a verification of its identity needs to occur > - which implies a shared key or a public/private key pair > endorsed by a certificate. I'm assuming this section meant to > really talk about HoA ownership validation? > > > Vidya > > _______________________________________________ > Mipshop mailing list > Mipshop@ietf.org > https://www1.ietf.org/mailman/listinfo/mipshop > _______________________________________________ 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