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