Subject: Re: I-D Action: draft-ietf-6man-default-iids-04.txt

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 3 Jul 2015 13:18:43 +0200

IMHO I think it makes sense to say that. I.e. "MAY implement [ll-based
IIDs] but SHOULD NOT use [them]." because one couldnt force that many
existing IPv6 stacks to remove the ll-based IID formation code, yet the
implementers may write a knob qualifying its use, knob turned off by
default.

Alex

Le 01/07/2015 07:20, Fernando Gont a écrit :
> Ralph, Samita, and co-authors (and wg in general),
>
> Could you please take a look at Mark's comment and rationale, and vice
> your opinion?
>
> He essentially argues that we should remove the "MAY" in:
>   "It is RECOMMENDED by this document that future specifications do not
>    specify IPv6 address generation schemes that embed the underlying
>    link-layer address in the IID.  Future specifications MAY use an IID
>    based on a node's link-layer address if design and engineering
>    considerations warrant."
>
> (his rationale is provided below).
>
> I'm fine with applying his suggested change, but would like to hear your
> thoughts before applying any changes.
>
> Thanks!
>
> Best regards,
> Fernando
>
>
>
>
> On 07/01/2015 01:33 AM, Mark Smith wrote:
>> Hi Fernando,
>>
>> On 1 July 2015 at 08:52, Fernando Gont <[email-masked]> wrote:
>>> Hi, Mark,
>>>
>>> On 06/30/2015 04:25 AM, Mark Smith wrote:
>>>>>> "Future specifications that specify IPv6 address generation schemes
>>>>>> SHOULD NOT embed the underlying link-address in the IID. Even when the
>>>>>> link-layer address is randomised as recommended previously, the IPv6
>>>>>> IID becomes a globally unique identifier for as long as the link-layer
>>>>>> address derived IID continues to be used. For low powered battery
>>>>>> operated devices, this globally unique IID may persist for many months
>>>>>> and possibly years. Random, yet rarely or never changing IIDs derived
>>>>>> from link-layer addresses are vulnerable to the threats described for
>>>>>> Constant IIDs in [draft-ietf-6man-ipv6-address-generation-privacy]"
>>>>>
>>>>> I will let others weigh in. IMHO, this is getting into to many details
>>>>> regarding an approach that we're recommending against in the first
>>>>> place. If anything, we might include something along these lines in
>>>>> draft-ietf-6man-ipv6-address-generation-privacy but it would seem out of
>>>>> scope to me.
>>>>
>>>>
>>>> The key thing I'm concerned about is the MAY in the last sentence
>>>> about future specifications. MAY means optional in any case rather
>>>> than only allowed in corner cases after careful consideration.
>>>
>>> I kind of agree with what you say. However, please note that the
>>> previous sentence says that the privacy-enhanced approach should be the
>>> default IID generation scheme.
>>>
>>> That is, hosts SHOULD implement and employ (by default) RFC7217, and MAY
>>> implement an IID generation scheme based on the link-layer addresses.
>>> So, you have to have "a very good reason" no to use (by default)
>>> RFC7217. -- i.e., the end-result is the same as the one you intend.
>>>
>>>
>>>
>>>> Perhaps all that is really necessary is to remove that sentence, as it
>>>> seems to be mostly contradicting the previous one ("you should not
>>>> embed link-layer addresses as IIDs, but you can if you need to or want
>>>> if it is easier to design or engineer it that way" - and as smart
>>>> people are usually naturally lazy, they'll avoid doing harder stuff
>>>> that they don't have to.)
>>>
>>> You MAY implement it, but SHOULD NOT use it by default.
>>
>> Re-quoting the text just to make the context clearer:
>>
>> "It is RECOMMENDED by this document that future specifications do not
>>     specify IPv6 address generation schemes that embed the underlying
>>     link-layer address in the IID.  Future specifications MAY use an IID
>>     based on a node's link-layer address if design and engineering
>>     considerations warrant."
>>
>> I think the MAY in very limited corner cases is implicit in the use of
>> SHOULD NOT in the previous sentence rather than a MUST. I don't really
>> see why it is necessary to subsequently explicitly state the MAY case,
>> which I fear can also be used to excuse not implementing RFC7217 when
>> it might be possible to.
>>
>> A "design" consideration from the "design and engineering
>> considerations warrant" caveat is what are the minimum features
>> necessary to ship the product as soon as possible - so optional or
>> possibly optional security (i.e., RFC7217) will get dropped if it
>> delays the product, unless it is perceived that it would cause market
>> failure of the product.
>>
>> As a broad observation, I think security/privacy has unfortunately
>> ended up being "too optional" in the past. Specific examples that have
>> effected me that I can think of are DECT devices for where encryption
>> was optional (I couldn't find a home phone that implemented DECT
>> encryption when I went to buy one) and much more recently
>> Bluetooth/Bluetooth LE devices, where encryption is also optional, and
>> since both those types of devices use radio signals, the exposure is
>> much larger then when I've either used wired Internet access or
>> properly secured Wifi.
>>
>>>
>>> FWIW, I'm okay myself with what you propose... But since the
>>> requirements language was hand-crafted with the 6lo people (the guys
>>> that essentially asked for some room for exception). - i.e., it took a
>>> while to converge to the current text... and if we start tweaking it,
>>> I'm afraid it might take forever (if ever) to converge.
>>>
>>
>> With how widely the types and numbers of IoT devices that 6lo will be
>> implemented on, how sensitive the data they may be collecting, what
>> they're controlling, and how visible the radio signals of these
>> devices might be in public spaces, I'm starting to think that the
>> savings of using link-layer IIDs to avoid of a few ND packets and to
>> avoid implementing RFC7217 might not be worth the security risk. Those
>> specific types of devices might be the ones where RFC7217 might be
>> actually more important than in other cases.
>>
>> I don't think going back to the 6lo people will end up an endless
>> loop. I think all it would be necessary to ask them is would they be
>> happy for the second sentence to be dropped in the following. The
>> RECOMMENDED ("SHOULD") rather than a MUST in the first sentence allows
>> them room to use link-layer addresses as IIDs if they absolutely must.
>> I think if they're unhappy with the first sentence by itself, then I
>> think it'd actually be a disagreement with the first sentence, and we
>> should then find out why they actually think implementing RFC7271 is
>> really a MAY rather than a RECOMMENDED/SHOULD.
>>
>> "It is RECOMMENDED by this document that future specifications do not
>>     specify IPv6 address generation schemes that embed the underlying
>>     link-layer address in the IID.  <strike>Future specifications MAY use an IID
>>     based on a node's link-layer address if design and engineering
>>     considerations warrant.</strike>"
>>
>>
>> Thanks very much,
>> Mark.
>>
>>
>>
>>> Thanks!
>>>
>>> Cheers,
>>> --
>>> Fernando Gont
>>> SI6 Networks
>>> e-mail: [email-masked]
>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>>
>>>
>>>
>>>
>>
>
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 4 Jul 2015 08:40:15 +1000

Hi Alex,

> implementers may write a knob qualifying its use, knob turned off by

Keep in mind this specific text we're discussing is about future specifications.

I think it has been too easy to justify avoiding implementing security
and privacy in the past. We need to stop that being the case in the
future, by reducing the size of possible loopholes.

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 6 Jul 2015 07:31:37 +0000

Hi Fernando,

Thanks for bringing this request to our attention.

From the thread of email chain, I understand that Mark recommends removing the last sentence.
Thus Mark's  suggested text is:
"It is RECOMMENDED by this document that future specifications do not
  specify IPv6 address generation schemes that embed the underlying
  link-layer address in the IID."

The reason, the" MAY" was added for 6lo usecases where IID-based implementations are  needed for the constrained environment. However  the wording "Future specifications MAY use..."  might be causing concern that it might create a loophole for non-constrained nodes.  Though I think the current sentence makes perfect sense for many implementations and their use cases. 

Here is a suggested alternative considering the rough consensus discussed in 6lo WG:

"It is RECOMMENDED by this document that future specifications do not
  specify IPv6 address generation schemes that embed the underlying
  link-layer address in the IID.  However, future specifications MAY use an IID
  based on a node's link-layer address if design and engineering
  considerations warrant( example: constrained nodes networks)"

I am copying 6lo WG here, for comments.

Regards,
-Samita

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 10:21 PM
To: Ralph Droms; Samita Chakrabarti; Dave Thaler; Alissa Cooper; Will Liu (Shucheng)
Cc: Mark Smith; Mark ZZZ Smith; [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-04.txt

Could you please take a look at Mark's comment and rationale, and vice your opinion?

I'm fine with applying his suggested change, but would like to hear your thoughts before applying any changes.

Thanks!

Best regards,
Fernando

On 07/01/2015 01:33 AM, Mark Smith wrote:
>>>>> "Future specifications that specify IPv6 address generation 
>>>>> schemes SHOULD NOT embed the underlying link-address in the IID. 
>>>>> Even when the link-layer address is randomised as recommended 
>>>>> previously, the IPv6 IID becomes a globally unique identifier for 
>>>>> as long as the link-layer address derived IID continues to be 
>>>>> used. For low powered battery operated devices, this globally 
>>>>> unique IID may persist for many months and possibly years. Random, 
>>>>> yet rarely or never changing IIDs derived from link-layer 
>>>>> addresses are vulnerable to the threats described for Constant IIDs in [draft-ietf-6man-ipv6-address-generation-privacy]"
>>>>
>>>> I will let others weigh in. IMHO, this is getting into to many 
>>>> details regarding an approach that we're recommending against in 
>>>> the first place. If anything, we might include something along 
>>>> these lines in draft-ietf-6man-ipv6-address-generation-privacy but 
>>>> it would seem out of scope to me.
>>>
>>>
>> previous sentence says that the privacy-enhanced approach should be 
>> the default IID generation scheme.
>>
>> That is, hosts SHOULD implement and employ (by default) RFC7217, and 
>> MAY implement an IID generation scheme based on the link-layer addresses.
>>> Perhaps all that is really necessary is to remove that sentence, as 
>>> it seems to be mostly contradicting the previous one ("you should 
>>> not embed link-layer addresses as IIDs, but you can if you need to 
>>> or want if it is easier to design or engineer it that way" - and as 
>>> smart people are usually naturally lazy, they'll avoid doing harder 
>>> stuff that they don't have to.)
>>
>> that essentially asked for some room for exception). - i.e., it took 
>> a while to converge to the current text... and if we start tweaking 
>> it, I'm afraid it might take forever (if ever) to converge.
>>
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 6 Jul 2015 07:37:23 +0000

Reposting  because it did not allow posting in multiple mailing lists.

-Samita

-----Original Message-----
From: Samita Chakrabarti 
Sent: Monday, July 06, 2015 12:31 AM
To: 'Fernando Gont'; Ralph Droms; Dave Thaler; Alissa Cooper; Will Liu (Shucheng)
Cc: Mark Smith; Mark ZZZ Smith; [email-masked]; [email-masked]; [email-masked]
Subject: RE: I-D Action: draft-ietf-6man-default-iids-04.txt

Hi Fernando,

Regards,
-Samita

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]]
Sent: Tuesday, June 30, 2015 10:21 PM
To: Ralph Droms; Samita Chakrabarti; Dave Thaler; Alissa Cooper; Will Liu (Shucheng)
Cc: Mark Smith; Mark ZZZ Smith; [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-04.txt

Thanks!

Best regards,
Fernando

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 Jul 2015 18:20:33 +1000

Hi Samita,

On 6 July 2015 at 17:31, Samita Chakrabarti
<[email-masked]> wrote:
> The reason, the" MAY" was added for 6lo usecases where IID-based implementations are  needed for the constrained environment.
 However  the wording "Future specifications MAY use..."  might be
causing concern that it might create a loophole for non-constrained
nodes.  Though I think the current sentence makes perfect sense for
many implementations and their use cases.

So I'm curious why the allowance in the implied "SHOULD NOT" in the
'RECOMMENDED' is not enough, such that it is necessary to add the MAY
statement?

A design consideration is "only implementing the minimal features so
that we can get to the market as soon as possible". I think the MAY
statement can therefore easily be interpreted as making link-layer
based IIDs far more acceptable than the prior RECOMMENDED (SHOULD NOT)
intends.

Why or how would the "RECOMMENDED" statement by itself,

prevent you from using link-layer addresses as IIDs when it is
absolutely necessary?

Is it because RECOMMENDED and SHOULD are seen to have slightly
different meanings, even though they're the same in RFC2119?

 My first language is English, yet I consider the strength of the
words 'recommended' and 'should' to have different strengths.
Personally, I'd prefer to see the single statement being:

"Future specifications SHOULD NOT specify IPv6 address generation
schemes that embed the underlying link-layer address in the IID."

as I find it more direct and clearer.

I think this would strongly state that link-layer addresses should not
be used in most cases, while allowing room for the corner cases where
it is absolutely necessary.

The reason I care about this is because I've been both using Bluetooth
LE fitness devices for the last 5 or some months in a number of public
spaces, and have also been out of interest collecting 100s of BLE
addresses in public spaces I've visited using this utility in the last
couple of months, and have been surprised at how many there are out
there, and how easy this utility makes it to record them, including
their geographic location.

https://play.google.com/store/apps/details?id=com.contextis.android.BLEScanner

As Bluetooth LE seems to be seen as a 6lo link-layer, I'd really like
to see link-layer addresses not be used for IPv6 IIDs with it because
of how many BLE device details I've passively collected.

Thanks very much,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 Jul 2015 18:31:18 +1000

> many implementations and their use cases.

<snip>

> of how many BLE device details I've passively collected.

Hmm, looking a bit further into BLE scanning apps, somebody has
already taken this to the next step. They're creating a global
database of BLE devices and their geographic location:

http://www.earthping.com/index.html

---

From: Tim Chown <[email-masked]>
Date: Mon, 6 Jul 2015 13:37:42 +0100

Hi,

> On 6 Jul 2015, at 09:20, Mark Smith <[email-masked]> wrote:
> 
> Hi Samita,
> 

This would seem the best wording to me. Adding the MAY is both redundant, and reads poorly. Imagine if every RFC did this.

> of how many BLE device details I've passively collected.

Interesting. One to run in Prague perhaps...

Best wishes,
Tim

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 6 Jul 2015 12:26:04 -0400

On Wed, Jul 1, 2015 at 1:20 AM, Fernando Gont <[email-masked]> wrote:

> As the lead author of https://tools.ietf.org/html/draft-ietf-6man-6lobac,
I'm
strongly in favor of retaining the option to specify IIDs based on locally
assigned link-layer addresses, particularly for link-local addresses.  I'm
prepared to provide a defensible example of "design and engineering
considerations" if that would be useful.

Locally assigned short identifiers (such as the IEEE 802.15.4 short address)
are dynamically assigned on a per-network basis, support the most efficient
compression afforded by LOWPAN_IPHC, and do not "leak" origin of
manufacture or personally identifying information.

The first sentence in the paragraph above could be interpreted as
recommending that authors of future proposals MUST NOT provide a
specification for forming IIDs from link-layer addresses.  The MAY
in the following sentence makes it clear that the recommendation is
SHOULD NOT.

What might be helpful is for the supporters of this proposal to agree on
a suitable "warning label" that could be slotted into the Security section
of future proposals to inform implementers of the risks of specifying IIDs
based on globally unique hardware identifiers (which, I suspect, is what
the concern is).

Regards, Kerry Lynn

---

From: Fernando Gont <[email-masked]>
Date: Mon, 06 Jul 2015 13:26:00 -0300

Hi, Tim,

> This would seem the best wording to me. Adding the MAY is both redundant, and reads poorly. Imagine if every RFC did this.

Point taken. Should we do also apply the s/RECOMMENDED/SHOULD NOT"
substitution suggested by Mark?

i.e.,

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 06 Jul 2015 13:50:21 -0300

Hi, Kerry,

On 07/06/2015 01:26 PM, Kerry Lynn wrote:
> As the lead author of
> https://tools.ietf.org/html/draft-ietf-6man-6lobac, I'm
> assigned link-layer addresses, particularly for link-local addresses. 

FWIW, this has never been under question. That is, the question is
regarding the wording, not about the intent. Based on past wg discussion
and consensus, we all agree that there must be room to go against this
advice if design/engineering tradeoffs warrant this.

> in the following sentence makes it clear that the recommendation is

Well... a "SHOULD NOT" is a "SHOULD NOT". IF somene can read a "SHOULD
NOT" as a "MUST NOT", then we should refer them to RFC2119. I think the
issue that MARK raises is more tricky, since the MAY itself might lead
to some confusion.

Thanks!

Best regards,

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 6 Jul 2015 13:16:18 -0400

On Mon, Jul 6, 2015 at 12:50 PM, Fernando Gont <[email-masked]>
wrote:

> I'm afraid I was a few emails behind in the thread.  I agree that Mark's
proposed

is clearer, although it remains silent on when it is permissible to specify
such
schemes (and perhaps intentionally so).

Cheers, Kerry

 Thanks!

---

From: Christian Huitema <[email-masked]>
Date: Mon, 6 Jul 2015 21:15:07 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of Kerry Lynn
Sent: Monday, July 6, 2015 10:16 AM
To: Fernando Gont
Cc: [email-masked]; Dave Thaler; Ralph Droms; [email-masked]
> advice if design/engineering tradeoffs warrant this.

Part of the problem is that "link layer address," as a category, is no well-defined.

I would prefer something stronger, like 
" Future specifications SHOULD NOT specify IPv6 address generation
   schemes that embed the underlying link-layer address in the IID.
   In some cases, where engineering constants dictate, identifiers
   MAY include a short dynamically assigned link-layer address.
   Notwithstanding that, specification MUST NOT embed a globally unique 
   identifier such as an IEEE802 address or a E.164 phone number."

The rationale is clear. Globally unique identifiers enable all kinds of evil, including tracking of devices over time and at different locations. Dynamically assigned identifiers are a lesser kind of evil. Their main issue is that they facilitate network enumeration.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Mon, 06 Jul 2015 18:53:20 -0300

Hi, Christian,

On 07/06/2015 06:15 PM, Christian Huitema wrote:
> Sent: Monday, July 6, 2015 10:16 AM To: Fernando Gont Cc:
> [email-masked]; Dave Thaler; Ralph Droms;
> [email-masked]
>>> As the lead author of 
>>> https://tools.ietf.org/html/draft-ietf-6man-6lobac, I'm strongly
>>> in favor of retaining the option to specify IIDs based on
>>> locally assigned link-layer addresses, particularly for
>>> link-local addresses.
>> 
>> regarding the wording, not about the intent. Based on past wg
>> discussion and consensus, we all agree that there must be room to
>> go against this advice if design/engineering tradeoffs warrant
>> this.
> 
> I would prefer something stronger, like " Future specifications
> SHOULD NOT specify IPv6 address generation schemes that embed the
> underlying link-layer address in the IID. In some cases, where
> engineering constants dictate, identifiers MAY include a short
> dynamically assigned link-layer address. Notwithstanding that,
> specification MUST NOT embed a globally unique identifier such as an
> IEEE802 address or a E.164 phone number."

Two comments:

1) Getting into the underlying details can be tricky: short and
temporary identifiers might be "good enough" wrt host-tracking, but
certinaly not god when it comes to network reconnaissance. So I'd keep
things the discussion as is.. otherwise one would need to get into a
discussion ov every sort of identifier that might be employed in the
future... and we might even fail to envision them.

2) I'm myself in the camp of "MUST NOT use IEEE802 addresses or the
like"... but given that the requirements in this document have been kind
of wordsmithed among a number of groups and people, the more we tweak
the text, the more ths might take forever. I'd say that the current text
(if anything, modulo some minor edits) is good enough...

Just my 2 cents.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 06 Jul 2015 20:39:03 -0300

>   considerations warrant( example: constrained nodes networks)"

The point is that the "MAY" can lead to confussion... at the end of the
day, the RECOMMENDED/SHOULD_NOT that yu can go against the advice if you
have a valid reason to do so....

Thanks!

Cheers,

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 6 Jul 2015 17:24:09 -0700

I’m happy with how this is in the -05:

"Future specifications SHOULD NOT specify IPv6 address generation
   schemes that embed the underlying link-layer address in the IID.”

Exceptions to this recommendation will need to be justified on a case-by-case in any event, so the second sentence that was there before was superfluous.

Alissa

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 7 Jul 2015 00:50:42 +0000

Hi Fernanado:

After watching the discussions, I see that folks preferred to have some wiggle room to move when it is ' SHOULD NOT'.

For 6lo WG:

draft-ietf-6man-default-iids-05: states: (section 3)

By default, nodes SHOULD NOT employ IPv6 address generation schemes
   that embed the underlying link-layer address in the IID.  In
   particular, this document RECOMMENDS that nodes do not generate IIDs
   with the schemes specified in [RFC2464], [RFC2467], [RFC2470],
   [RFC2491], [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572],
   [RFC4338], [RFC4391], [RFC4944], [RFC5121], and [RFC5072], and
   updates these documents with this recommendation.

And

Future specifications SHOULD NOT specify IPv6 address generation
   schemes that embed the underlying link-layer address in the IID.

--------------------------------------------
This means that exceptions to this recommendation will need to be justified on a case-by-case.

I had another alternative suggestion, that might be clearer when the exceptions are justified.  

"Future specifications SHOULD NOT specify IPv6 address generation
   schemes that embed the underlying link-layer address in the IID except when design, engineering considerations, deployment warrant it.”

----

If folks are OKAY with the  05 wordings, then we can close the chapter.
 
If folks like some explanation for exemption then please speak up.

-Samita

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 4:39 PM
To: Samita Chakrabarti; Ralph Droms; Dave Thaler; Alissa Cooper; Will Liu (Shucheng)
Cc: Mark Smith; Mark ZZZ Smith; [email-masked]; [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-04.txt

>   considerations warrant( example: constrained nodes networks)"

The point is that the "MAY" can lead to confussion... at the end of the day, the RECOMMENDED/SHOULD_NOT that yu can go against the advice if you have a valid reason to do so....

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 06 Jul 2015 22:09:38 -0300

Hi, Samita,

On 07/06/2015 09:50 PM, Samita Chakrabarti wrote:
> 
> After watching the discussions, I see that folks preferred to have
> some wiggle room to move when it is ' SHOULD NOT'.
> 
> For 6lo WG:
> 
> -------------------------------------------- This means that
> exceptions to this recommendation will need to be justified on a
> case-by-case.
> 
> 
> 
> schemes that embed the underlying link-layer address in the IID
> except when design, engineering considerations, deployment warrant
> it.”

IMHO such a statement is so abstract that, at the end of the day, it
will not add much. (For instance, one would expect that if you decide to
go against a "SHOULD NOT", it's because you have some engineering
consideration in mind... Besides, "engineering cosideration" is kind of
vague that even something like "I had code for the traditional SLAAC
IIDs, but not for stable-privacy" would probably qualify as an
"engineering consideration".. so I think the current text is fine).

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 07 Jul 2015 00:13:12 -0300

Hola, Gabriel!

On 07/06/2015 10:06 PM, Gabriel Montenegro wrote:
>> The point is that the "MAY" can lead to confussion... at the end of
>> the day, the RECOMMENDED/SHOULD_NOT that yu can go against the
>> advice if you have a valid reason to do so....
> 
> I agree that the SHOULD NOT leaves enough wiggle room to depart if
> needed/warranted and +1 on s/RECOMMENDED/SHOULD NOT/

Thanks!

> I also think that this will do *very* little to improve the observed
> situation with respect to BTLE that prompts this change.

FWIW, is just one possible user. But what actually prompted this I-D was
the traditional SLAAC addresses that embed the underlying link-layer
address.

[....]
> 
> At any rate, I'm fine with the SHOULD NOT and s/RECOMMENDED/SHOULD
> NOT/
> 

Thanks!

Cheers,

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 7 Jul 2015 01:06:48 +0000

> The point is that the "MAY" can lead to confussion... at the end of the day,
> the RECOMMENDED/SHOULD_NOT that yu can go against the advice if you

I agree that the SHOULD NOT leaves enough wiggle room to depart if needed/warranted and +1 on s/RECOMMENDED/SHOULD NOT/

I also think that this will do *very* little to improve the observed situation with respect to BTLE that prompts this change. The point is that most of the devices being observed in the wild do not implement the IETF 6lo WG's BTLE draft (or "not yet", as one can always be optimistic). 
	
Bluetooth 4.2 has some privacy-enhancing mechanisms:
http://blog.bluetooth.com/bluetooth-technology-protecting-your-privacy/ 

But manufacturers are either not using them or not using them properly, so it is known that the situation could be improved:
http://www.contextis.com/resources/blog/emergence-bluetooth-low-energy/

If they were to implement them correctly, using frequently changing MAC addresses (as in the Bluetooth 4.2 spec) to generate IIDs would not be as serious, but the point is that now very few devices ever generate an IID at all, as they don't use IPv6 yet. 

At any rate, I'm fine with the SHOULD NOT and s/RECOMMENDED/SHOULD NOT/

---

From: Mark Smith <[email-masked]>
Date: Tue, 7 Jul 2015 14:22:25 +1000

Hi,

> the traditional SLAAC addresses that embed the underlying link-layer

Just to clarify a bit further, my use of the BTLE examples in the
context of this ID has been more to show that with technologies such
as BTLE, link-layer addresses are going to be far more widely exposed
and therefore more easily collected (as simple as installing an app on
your phone, no unlocking/root level access or interface promiscuous
mode required, and then just walking around the supermarket/sports
event/etc.), meaning that there might be more significant consequences
of using link-layer addresses as IPv6 IIDs than in the past.

Regards,
Mark.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 07 Jul 2015 08:35:00 -0400

> schemes that embed the underlying link-layer address in the IID.”

I agree that dropping the second sentence with the MAY was good.

> 
> Exceptions to this recommendation will need to be justified on a
> case-by-case in any event, so the second sentence that was there
> before was superfluous.

Many times, reviewers/readers have asked why documents have not provided
known exceptions to SHOULD (or SHOULD NOT) conditions.  I think it is
useful to at least mention (informatively) the ones we know about today.

Regards,
Brian

---

From: Ralph Droms <[email-masked]>
Date: Tue, 7 Jul 2015 08:45:06 -0400

> On Jul 7, 2015, at 8:35 AM, Brian Haberman <[email-masked]> wrote:
> 
> 
> 

I agree with both of Brian's points.  The "MAY" was unnecessary and potentially confusing..,

I think we don't include informative exception advice often enough in conjunction with recommendation language.

So, I support the formulation with the informative exception language.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 7 Jul 2015 15:10:16 -0400

> On Jul 6, 2015, at 9:09 PM 7/6/15, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Samita,
> 

In my opinion, the explanation of when the "SHOULD NOT" branch can be followed is important and should be included in the document.  Any spec that does embed a link-layer address will be subject to IETF review and consensus on whether that design is appropriate.  I think we don't include informative exception advice often enough in conjunction with recommendation language. 

- Ralph

---

From: Philip Homburg <[email-masked]>
Date: Wed, 08 Jul 2015 13:26:04 +0200

>(if anything, modulo some minor edits) is good enough...

Let me first say that for personal mobile devices, avoiding tracking using
meta data is very important. So for those devices the recommendations 
in this draft are a good step forward.

However, there is a large class of devices that are not mobile and for those,
following this approach just leads to operational issues.

The motivation for non-mobile devices seems to be some kind of security by
obscurity: by hiding the mac address of the device and by making it hard to
enumerate devices on a lan you make it a bit harder for an attacker.
However, this little bit of extra security is not balanced against extra
operational costs.

Currently, IPv6 devices that use SLAAC with EUI-64 have stable and predictable 
IPv6 address. Stable across different operating systems, stable across 
different operating system versions, re-installs, etc. With EUI-64 based IIDs,
you only need to know the mac address, which is printed on the outside of most
embedded devices to be able to compute its IPv6 address.

For the proposed randomization schemes, it is very unlikely that different
operating systems on a dual boot machine will agree to a single IID. A
re-install is likely to result in a new IID. Firmware upgrades on embedded
devices may lead to new IIDs.

Even if the IID remains stable on an embedded device, how does the 
embedded device inform the user about its IID?

As long as EUI-64 based IIDs are defined for a link layer technology, it is
easy enough for a vendor to just default to them, overriding a SHOULD. If
the scheme is not defined for a link technology, then it may cause all kinds
of operation headaches.

So my preference would be to focus this technology on personal mobile 
devices where privacy is a primary requirement and allow EUI-64 for stationary
devices where privacy is not a concern. Giving admins the option to use
randomized IIDs to make enumeration or reconnaissance harder is good as long
as it doesn't lead to operational problems (this will probably depend on
the device class).

Finally, if this draft would be widely implemented on non-mobile devices
then the best way forward in many networks would be do just disable SLAAC
and use DHCPv6.

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 8 Jul 2015 19:44:07 +0000

> will not add much. (For instance, one would expect that if you decide 
> to go against a "SHOULD NOT", it's because you have some engineering 
> consideration in mind... Besides, "engineering cosideration" is kind 
> of vague that even something like "I had code for the traditional 
> SLAAC IIDs, but not for stable-privacy" would probably qualify as an 

- Ralph

SC>  I  agree with Ralph.  Some explanation or examples should follow when "SHOULD NOT"  should be followed.

Thanks,
-Samita

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Jul 2015 08:27:57 +1200

> enumerate devices on a lan you make it a bit harder for an attacker.

You don't think that privacy and surveillance-resistance apply to fixed
devices?

> embedded devices to be able to compute its IPv6 address.

What is the value of that stability?

The traditional answer (which I've given myself in the past) is asset
management and traceability. But that's going to be increasingly fluid in
any case, with randomized MAC addresses coming along. It's also a lost cause
in enterprise networks that allow BYOD. Using MAC addresses as some kind
of pseudo-authenticated device ID is surely going the way of the dinosaurs.
If a network wants to positively identify and authenticate devices,
that needs to be done with a cryptographic technology.

> devices may lead to new IIDs.

So what?

> embedded device inform the user about its IID?

Why does the user care?

> the scheme is not defined for a link technology, then it may cause all kinds

It will cause a change of habits that have grown up since about 1983. I'm
not convinced it will cause any real headaches.

> then the best way forward in many networks would be do just disable SLAAC

That doesn't change the recommendation to use pseudo-random IIDs.

    Brian

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 8 Jul 2015 14:27:41 -0700

On Wed, Jul 8, 2015 at 12:44 PM, Samita Chakrabarti <
[email-masked]> wrote:
> In my opinion, the explanation of when the "SHOULD NOT" branch can be
> followed is important and should be included in the document.  Any spec
> that does embed a link-layer address will be subject to IETF review and
> consensus on whether that design is appropriate.  I think we don't include
> informative exception advice often enough in conjunction with
> recommendation language.
>
> - Ralph
>
>

I agree that this draft can do more to describe when the SHOULD NOT branch
can be followed.  But I also understand that having this draft say
something concrete is a bit difficult, especially when the constraints of
future link layers are unknown.  Does it make sense for this draft to also
indicate that future IPv6-over-foo specifications MUST provide an
explanation for following the "SHOULD NOT" branch if they choose to do so?

--
Jonathan Hui

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 9 Jul 2015 02:44:35 +0000

Hi Johnathan,

I agree that this draft can do more to describe when the SHOULD NOT branch can be followed.  But I also understand that having this draft say something concrete is a bit difficult, especially when the constraints of future link layers are unknown.  Does it make sense for this draft to also indicate that future IPv6-over-foo specifications MUST provide an explanation for following the "SHOULD NOT" branch if they choose to do so?

--
[SC>]  This is one way of looking at it. I am okay with it. I believe the recommendation is not only true for ipv6-over-foo specifications but for other  IPv6 devices as well (raspberry Pi, wireless phones, cameras etc..).

-Samita

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Jul 2015 16:29:41 +1000

On 9 July 2015 at 12:44, Samita Chakrabarti
<[email-masked]> wrote:
> can be followed.  But I also understand that having this draft say something
> concrete is a bit difficult, especially when the constraints of future link
> layers are unknown.  Does it make sense for this draft to also indicate that
> future IPv6-over-foo specifications MUST provide an explanation for
> following the "SHOULD NOT" branch if they choose to do so?
>

I think that would be a very good idea. Having to write up a
justification would either ensure it has been properly thought about,
or should make it easy for a qualified reviewer to spot that it
hasn't.

As using link-layer addresses as IIDs is mostly reducing privacy if
the link-layer addresses are globally unique, a reference to RFC6973,
"Privacy Considerations for Internet Protocols" in this ID would
probably help somebody with considering and developing this
justification.

Regards,
Mark.

>
>
> --
>
> [SC>]  This is one way of looking at it. I am okay with it. I believe the
> recommendation is not only true for ipv6-over-foo specifications but for
> other  IPv6 devices as well (raspberry Pi, wireless phones, cameras etc..).
>
>
>
> -Samita

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Jul 2015 17:50:29 +1000

> that needs to be done with a cryptographic technology.

So I think it a lot of cases, what people are really trying to do is
to identify the person behind the device for security reasons, rather
than the device itself. The device is the identifiable tool used for
the attack, but it is the person that has the intent and is the
attacker.

I don't think device identifiers/addresses are very good analogues for
people identifiers, because people can and do have many of them, and
they can be quite easily changed - not only by e.g., randomising MAC
addresses, but also, as an attacker, by using a different device that
isn't associated with your identity. You'd use somebody else's desktop
they've left unlocked while they go to lunch, or steal somebody else's
portable laptop/mobile phone. If you have malicious intent, you would
have no guilt about making somebody else look responsible by using the
devices associated with them - in fact you'd actually welcome it.

To overcome a lot of these limitations, I think people really need to
implement "person authentication" systems for access to their
networks, meaning systems that identify the person behind the device,
using attributes of the person themselves,  meaning a combination of
the "what you are, what you know, what you have" attributes. 802.1X
would be such a system. They're not going to be perfect, but they'll
be a lot better than making what would be a completely false yet
security critical assumption that the same person is always using the
same device, and therefore the device's globally unique identifiers
(which may not actually be unique) always uniquely identify one
individual.

Once you've identified/authenticated the specific individual, you can
and will then have a much tighter coupling between that person and the
device identifiers they're using during that authenticated session.

<snip>
>> then the best way forward in many networks would be do just disable SLAAC

Disabling SLAAC and using DHCPv6 doesn't prevent an attacker from
configuring a valid static address on their device from within the
link's /64(s), conveniently announced by RAs, or determinable by
capturing traffic, and that static address won't be recorded in the
DHCPv6 stateful address database.

ND/MLD messages from the attacker's device would be way of identifying
that an attacker that has avoided being recorded in the DHCPv6
database. But even they can be avoided - if the attackers goal is an
IPv6 traffic denial of service attack on another on-link neighbor,
then they can disable all of that, and create a static ND cache entry
for their victim. Or then can just send huge volumes of crafted
packets at them, because they have complete control of the device
they're using for the attack.

On the other hand, if you can prevent them from accessing your network
unless they've proven their (personal) identity, then you've avoided a
lot of the threats that unauthenticated network users create, rather
than just assuming and relying on arbitrary device identifiers being
accurate and absolute individual people identifiers.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 Jul 2015 11:49:02 +0200

>You don't think that privacy and surveillance-resistance apply to fixed

I don't know what kind of privacy my mail server needs. If I leave it alone
it will deliver mail. Some other kind of privacy?

No, I have absolutely no idea how to apply the concept of 'privacy' to my fixed
devices. Privacy may apply to outgoing connections, but that is better served
by privacy extensions than by having a randomized fixed address.

I think it is perfectly fine if operators want to implement security by
obscurity (what you call surveillance-resistance). In practice this is 
stuff that firewalls already take care of. 

What I object to is essentially making it mandatory or making life harder for
people who don't want this feature.

>that needs to be done with a cryptographic technology.

I don't know about your network, but IP addresses very often end up in DNS
and in firewall rules. This will typically lead to breakage, certainly if
we are talking about dual-stack devices where IPv4 continues working.

Depening on how the network is set up, it is quite possible to keep BYODs
on separate networks that require extra steps, like a VPN, to connect to
internal servers. So traceability of fixed devices can be separated from
peoples personal devices.

>> devices may lead to new IIDs.

As discussed, changes in DNS, firewalls, etc.

>> embedded device inform the user about its IID?

It is rather hard to connect to a device if you don't know its IP address.

IPv6 with EUI-64 is a big step forward compared to dynamic DHCPv4, pity it
has to get killed in the name of universal privacy.

>not convinced it will cause any real headaches.

This is what works today. It is one of the few improvements of IPv6 over
IPv4.

>That doesn't change the recommendation to use pseudo-random IIDs.

With DHCPv6, the IID will only show up in the link local address. For
communicating with hosts, the link local address is almost never needed.

So my preference: allow IIDs based on link layer address for all link layer
technologies. For personal mobile devices, the device SHOULD (maybe even MUST)
default to randomized addresses. For stationary devices, the device MAY
default to one or the other.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Jul 2015 08:45:14 +1200

Hi Philip,

> it will deliver mail. Some other kind of privacy?

This dialogue is mainly addressing systems used by individuals, I think;
static IIDs for servers that are in any case visible to the world seem
quite reasonable and should be exempt, I think.

> people who don't want this feature.

Certainly there's a tussle here between operators (in the most general sense
of the word) and individual users. Privacy is for users.

> we are talking about dual-stack devices where IPv4 continues working.

DNS needs to be set up automatically, for hosts that actually need a DNS name.
Firewall rules for individual end user systems are pretty rare, aren't they?
(Again, servers are a different issue.)

> peoples personal devices.

Having separate arrangements for BYOD is a very expensive approach. I am
more thinking of the thousands of end-user devices in a large enterprise
or university network (again, not of the relatively small number of
servers).

> It is rather hard to connect to a device if you don't know its IP address.

Yes, but why does the *human* care? DNS cares, but that should just work
dynamically.

> With DHCPv6, the IID will only show up in the link local address. 

Not quite - that part of the address is set by DHCPv6, but it can remain
opaque and pseudorandom.

   Brian

> For

---

From: Philip Homburg <[email-masked]>
Date: Fri, 10 Jul 2015 11:32:19 +0200

>quite reasonable and should be exempt, I think.

If the draft can be explict about this, then it's fine with me.
I.e. "This document specifies IIDs selection and addressing for systems
used by individuals".

I would note here that if a mobile system uses randomized link layer addresses
then tying the IPv6 address to the link layer address would make perfect
sense because it also prevents correlation attacks where the link layer
address changes but old IPv6 addresses are still used.

I'm curious how randomized link layer addresses interact with RFC 7217. At
first reading it seems that RFC 7217 would defeat randomized link layer
addresses.

>Not quite - that part of the address is set by DHCPv6, but it can remain

The big difference is that in general device vendors control IID selection
whereas DHCPv6 policy is set by operators.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 10 Jul 2015 10:19:49 -0400

Hi Brian,

> that needs to be done with a cryptographic technology.

How do you see RFC 7217 playing into the above? One of the arguments for
that draft was that network security folks wanted stable, but not
EUI-64-based, IPv6 addresses for things like ACLs. Randomizing MAC
addresses, and then re-generating the corresponding IPv6 addresses,
seems to take us back to the RFC 4941 state-of-the-art.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Jul 2015 14:04:17 -0300

> So, I support the formulation with the informative exception language.

Would it be sensible to raise this during WGLC?

P.S.: And if you guys (6lo) could come up with a small sentence
paragraph for this, that'd be great. (That would probably be a better
starting point than if I craft such sentence myself).

Thanks!

Best regards,

---

From: Christian Huitema <[email-masked]>
Date: Fri, 10 Jul 2015 17:25:23 +0000

On Friday, July 10, 2015, 2:32 AM, Philip Homburg wrote:
> ...
> 
> I'm curious how randomized link layer addresses interact with RFC 7217. At first
> reading it seems that RFC 7217 would defeat randomized link layer addresses.

You may want to check https://datatracker.ietf.org/doc/draft-huitema-6man-random-addresses/.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Jul 2015 15:14:47 -0300

On 07/08/2015 08:26 AM, Philip Homburg wrote:
> meta data is very important. 

Its not just tracking. Please see draft-ietf-6man-address-generation-privacy

> However, this little bit of extra security is not balanced against extra

This is incorrect. That's why we've produced RFC7217.

And when it comes to operational costs, I should note that if your
network runs Windows, you've not been using link-layer address-based
IIDs for quite a few years now.

> embedded devices to be able to compute its IPv6 address.

Sticking to this becase "many vendors print the MAC address in the box"
seems like an extremely poor reason for backing this behavior.

> operating systems on a dual boot machine will agree to a single IID.

Does people still do dual boot? -- That said, you could consider
different OSes receiving a different IID could be considered a feature.

> embedded device inform the user about its IID?

Why should the user care?

> devices where privacy is not a concern.

If anything, privacy should be an opt out, not an "opt in".

> Giving admins the option to use

RFC7217 was designed with this goal in mind.

> then the best way forward in many networks would be do just disable SLAAC

This is orthogonal. Besides, you might be aware that DHCPv6 is OPTIONAL
not only spec-wise but in practice: i.e., not everyone supports DHCPv6.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Jul 2015 08:40:52 +1200

> seems to take us back to the RFC 4941 state-of-the-art.

It's a dilemma. As far as I can see, there's a real difference between
end-user systems (even within an enterprise network), where privacy arguments
might dominate, and servers, where stability and ACL arguments might dominate.
I'm thinking that for privacy-sensitive systems, we'll have to use a firewall
penetration solution rather than ACLs.

   Bria

---

From: Christian Huitema <[email-masked]>
Date: Sat, 11 Jul 2015 04:13:05 +0000

On Friday, July 10, 2015 1:41 PM, Brian E Carpenter wrote:

>> How do you see RFC 7217 playing into the above? One of the arguments 
>> for that draft was that network security folks wanted stable, but not 
> It's a dilemma. As far as I can see, there's a real difference between end-user systems (even 
> within an enterprise network), where privacy arguments might dominate, and servers, where 
> stability and ACL arguments might dominate. I'm thinking that for privacy-sensitive systems, 
> we'll have to use a firewall penetration solution rather than ACLs.

I think we need to educate the enterprise IT managers. Right now, they consider only one facet of the problem, the need to manage a variety of devices. So they make sure that devices have stables addresses, because using these as stable identifiers is very convenient. But then, by doing that, they also facilitate tracking of these device's traffic outside the enterprise, which is the other facet of the problem.  And I am afraid that IT managers are not taking that second facet in consideration.

One possibility is to have devices with different behaviors "inside" and "outside." For example, use a stable MAC address at the office, and a random one on the road. That solves some of the problem, but the stable addresses can still be tracked if the user does TCP connections "from the inside to the outside."

-- Christian Huitema

---

From: Mark Smith <[email-masked]>
Date: Sat, 11 Jul 2015 16:00:26 +1000

> One possibility is to have devices with different behaviors "inside" and "outside." For example, use a stable MAC address at the office, and a random one on the road. That solves some of the proble…

I think Multipath TCP would make this a much harder problem when using
mobile multihomed hosts e.g., smartphones. Application MPTCP
connections can survive crossing from "inside" to "outside" and
vice-versa.

A stable "Inside" identifier can be correlated with random "outside"
identifiers either via concurrent MPTCP subflows that use the same 32
bit MPTCP token, across different networks, or when the host's
addresses are announced to the MPTCP peer via MPTCP optons, even if
the "inside" address/identifier isn't reachable by the MPTCP peer.

Using global MAC addresses as asset numbers won't be a reliable as it
used to be, as they're not as globally unique as they would have been
in the past. Based on some research HD Moore did a couple of years
ago, there are more 6 million instances of one "globally unique" MAC
address, and 4 other instances where a "globally unique" MAC address
has been duplicated more and many more than 100 000 times. Summary of
the top 10 occurrences here:

https://www.ietf.org/mail-archive/web/ipv6/current/msg17109.html

It would be more reliable for enterprises to be assigning their own
device asset numbers/identifiers rather than relying on manufacturer
assigned ones. I think it would be best that these asset
numbers/identifiers are at a layer above IP, so that if IP addresses
or MAC addresses change or aren't unique for any reason, the
identity/asset number of the device doesn't change.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Jul 2015 08:22:44 +1200

On 11/07/2015 18:00, Mark Smith wrote:

<snip>

> identity/asset number of the device doesn't change.

Yes, but then you are talking about cryptographically authenticated
device IDs, I think, which is a whole other topic. And the question
whether it's vendor-based or enterprise-based is quite debatable.
(e.g. draft-pritikin-anima-bootstrapping-keyinfra)

Off-topic for 6man, I think.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 12 Jul 2015 13:49:49 +1000

> Off-topic for 6man, I think.

Agree.

If people agree that doing reliable asset tracking is a problem better
or best solved at a higher layer than IP, then I think means we don't
need to consider or put much weight on the use case of asset tracking
when making statements on the values of IPv6 IIDs.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 Jul 2015 17:29:16 +0200

In your letter dated Fri, 10 Jul 2015 17:25:23 +0000 you wrote:
>You may want to check https://datatracker.ietf.org/doc/draft-huitema-6man-r=
>andom-addresses/.

I think that your draft should become a bit more explicit in its
recommendations. I.e. if you want to use a randomized link address
adresses, how to manage that address. And how to manage Ipv6 addresses. In
particular, make explicit how to manage the valid/preferred timers.

Now it is sort of a discussion of various alternatives without clearly
specifying a course of action. 

One thing that is very risky, is updating RFC-7217 almost in a footnote. 

In anycase, this text should be part of draft-ietf-6man-default-iids, either
by reference or by moving the discussing into draft-ietf-6man-default-iids
itself.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 Jul 2015 18:12:33 +0200

>Its not just tracking. Please see draft-ietf-6man-address-generation-privacy

This was a statement that I consider tracking very important. I don't care
at all about the security by obscurity that was added to
draft-ietf-6man-address-generation-privacy

Then there is Section 3.1, which also applies to RFC-7217. So I'll ignore
that.

>This is incorrect. That's why we've produced RFC7217.

What is incorrect? non-mobile devices obviously do not suffer from location
tracking. RFC-7217 doesn't solve Section 3.1 of
draft-ietf-6man-address-generation-privacy. Which leaves the
security by obscurity sections 3.3 and 3.4

>IIDs for quite a few years now.

I try to stay away from Windows. In particular I don't have Windows servers.
So what Windows does or doesn't do is not relevant to me.

>> With EUI-64 based IID
>s,

This is operationally very convenient. There is a reason vendors print those
numbers on the outside of a device.

MAC addresses are also in many asset databases, you need them for wake-on-lan.
In other words, it saves having to track yet another piece of information.
Worse a piece of information that locally generated on the device.

>different OSes receiving a different IID could be considered a feature.

It is not a feauture if that behavior is mandated by the IEFT. Depending on
the context, it may be quite painful if you have to manually fix up 
features like that.

>Why should the user care?

Because some devices don't have any user interface beyond maybe reset button.
So it is very annoying if the device has to pick a randomized IPv6 address
and has no way of informing the user of the address.

Of course, we can start mandating all kinds of higher level protocols. Just
to make life harder.

>If anything, privacy should be an opt out, not an "opt in".

My mail server doesn't need privacy. And concept of 'opting out' for a 
public server is silly.

Privacy is good for personal mobile devices. For servers in a fixed location
it is just silly.

>not only spec-wise but in practice: i.e., not everyone supports DHCPv6.

If SLAAC becomes intentionally broken for servers and embedded devices then
DHCPv6 will quickly become non-optional in practice.

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 13 Jul 2015 15:21:07 -0700

> In my opinion, the explanation of when the "SHOULD NOT" branch can be followed is important and should be included in the document.  Any spec that does embed a link-layer address will be subject to…

I think part of the reason we are going round and round on this is because we haven’t drilled down on what the exception criteria should actually be. I agree that “engineering considerations” is an exception that swallow the rule. I’m prepared to get tomatoes thrown at me for saying this, but as far as future specifications go, the main exception case I’ve seen put forward is the same one that is already discussed elsewhere in the document: header compression for low power devices. So can we frame the exception criteria along those lines? E.g.,

"Future specifications SHOULD NOT specify IPv6 address generation schemes that embed the underlying link-layer address in the IID. In some cases, embedding the link-layer address in the IID may yield energy savings by facilitating header compression in low power devices. In such cases, future specifications MAY include address generation schemes that embed the link-layer address in the IID, but MUST also specify an alternative address generation scheme.”

Personally I would prefer the formulation Christian put forth (reproduced below), but I assume that is not going to fly for the 6lo folks given that there’s no way to guarantee that the link layer address has been dynamically assigned and low power devices will want to make use of IID-based header compression nonetheless.

>   identifier such as an IEEE802 address or a E.164 phone number.”

Alissa

---

From: Ralph Droms <[email-masked]>
Date: Tue, 14 Jul 2015 13:51:52 -0400

(trimming CC: line)

> On Jul 13, 2015, at 6:21 PM 7/13/15, Alissa Cooper <[email-masked]> wrote:
> 
> 
>>>> 

I don't think we can restrict the exception criteria to energy savings.  For example, I think bandwidth utilization and MTU considerations have both been considered as valid engineering criteria that apply to devices that are not energy-constrained.

Christian's text assumes the existence of "a short dynamically assigned link-layer address", which may not apply to all such devices.

Perhaps a more acceptable formulation using several examples might be acceptable:

"Future specifications SHOULD NOT specify IPv6 address generation schemes that embed the underlying link-layer address in the IID. In some cases, embedding the link-layer address in the IID may reduce resource requirements such as energy, bandwidth and packet transmission by facilitating header compression in constrained devices. In such cases, future specifications MAY include address generation schemes that embed the link-layer address in the IID, but MUST also specify an alternative address generation scheme.”

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 14 Jul 2015 18:34:39 +0000

Hi Ralph, Alissa and Christian:

Thanks for  the attempt to wordsmith the exemption criteria. The following looks fine to me.

---------------------

"Future specifications SHOULD NOT specify IPv6 address generation schemes that embed the underlying link-layer address in the IID. In some cases, embedding the link-layer address in the IID may reduce resource requirements such as energy, bandwidth and packet transmission by facilitating header compression in constrained devices. In such cases, future specifications MAY include address generation schemes that embed the link-layer address in the IID, but MUST also specify an alternative address generation scheme."
 -----
-Samita

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 14 Jul 2015 11:55:31 -0700

I support the proposed text below.

One nit in the text: "such as energy, bandwidth and packet transmission by
facilitating"

Not sure what resource "packet transmission" refers to.  Maybe you meant to
say "packet transmission time".

On Tue, Jul 14, 2015 at 10:51 AM, Ralph Droms <[email-masked]> wrote:

> "Future specifications SHOULD NOT specify IPv6 address generation schemes
> that embed the underlying link-layer address in the IID. In some cases,
> embedding the link-layer address in the IID may reduce resource
> requirements such as energy, bandwidth and packet transmission by
> facilitating header compression in constrained devices. In such cases,
> future specifications MAY include address generation schemes that embed the
> link-layer address in the IID, but MUST also specify an alternative address
> generation scheme.”

--
Jonathan Hui

---

From: Christian Huitema <[email-masked]>
Date: Tue, 14 Jul 2015 19:24:47 +0000

> "Future specifications SHOULD NOT specify IPv6 address generation schemes that 
> embed the underlying link-layer address in the IID. In some cases, embedding the 
> link-layer address in the IID may reduce resource requirements such as energy, 
> bandwidth and packet transmission by facilitating header compression in constrained 
> devices. In such cases, future specifications MAY include address generation schemes 
> that embed the link-layer address in the IID, but MUST also specify an alternative 
> address generation scheme.”

That's too weak a restriction. It does not include the part about "MUST NOT embed a globally unique identifier," which is the core of the issue. 

I would rather go for:

"Future specifications SHOULD NOT specify IPv6 address generation schemes that 
embed the underlying link-layer address in the IID. There MAY be some exceptions
in cases where network technologies works under very restrictive constraints. 
These exceptions MUST be reviewed on a case by case basis. Specifications 
allowing address generation schemes that embed the link-layer address in the IID
under such exceptions MUST also specify an alternative address generation scheme.”

-- Christian Huitema

---

From: Ralph Droms <[email-masked]>
Date: Tue, 14 Jul 2015 16:05:32 -0400

> On Jul 14, 2015, at 2:55 PM 7/14/15, Jonathan Hui <[email-masked]> wrote:
> 
> One nit in the text: "such as energy, bandwidth and packet transmission by facilitating"
> 
> Not sure what resource "packet transmission" refers to.  Maybe you meant to say "packet transmission time".

Good question ... I meant "number of frames to carry a given IPv6 packet".

- Ralph

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 14 Jul 2015 16:19:59 -0400

On Tue, Jul 14, 2015 at 3:24 PM, Christian Huitema <[email-masked]>
wrote:

> schemes that
> That's too weak a restriction. It does not include the part about "MUST
> NOT embed a globally unique identifier," which is the core of the issue.
>
> I would rather go for:
>
> that
> I strongly disagree; I think Ralph's wording more closely reflects the
consensus
that has developed over several meetings now.  As I understand that
consensus,
the directive is SHOULD NOT embed L2 addresses in IIDs and MUST specify a
scheme by which privacy IIDs can be generated.  At that point, it seems to
be a
local matter whether privacy IIDs are configured or not.  The simplest IoT
devices
will probably not have a UI nor a good source of entropy, so injecting
secret keys
into these devices becomes an operational consideration.

I also do not agree that every new IP-over-6lo proposal should need to
repeat the
same arguments ("We'd really like to be able to use RFC 6282 compression"),
subject to the constitution of the IESG at the time.  Instead, I think it
would be
helpful for those who understand the issue best (the I-D authors and other
subject matter experts) to agree on language that could be included in
future
proposals as BCP to implementers.  Something like:

   A 64-bit privacy IID is RECOMMENDED for routable addresses and SHOULD
   be locally generated according to [I-D.ietf-6man-default-iids
<https://tools.ietf.org/html/draft-ietf-6lo-6lobac-02#ref-I-D.ietf-6man-default-iids>].
A
   node that generates a 64-bit privacy IID MUST register it with its
   local router(s) by sending a Neighbor Solicitation (NS) message with
   the Address Registration Option (ARO) and process Neighbor
   Advertisements (NA) according to [RFC6775
<https://tools.ietf.org/html/rfc6775>].

The acceptable alternatives (including managed opaque DHCPv6 addresses)
would
be spelled out in ID-ietf-6man-default-iids.  This statement would be
something like
the Surgeon General's warning that appears on every pack of cigs in the US;
we
can't stop you from smoking, but we want you to know it's a very bad idea.

Regards, Kerry Lynn

-- Christian Huitema

---

From: Mark Smith <[email-masked]>
Date: Fri, 17 Jul 2015 14:41:26 +1000

Hi,

<snip>
>    A 64-bit privacy IID is RECOMMENDED for routable addresses

I assume this means this wouldn't apply to link-local addresses? If
so, that is assuming that privacy violators are always off-link. I
don't think that is a correct assumption.

Here's a scenario. I'm in an Internet cafe, and somebody on the link
captures my link-local addresses, which include globally unique IIDs.
They then upload it to a global database that also records the GPS
location of where the link-local address is stored.

Later, I'm at a different Internet cafe, and somebody on the link
captures my link-local addresses, which include the same globally
unique IID as before. They then upload it to the same global database
that also records the GPS location of where the link-local address is
stored.

This global database now has a record of my movements, even though
link-local addresses and link-local traffic was limited to the
individual local link at each of the Internet cafes.

This sort of sniffing application and database already exists for
single link bluetooth addresses (http://www.earthping.com/), and it
wouldn't be hard to do the same thing for link-local addresses with
globally unique IIDs.

Reflecting on it, the first violations of network traffic privacy were
actually single link ones - via tcpdump and LAN technologies where all
hosts received all packets e.g. 10BASE2. It is global privacy
violations that are the newer risk.

Regards,
Mark.

> and SHOULD
>    be locally generated according to [I-D.ietf-6man-default-iids].  A
>    Advertisements (NA) according to [RFC6775].
>
>