Subject: Re: [6lo] Generation of IPv6 IIDs

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 22 Jul 2014 16:41:56 +0000

Hi  Fernando and Dave:

Based on the discussions at the 6lo list regarding the impact of default-iid draft on 6lo/6lowpan documents and future ipv6-over-foo 6lo documents, Ulrich, Ralph and myself had a discussion and our recommendation to default-iid co-authors are to either list 6lo specific RFCs or make a general statement about 6lo/6lowpan documents for exceptions from default-iid  mandate. The future documents in 6lo WG  would consider the default-iid recommendations when applicable. But note that 6lo deals with  constrained nodes and RFC6282/RFC4944/RFC6755 do require using IID bits for efficiency over privacy in a constrained network environment that can be isolated from the rest of the Internet.

6lo-chairs are working on a proposed text for default-iid  for 6lo/6loWPAN documents in this regard.  Please stay tuned.

Here is a summary of comments from the 6lo WG suggestions for your reference and refreshing memory. 

Dijk, Esko <[email-masked]>
=============================
 RFC 6282 (and perhaps the RFC 4944 which it updates?) should be mentioned, since the 6LoWPAN header compression is based on the IID containing the hardware address. This RFC is then a notable exception to the 'SHOULD NOT'.
Other exceptions noted: draft-ietf-6lo-btle and draft-ietf-6lo-lowpanz which are derived from RFC6282/RFC4944.

Erik Nordmark <[email-masked]>
==============================
I think it would be better to progress default-iids with
  - SHOULD implement stable-privacy
  - SHOULD use stable-privacy as default where it works (such as Ethernet)
  - state that some issues have been identified in RFC X, Y, Z, as as those get addressed the SHOULD use will be applied to those as well.

RFC6775  requires link-local address to be configured with EUI-64 and sends error back for address registration to the link-local address derived from the EUI-64 (section 6.5.2)

Paul Duffy <[email-masked]>
===========================
In strong agreement with Erik's suggestions. RFC 6775 should be in the list of exceptions

Robert Cragie <[email-masked]>
===================================
different scopes the IIDs can be used. In many cases 6LoWPAN compression relies on a one-to-one correspondence between a link local and IPv6 address

 Carsten Bormann <[email-masked]>
==========================
Privacy leaks for link-local cases requires privacy fixing at the lower layers: https://www.w3.org/2014/strint/papers/35.pdf

Owen Kirby <[email-masked]>
===========================
Re-assigning link-layer IID is another way to solve privacy in 6lo

---

Best regards,
-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Wednesday, April 30, 2014 6:42 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Dave Thaler
Subject: [6lo] Generation of IPv6 IIDs

Folks,

We recently contacted the 6lo chairs asking whether there were any 6lo-related documents that should be mentioned in the "Updates" of our
I-D: <http://tools.ietf.org/html/draft-ietf-6man-default-iids>.

We briefly discussed this off-list, and they suggested that raised this on this list.

Here's the summary of our exchange:

Samita and Ulrich kindly noted that at least some 6lo document does IPv6 address compression on the assumption that the IID contains the underlying hardware address.

On the other hand we noted that:

* Some OSes (notably Microsoft Windows) have moved away from embedding MAC addresses in the IIDs (to mitigate the issues discussed in <http://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy>).

* Additionally, there's an existing 6man recommendation (in RFC 7136) against expecting any semantics in the IPv6 IIDs -- the IID should be treated as a string of opaque bits.

Dave Thaler had already posted some related comments on this list that are related to this issue. Please see:

* <http://www.ietf.org/mail-archive/web/6lo/current/msg00403.html>

As noted by Dave (and also by myself), there seem to be some statements in 6lo documents which seem to go against some 6man recommendations.
That said, in the specific case of header compression, you might have a case to go against the "SHOULD NOT" in <http://tools.ietf.org/html/draft-ietf-6man-default-iids> -- although expecting specific semantics in the IPv6 IIDs still goes against RFC 7136.

All the above said, we still wonder if there are any 6lo-related documents we should include in the "Updates" of draft-ietf-6man-default-iids.

P.S.: I apologize if some of the above comments are not that timely...
but I was not following the 6lo work.

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jul 2014 13:26:03 -0400

I will add that we may have 802.1AR certificates built into constrained
devices which authenticate their EUI-64, and if they can't speak from that
address, then all the security may fail.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 23 Jul 2014 18:44:20 +0000

Thanks for adding this point. Perhaps it can be included as one of the reasons for exceptions for EUI-64based IPv6 addresses.
Michael,  a novice question : Can you please elaborate use of 802.1AR  device security in 6lo/6tisch type of devices ? ie are they going to be available as an option/default for the 802.15.4 devices?

-Samita

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, July 22, 2014 10:26 AM
To: Samita Chakrabarti
Cc: Fernando Gont; [email-masked]; [email-masked]; 6man Chairs ([email-masked]); [email-masked]; Dave Thaler
Subject: Re: [6lo] Generation of IPv6 IIDs

I will add that we may have 802.1AR certificates built into constrained devices which authenticate their EUI-64, and if they can't speak from that address, then all the security may fail.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Jul 2014 16:19:52 -0400

Samita Chakrabarti <[email-masked]> wrote:
    > Thanks for adding this point. Perhaps it can be included as one of the
    > reasons for exceptions for EUI-64based IPv6 addresses.  Michael, a
    > novice question : Can you please elaborate use of 802.1AR device
    > security in 6lo/6tisch type of devices ? ie are they going to be
    > available as an option/default for the 802.15.4 devices?

All of 802.1AR can be implemented in software, provided with a 1k of
"parameter" flash for the private key, and some ECDSA libraries...
clearly, there are advantages to having it all in a tamper-proof hardware
module and the 802.1AR document spends some space explaining all the
requirements that such a device should support;
And currently available devices with ECDSA/AES hardware can certainly do it
all cheaper and at lower energy.

(I hope to have the resources to implement something in Contiki at some point
this year.)

---

From: Fernando Gont <[email-masked]>
Date: Wed, 23 Jul 2014 20:57:12 -0400

Hi, Samita,

[Erik Nordmark added t te CC list]

Thanks so much for your effort and help in summarizing the discussion!
Please find my comments in-line....

On 07/22/2014 12:41 PM, Samita Chakrabarti wrote:
> 
> Based on the discussions at the 6lo list regarding the impact of
> default-iid draft on 6lo/6lowpan documents and future ipv6-over-foo
> 6lo documents, Ulrich, Ralph and myself had a discussion and our
> recommendation to default-iid co-authors are to either list 6lo
> specific RFCs or make a general statement about 6lo/6lowpan documents
> for exceptions from default-iid  mandate. The future documents in 6lo
> WG  would consider the default-iid recommendations when applicable.
> But note that 6lo deals with  constrained nodes and
> RFC6282/RFC4944/RFC6755 do require using IID bits for efficiency over
> privacy in a constrained network environment that can be isolated
> from the rest of the Internet.

The question here maybe is whether we want to flag these documents as
"exceptions", or whether we want to flag them as "these documents rely
on MAC-address-based IIDs. They may continue to employ such IIDs while a
solution that does not rely on such IIDs is generated".

(i.e., "it's okay to leave as is" vs. "there's work to be done here"...)

The "there's work to be done" option seems to be the one suggested by
Erik, and I tend to like it better than the "leave it 'as is'"

> Carsten Bormann <[email-masked]> ========================== Privacy
> leaks for link-local cases requires privacy fixing at the lower
> layers: https://www.w3.org/2014/strint/papers/35.pdf
> 
> Owen Kirby <[email-masked]> =========================== Re-assigning
> link-layer IID is another way to solve privacy in 6lo

My take is that these two are orthogonal. So I don't think one should
consider "randomizing the MAC address" as an alternative to employing
privacy-enhanced IIDs.

Thanks!

Best regards,

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 23 Jul 2014 18:05:49 -0700

> solution that does not rely on such IIDs is generated".

I think we should assume that those documents will be updated in the 
future to provide the option to work with other IIDs even if that comes 
with lower efficiency.
> Erik, and I tend to like it better than the "leave it 'as is'"

Yep. Once such work has been done there might be a deployment choice 
(depending on whether there would be a loss in efficiency with different 
IIDs).

I think the

802.1AR point that Michael brought up is more about the MAC address than the IID. One should be able to use a certifcate tied to a MAC address even if the IID is not based on the MAC address.

     Erik

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 24 Jul 2014 05:19:41 +0000

HI Fernando:

Please see in-line.

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2014 5:57 PM
To: Samita Chakrabarti; [email-masked]
Cc: [email-masked]; 6man Chairs ([email-masked]); [email-masked]; Dave Thaler; Erik Nordmark
Subject: Re: [6lo] Generation of IPv6 IIDs

Hi, Samita,

On 07/22/2014 12:41 PM, Samita Chakrabarti wrote:
> privacy in a constrained network environment that can be isolated from 
> the rest of the Internet.

The question here maybe is whether we want to flag these documents as "exceptions", or whether we want to flag them as "these documents rely on MAC-address-based IIDs. They may continue to employ such IIDs while a solution that does not rely on such IIDs is generated".
[SC>]  That should work.

RFC6775 could be updated to address privacy options more easily than other documents (RFC 4944 and RFC 6282). Given the constrained node application scenarios, I am not sure it will change anytime soon unless we have options to change them at the link-layer. Also there is question about backward compatibility of the thousands of  tiny devices that already follow the current specs. But in the upcoming ipv6-over-foo documents, we can consider adding  privacy options though they will be definitely inefficient compared to the current HC mechanism.

Thanks,
-Samita

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 24 Jul 2014 05:25:19 +0000

On Jul 23, 2014, at 6:05 PM, Erik Nordmark <[email-masked]> wrote:

> I think we should assume that those documents will be updated in the future to provide the option to work with other IIDs even if that comes with lower efficiency.

Note that RFC 6282 already provides the option:
- If the IID can be derived from MAC address, great.
- If not, things will still work just with reduced efficiency.

Section 10 of RFC 4944 also provides the same option, but has since been replaced by the encoding specified in RFC 6282.

Also note that 802.15.4 interfaces have both a stable MAC address (EUI-64) and a locally-significant, dynamic MAC address (Short Address).  Many of the arguments against MAC-address-based IIDs may not apply when using Short Addresses.

—
Jonathan Hui

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 24 Jul 2014 05:32:34 +0000

Hi Jonathan/Erik:

That's a good point. 

Jonathan: could we then request you to provide a text that can be added to default-iid document for 6lo related documents ?

Thanks,
-Samita

-
Jonathan Hui

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 24 Jul 2014 05:27:51 -0700

[Hit send too early]

> Also note that 802.15.4 interfaces have both a stable MAC address (EUI-64) and a locally-significant, dynamic MAC address (Short Address).  Many of the arguments against MAC-address-based IIDs may…

Good.

The issue I know about is in RFC 6775 which would fail to deliver errors 
to an ARO if the host doesn't have a link-local address with a 
EUI-64-based IID.

RFC 6775 (6lowpan-nd) makes the assumption that the host always has a 
link-local address configured with the EUI-64 of the host.
That assumption is used in section 6.5.2 to send errors back to hosts.
Note that we already know of a solution, which is local to the router 
implementation, which is already captured in section 9.7 in 
draft-chakrabarti-nordmark-6man-efficient-nd.

That doesn't prevent a host from having global addresses with other 
IIDs. In fact the host can have and use a link-local with a different 
IID as long as it will be able to receive the error packets sent to 
fe80::modified-EUI-64.

    Erik

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 24 Jul 2014 13:17:54 -0400

On Thu, Jul 24, 2014 at 1:25 AM, Jonathan Hui (johui) <[email-masked]>
wrote:

> To recap, re-using the L2 addresses for IIDs contributes to the efficiency
of
IPHC [RFC 6282].  Using locally-assigned short MACs provides the greatest
efficiency.

Requiring randomly assigned IIDs can have a significant impact on 6lo
networks
with short frames, which already have reduced payloads due to security and
other
headers.  In some cases, random IIDs might necessitate an additional frame
per
message.

> Section 10 of RFC 4944 also provides the same option, but has since been
> replaced by the encoding specified in RFC 6282.
>
> Also note that 802.15.4 interfaces have both a stable MAC address (EUI-64)
> and a locally-significant, dynamic MAC address (Short Address).  Many of
> the arguments against MAC-address-based IIDs may not apply when using Short
> Addresses.
>
> I'm not sure that any of the arguments do apply when using locally assigned
short MAC addresses.  Please note that draft-ietf-6lo-6lobac *only* uses
locally
assigned short MAC addresses.

Kerry Lynn

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 24 Jul 2014 05:21:16 -0700

Erik

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Jul 2014 13:43:29 -0400

On 07/24/2014 01:17 PM, Kerry Lynn wrote:
>     > I think we should assume that those documents will be updated in
>     the future to provide the option to work with other IIDs even if
>     that comes with lower efficiency.
> 
> To recap, re-using the L2 addresses for IIDs contributes to the
> efficiency of

I'd personally say that sticking to MAC-derived IIDs is not a good idea.
It's okay if that's still employed before something else is engineered,
though.

> with short frames, which already have reduced payloads due to security
> and other
> headers.  In some cases, random IIDs might necessitate an additional
> frame per
> message.
>  
> 
>     Section 10 of RFC 4944 also provides the same option, but has since
>     been replaced by the encoding specified in RFC 6282.
> 
>     Also note that 802.15.4 interfaces have both a stable MAC address
>     (EUI-64) and a locally-significant, dynamic MAC address (Short
>     Address).  Many of the arguments against MAC-address-based IIDs may
>     not apply when using Short Addresses.
> 

If you generate your IIDs from a constant IID, they do apply. Please see
e.g.
<http://tools.ietf.org/id/draft-ietf-6man-ipv6-address-generation-privacy-01.txt>
for a longer version of the story.

Thanks,

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 24 Jul 2014 17:50:03 +0000

Ditto what Erik said....we operate AMI networks where most of the EUI-64 threats do not exist, and 6775 mechanisms are employed - it would be nice if EUI-64s were not "deprecated" but still allowed, with the existing alternative documents being available for those that need it.

Randy

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Thursday, July 24, 2014 8:21 AM
To: Jonathan Hui (johui); Erik Nordmark
Cc: [email-masked]; 6man Chairs ([email-masked]); Erik Nordmark; Dave Thaler; Samita Chakrabarti; [email-masked]; Fernando Gont; [email-masked]
Subject: Re: [6lo] Generation of IPv6 IIDs

> Also note that 802.15.4 interfaces have both a stable MAC address (EUI-64) and a locally-significant, dynamic MAC address (Short Address).  Many of the arguments against MAC-address-based IIDs may…

The issue I know about is in RFC 6775 which would fail to deliver errors to an ARO if the host doesn't have a link-local address with a EUI-64-based IID.

RFC 6775 (6lowpan-nd) makes the assumption that the host always has a link-local address configured with the EUI-64 of the host.
That assumption is used in section 6.5.2 to send errors back to hosts.
Note that we already know of a solution, which is local to the router implementation, which is already captured in section 9.7 in draft-chakrabarti-nordmark-6man-efficient-nd.

    Erik

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 24 Jul 2014 17:47:54 +0000

Randy

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Thursday, July 24, 2014 8:21 AM
To: Jonathan Hui (johui); Erik Nordmark
Cc: [email-masked]; 6man Chairs ([email-masked]); Erik Nordmark; Dave Thaler; Samita Chakrabarti; [email-masked]; Fernando Gont; [email-masked]
Subject: Re: [6lo] Generation of IPv6 IIDs

    Erik

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Jul 2014 17:06:59 -0400

Hi, Randy,

Essentially, the two options seem to be:

1) Say that what 6lo currently does is a perfetly valid exception (with
no need to do anything in this area in the future)

2) Flag what 6lo is doing as "something that doesn't comply with
default-iids. You may still use this n the mean time, but a solution
should be engineered to comply with default-iids"

My understanding is that Erik is proposing "2)"... and I tend to like
that option.

Thoughts?

Thanks!

Best regards,
Fernando

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 24 Jul 2014 21:34:13 +0000

[Sorry for the dup.  The 6lo mailer is complaining that there’s too many recipients.]

> It's okay if that's still employed before something else is engineered,

Can you elaborate more?  As mentioned before, the scope of 802.15.4 Short Addresses is the PAN.

> for a longer version of the story.

I assume you meant “constant MAC address”.  In any case, see my comment above.

—
Jonathan Hui

---

From: "Turner, Randy" <[email-masked]>
Date: Fri, 25 Jul 2014 14:17:56 +0000

When you say "doesn't comply with default IIDs", we're really saying default IIDs that do not use EUIs ?  So we would be saying, it's ok to do this (using EUI-based addressing) for now, but a future draft (or drafts) may restate the existing document set to comply with a better way to derive IIDs  in the future ?

Randy

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Thursday, July 24, 2014 5:07 PM
To: Turner, Randy; [email-masked]'; 6man Chairs ([email-masked]) ([email-masked])
Cc: Erik Nordmark
Subject: Re: [6lo] FW: Generation of IPv6 IIDs

Hi, Randy,

1) Say that what 6lo currently does is a perfetly valid exception (with no need to do anything in this area in the future)

2) Flag what 6lo is doing as "something that doesn't comply with default-iids. You may still use this n the mean time, but a solution should be engineered to comply with default-iids"

My understanding is that Erik is proposing "2)"... and I tend to like that option.

Thoughts?

Thanks!

Best regards,
Fernando

On 07/24/2014 01:50 PM, Turner, Randy wrote:
> Cc: [email-masked]; 6man Chairs 
> ([email-masked]); Erik Nordmark; Dave Thaler; Samita 
> Chakrabarti; [email-masked]; Fernando Gont; 
> [email-masked]