RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04

["Narayanan, Vidya" <vidyan at qualcomm.com>]

A minor correction inline below.  

> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan at qualcomm.com] 
> Sent: Monday, August 07, 2006 2:37 PM
> To: mipshop at 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 at ietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop
> 

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