Subject: Re: [6lo] Review of draft-sarikaya-6lo-ap-nd : CGA or nor CGA

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 1 Feb 2016 09:14:11 +0000

Hello Mohit

Huge thanks for this.

Let me give you a partial answer: The way we build the crypto ID can be anything the WG wants, depending on whether there is sensitivity to the CGA IPR. We can make that an open issue for the group.

What is critical and specific to this work is that we do not want to use SeND. This is because SeND forces the node to prove itself on every exchange, which is heavy in signaling and not something we can afford on LLNs. 

Here, the device will only need to prove itself reactively in case of a collision. In static or stable conditions, the network may operate without a challenge/proof. 

We can do that because, as opposed to classical ND, 6LoWPAN ND maintains a centralized state in the network in the 6LBR that can be used to associate the IP address and the crypto ID, and a regional state in the 6LR that associates the IP address and the MAC address.

Cheers,

Pascal

> -----Original Message-----
> From: Mohit Sethi [mailto:[email-masked]]
> Sent: lundi 1 février 2016 10:01
> To: [email-masked]; [email-masked]; Pascal Thubert (pthubert)
> <[email-masked]>
> Subject: Review of draft-sarikaya-6lo-ap-nd
> 
> Hi folks
> 
> Here is my review for draft-sarikaya-6lo-ap-nd-01
> 
> - Overall, I believe the draft is trying to address a valid problem.
> 
> - Before coming to the technical merits, at first glance, this proposal looked
> quite similar to CGA. While I have no horse in this race, I wonder why not
> use CGA directly (or define an extension). I understand that CGA spec was
> defined with RSA which might be unsuitable for constrained devices, but are
> there any other major differences in the spec? The authors say that " the
> cryptographic material is not embedded in the Interface ID (IID) in an IPv6
> address but used as a correlator associated to the registration of the IPv6
> address." What is the reason for not embedding? Are there any advantages
> to such an approach? When it comes to security, I would rely on an existing
> standards that are well-studied and have running code as much as possible.
> 
> - I think address spoofing is a valid problem. However, I wonder why we
> want to force the nodes to use its own MAC address. Given all the privacy
> concerns, shouldn't we just allow nodes to use a random MAC address.
> There is a trend of moving away from static MAC addresses that never
> change. For example, iOS 8 features MAC Randomization
> (http://blog.airtightnetworks.com/ios8-mac-randomization-analyzed/ ).
> Similarly, IEEE has suggested the use of MAC randomization
> (http://www.csoonline.com/article/2945044/cyber-attacks-espionage/ieee-
> groups-recommends-random-mac-addresses-for-wi-fi-security.html)
> and there was a presentation in IETF 93 about experiences with MAC
> address randomization in Windows
> (https://www.ietf.org/proceedings/93/slides/slides-93-intarea-5.pdf). If the
> nodes can do ECC, I am sure they can generate a random MAC address.
> 
> Given this, and the Alissa Coopers recommendation on MAC address privacy
> (https://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-
> 08),
> won't it be just simpler to also suggest that 6LoWPAN nodes generate a
> random MAC address during registration. I think these recommendations
> holds true even if the addresses are not used beyond the 6LBR.
> 
> - Another thing that worries me a lot is crypto agility. The draft currently
> defines just one curve (P-256). There is no way of negotiating among nodes
> and routers what kind of elliptic curves are used for public keys. Having no
> crypto agility works fine for RSA which is still accepted to be secure. I am not
> sure how well this works for ECC.
> Especially when there seem to be repeated reports of vulnerabilities found
> in different curves every now and then. If you check
> http://safecurves.cr.yp.to/ then NIST P-256 is listed as unsafe. If new devices
> come with new curve parameters, how would they inter-operate?
> The lifetime of these devices is expected to be at-least 10-20 years.
> One way to resolve this is to add curve information to the CGA params.
> And one would assume that the 6LR and 6LBR support several curves and
> use the one that is chosen by the node. I think this still requires some
> thinking.
> 
> These initial comments are based on my understanding from a first glance of
> the draft and I might have missed something completely. Please correct me
> where I am wrong.
> 
> Thanks
> /--Mohit