Subject: Re: [6lo] Review of draft-sarikaya-6lo-ap-nd: on static MAC

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 1 Feb 2016 12:15:23 +0000

Hello Mohit:

OTOH, only addresses that are derived from the MAC may be compressed statelessly by 6LoWPAN. So the natural suggestion in 6LoWPAN would be that when a node forms a new MAC address, it also forms a new IP address. The cost / value ratio of doing this is a 6LoWPAN problem, not a problem with this draft. 

This draft only adds a cost is for a transient period the device wants to use its old IP address (built out of its old MAC address) associated with it new MAC address. The impact is managed local between the 6LR(s) and the node. This is because the 6LR(s) need(s) to maintain the association of the crypto material, the IP address and the MAC address whereas the 6LBR only maintains the association between the crypto ID and the IP address.

In case of a change suggested by a device, a 6LR has to validate whether the change is legit, IOW whether the new device is allowed to take over the IP address.  This is done by challenging the requesting node to prove that it owns the crypto ID which is the token of ownership. 

So changing the MAC is doable at a cost, and if the text seems to preclude it, then we need to change the text.

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

---

From: Mohit Sethi <[email-masked]>
Date: Mon, 1 Feb 2016 15:51:51 +0200

Hi Pascal

I think both this and your previous email (CGA or nor CGA) are related.

I think the frequency of MAC address changes really depends on the node. 
If the node is mobile and moves around and attaches to different 6LRs, 
then it should use a different MAC address (and different IP address 
derived from this MAC) when it moves. But other less mobile nodes may 
not change it at all after registering with the 6LR (or only after a 
year/or when the battery is changed).

"

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.

"

If this is the case, then perhaps we don't even need all that crypto at 
all then. The node registers itself with a randomly generated MAC 
address. When there is a collision (i.e. a new node asking for the same 
IP Address assignment), the 6LR/6LBR simply asks the newly joining 
device to generate another random MAC and register. Is there a benefit 
of proving MAC address ownership other than loosing some private info?

Thanks
/--Mohit

---

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

Hello again Mohit.

The crypto is only needed if the IP address is claimed at another place, or for a different MAC address at the same place. So indeed is the device that moves always forms new MAC and IP address, then there is no collision and no need for this draft. And indeed in case of a collision the node is free to form a new IPv6 address, 6LoWPAN ND allows for that.

But 
1) A node may need more than one address. It usually has only one MAC address

2) changing the IP address is usually a bad idea in LLN, sometimes for bad reasons. Like the IP address can be used as device ID, like the actuator for that control loop is IP address blah. Or the energy expense of renumbering. And even if the IP can be changed, it may take time and in the meantime the device may need to use both old and new addresses.

2) If the first owner changes its MAC address or moves at a different place, that must be recognized and accepted. Whereas the case where a different node wants to steal an address is a DAD case that has to be rejected. 6LoWPAN uses a unique ID for doing that, but both the unique ID and the MAC address maybe spoofed. This draft aims and preventing this situation.

Cheers,

Pascal

> Sent: lundi 1 février 2016 14:52
> To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: Review of draft-sarikaya-6lo-ap-nd: on static MAC
> 
> Hi Pascal
> 
> If the node is mobile and moves around and attaches to different 6LRs, then
> it should use a different MAC address (and different IP address derived from
> this MAC) when it moves. But other less mobile nodes may not change it at
> all after registering with the 6LR (or only after a year/or when the battery is
> changed).
> 
> "
> 
> 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.
> 
> "
> 
> If this is the case, then perhaps we don't even need all that crypto at all
> then. The node registers itself with a randomly generated MAC address.
> When there is a collision (i.e. a new node asking for the same IP Address
> assignment), the 6LR/6LBR simply asks the newly joining device to generate
> another random MAC and register. Is there a benefit of proving MAC address
> ownership other than loosing some private info?
> 
> Thanks
> /--Mohit
> 
> > OTOH, only addresses that are derived from the MAC may be compressed
> statelessly by 6LoWPAN. So the natural suggestion in 6LoWPAN would be
> that when a node forms a new MAC address, it also forms a new IP address.
> The cost / value ratio of doing this is a 6LoWPAN problem, not a problem
> with this draft.
> >
> > This draft only adds a cost is for a transient period the device wants to use
> its old IP address (built out of its old MAC address) associated with it new
> MAC address. The impact is managed local between the 6LR(s) and the node.
> This is because the 6LR(s) need(s) to maintain the association of the crypto
> material, the IP address and the MAC address whereas the 6LBR only
> maintains the association between the crypto ID and the IP address.
> >
> > In case of a change suggested by a device, a 6LR has to validate whether
> the change is legit, IOW whether the new device is allowed to take over the
> IP address.  This is done by challenging the requesting node to prove that it
> owns the crypto ID which is the token of ownership.
> >
> >> - 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.
> >> (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.
> >>
> >> 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?
> >> 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
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 2 Feb 2016 11:59:28 -0600

Hi Mohit,

On Mon, Feb 1, 2016 at 7:51 AM, Mohit Sethi <[email-masked]> wrote:
> I think the frequency of MAC address changes really depends on the node. If
> the node is mobile and moves around and attaches to different 6LRs, then it
> should use a different MAC address (and different IP address derived from
> all after registering with the 6LR (or only after a year/or when the battery
> is changed).
>
> "
>
> 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.
>
> "
>
> then. The node registers itself with a randomly generated MAC address. When
> there is a collision (i.e. a new node asking for the same IP Address

Thanks for bringing up MAC address privacy, CGA or why not SeND,
crypto agility issues.
We will revise the draft with clarifications on these.
If you have other concerns, please let us know.

Regards,

Behcet
>> statelessly by 6LoWPAN. So the natural suggestion in 6LoWPAN would be that
>> when a node forms a new MAC address, it also forms a new IP address. The
>> cost / value ratio of doing this is a 6LoWPAN problem, not a problem with
>> this draft.
>>
>> This draft only adds a cost is for a transient period the device wants to
>> use its old IP address (built out of its old MAC address) associated with it
>> new MAC address. The impact is managed local between the 6LR(s) and the
>> node. This is because the 6LR(s) need(s) to maintain the association of the
>> crypto material, the IP address and the MAC address whereas the 6LBR only
>> IP address.  This is done by challenging the requesting node to prove that
>> it owns the crypto ID which is the token of ownership.
>>
>>> currently
>>> found