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

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 1 May 2014 08:41:58 +0000

Hello Fernando, all,

I would expect that at least 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'.

Furthermore for the 6lo active WG documents:
- draft-ietf-6lo-btle-00 has the use of hardware address for IID as a 'MAY' - that would need to become a 'SHOULD NOT' (unless there is some negative impact on performance) ?
- draft-ietf-6lo-lowpanz-04 has a MUST on the use of NodeID in the IID, however the NodeID is only 8-bit locally assigned and is not an identifiable hardware address.
- for draft-ietf-6lo-ghc I don't see issues
- for draft-ietf-6lo-lowpan-mib I don't see issues

regards,
Esko

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Thursday, May 01, 2014 03:42
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

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 01 May 2014 10:42:38 -0700

On 4/30/14, 6:42 PM, Fernando Gont wrote:
> Folks,
>
> We recently contacted the 6lo chairs asking whether there were any
> 6lo-related documents that should be mentioned in the "Updates" of our

Fernando,

Are you planning on specifying all the possible protocols tweaks that 
might be needed to existing RFCs in draft-ietf-6man-default-iids?
Unless you do you can't claim that it updates those RFCs.
And that would be completely unwieldy.

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.

That way you avoid having to design all the solutions before 
default-iids can be progressed in 6man.

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. 6lo might consider taking 
that suggestion and having either a short document which updates 6775 or 
doing a 6775-bis if there are other desirable updates (I think a 
transaction ID in the ARO is such another desirable update).

But IMHO we shouldn't have any such work hold up 
draft-ietf-6man-default-iids.

Regards,
    Erik

> 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.
>
> * 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.
>
> 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.
>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 01 May 2014 22:04:14 +0100

It is also worth noting the different scopes the IIDs can be used in. If 
the address is globally routable, there is certainly a case for adopting 
privacy addresses. However, for link local addresses, especially in a 
route-over mesh where a link-local IP packet travels strictly one node 
hop, it does not seem as critical. As mentioned below, in many cases 
6LoWPAN compression relies on a one-to-one correspondence between a link 
local and IPv6 address to provide effective compression.

Robert

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 May 2014 23:32:35 +0200

On 01 May 2014, at 23:04, Robert Cragie <[email-masked]> wrote:

> However, for link local addresses, especially in a route-over mesh where a link-local IP packet travels strictly one node hop, it does not seem as critical. As mentioned below, in many cases 6LoWPAN compression relies on a one-to-one correspondence between a link local and IPv6 address to provide effective compression.

Indeed, and a more complete approach to fix the privacy leaks for the link-local cases will involve privacy enhancements to the layers below (as discussed by Piers O'Hanlon at IETF 89 and see also https://www.w3.org/2014/strint/papers/35.pdf).

Grüße, Carsten

---

From: Owen Kirby <[email-masked]>
Date: Thu, 01 May 2014 14:55:46 -0700

Also, it should be pointed out that the privacy concerns over IPv6 and
IIDs has to do more with lifetime of the IID rather than the fact that
they just so happens to be bound to routeable addresses. In 6LoWPAN, the
IID is bound to a routable address to aid in address compression, but
the IIDs themselves are often based on ephemeral link layer addresses
that could easily be reassigned periodically* to aid user privacy.

Cheers,
Owen

* they could be easily reassigned in IEEE 802.15.4, I'm not enough of a
bluetooth expert to know how the NodeIDs are used.

On 14-05-01 02:04 PM, Robert Cragie wrote:
> It is also worth noting the different scopes the IIDs can be used in.
> If the address is globally routable, there is certainly a case for
> adopting privacy addresses. However, for link local addresses,
> especially in a route-over mesh where a link-local IP packet travels
> strictly one node hop, it does not seem as critical. As mentioned
> below, in many cases 6LoWPAN compression relies on a one-to-one
> correspondence between a link local and IPv6 address to provide
> effective compression.
>
> Robert
>
>> I would expect that at least 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'.
>>
>> - draft-ietf-6lo-btle-00 has the use of hardware address for IID as a
>> 'MAY' - that would need to become a 'SHOULD NOT' (unless there is
>> some negative impact on performance) ?
>> - draft-ietf-6lo-lowpanz-04 has a MUST on the use of NodeID in the
>> IID, however the NodeID is only 8-bit locally assigned and is not an
>> identifiable hardware address.
>> Cc: [email-masked];
>> [email-masked]; Dave Thaler
>> Samita and Ulrich kindly noted that at least some 6lo document does
>> IPv6 address compression on the assumption that the IID contains the
>> * Some OSes (notably Microsoft Windows) have moved away from
>> embedding MAC addresses in the IIDs (to mitigate the issues discussed
>> in
>> Dave Thaler had already posted some related comments on this list
>> that are related to this issue. Please see:
>>
>> 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
>> The information contained in this message may be confidential and
>> legally protected under applicable law. The message is intended
>> solely for the addressee(s). If you are not the intended recipient,
>> you are hereby notified that any use, forwarding, dissemination, or
>> reproduction of this message is strictly prohibited and may be
>> unlawful. If you are not the intended recipient, please contact the
>> sender by return e-mail and destroy all copies of the original message.
>>

---

From: Paul Duffy <[email-masked]>
Date: Fri, 02 May 2014 09:23:29 -0400

I strongly agreement with Erik's comments.  SHOULDs and identify the non 
aligned RFCs.

6775 is a perfect example.

On 5/1/2014 1:42 PM, Erik Nordmark wrote:
> draft-chakrabarti-nordmark-6man-efficient-nd. 6lo might consider 
> taking that suggestion and having either a short document which 
> updates 6775 or doing a 6775-bis if there are other desirable updates 
> (I think a transaction ID in the ARO is such another desirable update).
>
> .

---

From: Fernando Gont <[email-masked]>
Date: Sat, 03 May 2014 04:23:23 -0500

Hi, Eric,

> might be needed to existing RFCs in draft-ietf-6man-default-iids?

Are you referring to the corresponding 6lo documents, or the "ipv6 over
foo" documents we currently have in the "Updates" metadata?

>  - SHOULD use stable-privacy as default where it works (such as Ethernet)

Why not explicitly updating the "ipv6 over foo" documents in those cases
where stable-privacy does work?

FWIW, I believe the "Updates" tag is important, such that folks
implementing "ipv6 over foo" are somehow directed to default-iids...

> those get addressed the SHOULD use will be applied to those as well.

I believe the only "issue" has been that related with header compression
in 6lo.

I gues one possible option is simply to not reference the aforementioned
RFC ni the "Updates", or maybe even do reference it, but consider such
case as a valid reason to go against the "SHOULD"/"SHOULD NOT" in
default-iids..

Thoughts? (i.e., take the above as brain-storming, rather than as a
strong statement)

> default-iids can be progressed in 6man.

I certainly think that deafult-iids should wait for other work to be
progressed. If anything, it should be the other way around.

> draft-ietf-6man-default-iids.

Agreed.

Thanks so much! (your comments and feedback are always very appreciated)

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 03 May 2014 05:01:38 -0500

Hi, Esko,

Thanks so much for your feedback! Please find my responses in-line....

> RFC is then a notable exception to the 'SHOULD NOT'.

Since this one does not really follow the "SHOULD NOT", I guess we might
opt to:

a) List the RFC as "There are issues with this specification" (as
suggested by Erik), or,

b) Do not mention this RFC at all.

Thoughts?

> Furthermore for the 6lo active WG documents: - draft-ietf-6lo-btle-00
> has the use of hardware address for IID as a 'MAY' - that would need
> to become a 'SHOULD NOT' (unless there is some negative impact on
> performance)

I'd suggest that draft-ietf-6man-default-iids is referenced in that I-D.
Then you either follow the advice in draft-ietf-6man-default-iids, or
explain your reasoning to go against it. (this was suggested by Dave
Thaler earlier on).

> ? - draft-ietf-6lo-lowpanz-04 has a MUST on the use of
> NodeID in the IID, however the NodeID is only 8-bit locally assigned
> and is not an identifiable hardware address.

I'll check the aforementioned I-D when I land (I'm currently on a
plane). I'd note that the issue is not only about IIDs being derived
from hardware addresses, but also about they being constant across
different network attachment points.

Thanks so much!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 03 May 2014 15:48:30 -0500

Hi, Robert,

> local and IPv6 address to provide effective compression.

The link-local case has been discussed within 6man already. Short
summary: these addresses can link (think e.g. a node contacting an MTA
on the local network, and then the link-local address leaking out via
the email headers).

Predictable/constant addresses is something with well-known
implications. We should move away from them.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 05 May 2014 02:34:41 -0500

Hi, Carsten,

On 05/01/2014 04:32 PM, Carsten Bormann wrote:
>> However, for link local addresses, especially in a route-over mesh
>> where a link-local IP packet travels strictly one node hop, it does
>> not seem as critical. As mentioned below, in many cases 6LoWPAN
>> compression relies on a one-to-one correspondence between a link
> Indeed, and a more complete approach to fix the privacy leaks for the
> link-local cases will involve privacy enhancements to the layers
> below (as discussed by Piers O'Hanlon at IETF 89 and see also
> https://www.w3.org/2014/strint/papers/35.pdf).

While I don't necessarily disagree with doing any privacy-wise
improvements at the link-layer, that's mostly orthogonal to what we're
discussing here.

Several things to note:

* Firstly (and most importantly), traditional SLAAC IIDs mean that the
IID has the same properties as the underlying MAC address. That's where
the problem resides.  If you play with the underlying MAC address,
you're not solving that problem.

* If you do simple MAC-address-randomization + traditional SLAAC, that
would lead to IPv6 addresses that change over time, even when that's not
really desirable. In order to know where such change might be desirable,
you would need to do some sort flavor of RFC6059.. but most of the
"hints" there are not available at layer-2.

* The scale of the problem is different between MAC address privacy vs.
IPv6 address privacy: In order to exploit the former, you essentially
need a rogue device connected to the victim's network. In order to
exploit the later, you just need to be connected to the Internet.

* Finally, there could even be cases where the MAC address is not
changeable (for one reason or another).

Thanks,

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 14 May 2014 15:54:20 +0000

Hello Fernando,

> a) List the RFC as "There are issues with this specification" (as suggested by Erik), or,

for me no preference. I would expect you can either list all known RFCs with such issues, or don't mention any such RFC. In case a) both RFC6282 and 6775 should be included.

regards,
Esko

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]]
Sent: Saturday, May 03, 2014 12:02
To: Dijk, Esko; [email-masked]
Cc: [email-masked]; [email-masked]; Dave Thaler; Erik Nordmark
Subject: Re: [6lo] Generation of IPv6 IIDs

Hi, Esko,

On 05/01/2014 03:41 AM, Dijk, Esko wrote:
> 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'.

Since this one does not really follow the "SHOULD NOT", I guess we might opt to:

a) List the RFC as "There are issues with this specification" (as suggested by Erik), or,

Thoughts?

I'd suggest that draft-ietf-6man-default-iids is referenced in that I-D.
Then you either follow the advice in draft-ietf-6man-default-iids, or explain your reasoning to go against it. (this was suggested by Dave Thaler earlier on).

> ? - draft-ietf-6lo-lowpanz-04 has a MUST on the use of NodeID in the

I'll check the aforementioned I-D when I land (I'm currently on a plane). I'd note that the issue is not only about IIDs being derived from hardware addresses, but also about they being constant across different network attachment points.

Thanks so much!

Best regards,

---

From: Dave Thaler <[email-masked]>
Date: Wed, 14 May 2014 19:16:36 +0000

> Sent: Saturday, May 3, 2014 2:23 AM
> To: Erik Nordmark; [email-masked]
> Are you referring to the corresponding 6lo documents, or the "ipv6 over foo"
> documents we currently have in the "Updates" metadata?
> 
> 
> 
> FWIW, I believe the "Updates" tag is important, such that folks implementing
> "ipv6 over foo" are somehow directed to default-iids...

Agree with Fernando.  Anything that is an RFC and "just works" with
stable-privacy should be listed with Updates.

> I believe the only "issue" has been that related with header compression in
> 6lo.
> 
> I gues one possible option is simply to not reference the aforementioned RFC
> ni the "Updates", or maybe even do reference it, but consider such case as a
> valid reason to go against the "SHOULD"/"SHOULD NOT" in default-iids..
> 
> Thoughts? (i.e., take the above as brain-storming, rather than as a strong
> statement)

My slight preference is to not mention it in default-iids itself.
However, I'm also ok with saying the 6lo issue is left for future work.
In my opinion, though, default-iids should NOT list anything as 
"a valid reason to go against the SHOULD/SHOULD NOT".

-Dave

> I certainly think that deafult-iids should wait for other work to be progressed.
> If anything, it should be the other way around.

Agree.