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

From: [email-masked]
Date: Thu, 25 Jun 2015 22:35:54 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Recommendation on Stable IPv6 Interface Identifiers
        Authors         : Fernando Gont
                          Alissa Cooper
                          Dave Thaler
                          Will Liu
	Filename        : draft-ietf-6man-default-iids-04.txt
	Pages           : 9
	Date            : 2015-06-25

Abstract:
   The IPv6 addressing architecture defines Modified EUI-64 format
   Interface Identifiers, and the existing IPv6 over various link-layers
   specify how such identifiers are derived from the underlying link-
   layer address (e.g., an IEEE LAN MAC address) when employing IPv6
   Stateless Address Autoconfiguration (SLAAC).  The security and
   privacy implications of embedding link-layer addresses in the
   Interface Identifier have been known and understood for some time
   now, and some popular IPv6 implementations have already deviated from
   such schemes to mitigate these issues.  This document changes the
   recommended default Interface Identifier generation scheme for SLAAC
   to that specified in RFC7217, and recommends against embedding link-
   layer addresses in IPv6 Interface Identifiers.  It formally updates
   RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590,
   RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC4944, RFC5072, and
   RFC5121, which require IPv6 Interface Identifiers to be derived from
   the underlying link-layer address.  Additionally, this document
   provides advice about the generation of Interface Identifiers with
   other address configuration mechanisms, such as Dynamic Host
   Configuration Protocol version 6 (DHCPv6) and manual configuration.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-6man-default-iids-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 27 Jun 2015 03:16:35 +0000 (UTC)

Hi,
Thanks very much for incorporating the changes I suggested.
A further thought I've had is that I think it is probably necessary to say explicitly that the link-layer addresses should be changed periodically. While I'd like to think that it was implicitly obvious that these link-layer address should be changed periodically, I think when it comes to security it is better to be explicit. So, something like,
"Where IPv6 IIDs are to be derived from link-      layer addresses, it is RECOMMENDED that the random addresses      supported by the link-layer are used, or that pseudo-random locally      assigned link-layer addresses are generated, assigned and used.
These random link-layer addresses should be changed regularly, such as each time the link-layer interface is initialised. They SHOULD NOT be changed during a sequence of link-down/link-up events, as that will cause on-link neighbors' neighbor cache entries for this device to become invalid. These invalid neighbor cache entries could be corrected by sending Unsolicited Neighbor Advertisements [RFC4861], however the likely globally unique IPv6 addressing information in the Unsolicited NA would disclose the device's previous network and corresponding location when attaching to a different network."
Regards,Mark.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Jun 2015 18:58:52 -0300

Hi, Mark,

Thanks so much for your feedback! Comments in-line...

On 06/27/2015 12:16 AM, Mark ZZZ Smith wrote:
> A further thought I've had is that I think it is probably necessary to
> say explicitly that the link-layer addresses should be changed
> periodically. While I'd like to think that it was implicitly obvious
> that these link-layer address should be changed periodically, I think
> when it comes to security it is better to be explicit. 
[...]

To be honest, I wouldn't go this path. I'd say that what we currently
have in the I-D is fine, in the sense that we provide some hints (use
randomized MAC addresses) for folks that are going to base their IIDs on
the underlying lying layer address. But providing more details seems to
me like rather out of scope.. On one hand, because how/when they
randomize the MAC addresses seems more of layer-2 advice than IPv6
advice. On the other hand, because randomizing link-layer addresses is a
different animal. There are many details that one should think about,
and the implications/interactions are rather different (than in the case
of simply generating a stable, non-predictable, IID).

Thoughts?

Thanks!

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 30 Jun 2015 01:44:49 +0000

On  Monday, June 29, 2015 2:59 PM, Fernando Gont wrote
> To: Mark ZZZ Smith; [email-masked]
> Subject: Re: I-D Action: draft-ietf-6man-default-iids-04.txt
> 
> Hi, Mark,
> 
> ...
> To be honest, I wouldn't go this path. I'd say that what we currently have in the
> I-D is fine, in the sense that we provide some hints (use randomized MAC
> addresses) for folks that are going to base their IIDs on the underlying lying layer
> address. But providing more details seems to me like rather out of scope.. On
> one hand, because how/when they randomize the MAC addresses seems more
> of layer-2 advice than IPv6 advice. On the other hand, because randomizing
> link-layer addresses is a different animal. There are many details that one should
> think about, and the implications/interactions are rather different (than in the
> case of simply generating a stable, non-predictable, IID).

I sent that message to the authors already, but I can just as well repeat it for the 6man list. I would like to see a discussion of how MAC Address Randomization interacts with different classes of addresses. If the device uses a "temporary MAC address," then:

1) IEEE identifiers have the same life time as the temporary MAC addresses (good) but reveal the temporary MAC addresses outside the link (bad).

2) Static manual, constant opaque, and CGA enable device identification and negate the value of using temporary MAC addresses.

3) Stable semantically opaque address may or may not negate the value of using temporary MAC addresses, depending on whether the stable address construction takes as input the current MAC address or not. When randomizing the MAC address, we should ensure that the "stable" address changes each time the MAC address changes.

4) Temporary addresses may or may not negate the value of using temporary MAC addresses, depending whether or not the temporary address lifetime expires when the MAC address changes. If the temporary address lifetime overlaps the usage of two different MAC addresses, then it enables correlation.

5) When using DHCPv6 and randomized MAC address, hosts should be careful to use the DHCPv6 anonymity profile.

-- Christian Huitema

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Jun 2015 14:28:20 +1000

Hi Fernando,

On 30 June 2015 at 07:58, Fernando Gont <[email-masked]> wrote:
> advice.

So broadly I agree that layer 2 advice would seem to be out of scope,
and thought about that when I was writing the email, however I think
it becomes, in one way or another, in scope when the layer 2 address
is directly used as the IID value. Randomising the link-layer address
once gets rid of predictability due to OUIs, but if it is only done
once, or very rarely, then the link-layer address and the
corresponding IPv6 IID are still likely to become globally unique,
defeating privacy.

As a bit of background on my thinking on this, about 5 and a half
months ago I bought a number of Bluetooth LE fitness sensors to use
either while walking/exercising including while riding my bicycle, and
out of curiosity started looking a bit into how Bluetooth LE worked
and what sort of security it had, in part because of how exposed my
use of BLE devices and their addresses will be while in public spaces.

A few things I've come across or thought since:

o  "IPv6 over BLUETOOTH(R) Low Energy" -
https://tools.ietf.org/html/draft-ietf-6lo-btle-13

This draft generates Link-Local address IIDs using the bluetooth
link-layer address. The motivation seems to be the 6lowpan one - to
reduce the number of ND related packets. However, the draft then talks
about using non-link-layer IIDs for non-Link-Local addresses,
including specifically referencing this draft, and also talks about
triggering Router Solicitations etc. I'm not sure why the efficiency
of using link-layer addresses in IPv6 Link-Local address IIDs is
necessary or useful when it isn't for other types of IPv6 addresses.
However, if it is better to use link-layer addresses in IPv6
Link-Local addresses, then I'd like to see them randomised when they
are. That draft mentions that BLE link-layer addresses can either be
public or random, but doesn't take a position on which should be used.
The included text in this draft that I suggested before that has been
included states that random should be the position.

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

I came across the RaMBLE a few months ago, mentioned on Slashdot, so
it's existence would be widely known. It is a Bluetooth LE scanner,
which records both the public details of any BLE devices it encounters
and their GPS co-ordinates. It does not require rooting/unlocking the
device, so in other words, anybody can run it with stock firmware.
I've been running it while out walking or riding my bike, just to get
a basic idea of how many BLE devices are out there. There are far more
than I expected, at a guess I've easily recorded more than 100, and
that hasn't commonly been in highly crowded areas. I think it is
likely that this app is using the BLE link-layer address as the
globally unique BLE device identifier. The significance of the GPS
co-ordinates is that they've conveniently made it possible to select a
device and then display where RaMBLE recorded it using the Android
Maps application/plugin.

o  Bluetooth 4.1 (including BLE) link-layer addresses can be random,
however they are only generated at device power on

With BLE devices being both low powered and battery operated, it could
be many months before a new BLE device's link-layer address is
randomised again. I haven't changed the batteries in any of my BLE
fitness devices in the last 5 months, and they all wake-up by sensing
an external event, so they're constantly powered.

o  BLE payload encryption is optional

o  BLE encryption key exchange is weak, although the crypto algorithm is a good

"Black Hat USA 2013 - Bluetooth Smart: The Good, The Bad, The Ugly,
and The Fix!"
https://www.youtube.com/watch?v=A-kJ3AXp9cI

o  Embedding BLE link-layer addresses directly in IPv6 address IIDs
would be a useful crib for brute forcing when the BLE payload, which
would include the IPv6 header, is encrypted.

So given all of that, I think when link-layer addresses are directly
used as IPv6 IIDs, random link-layer address, and fairly regular
changing changing of them (i.e., more than just when the device is
powered up) are equally important.

Perhaps an alternative way to reduce the "out of scopeness" of the
most recent text I suggested would be to change following text

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

to something like:

"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 think "SHOULD NOT" is appropriate going by its description in RFC2119,

SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

>On the other hand, because randomizing link-layer addresses is a

So I'm sort of willing to take a narrower "IPv6 only" view when it
comes to security/privacy of IIDs, however I agree there can be wider
implications of changing link-layer addresses, possibly when running
multiple layer 3 protocols (I heard many years ago that DEC caused
some trouble on multiprotocol routers/networks when they changed
link-layer addresses to sue the operation of DECNET).

Regards,
Mark.

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jun 2015 03:28:30 -0300

Hi, Mark,

> corresponding IPv6 IID are still likely to become globally unique,

The thing here is that if we get into this sort of details,we will end
up with a document that is very different from what we have right now.
So far, this document simply recommends e.g. to do RFC7217 as the
default algorithm for IID generation with SLAAC. Generation of IIDsby
embedding the MAC address is kind of allowed only for corner cases --
which should have a justification for doing so.

Getting into the details of what to do if you decide to generate IIDs by
embedding the MAC address is essentially putting effort in how to do
something that we're recommending against. Besides I think that
temporary MAC addresses can have such a number of implications that, if
we're going to advice for the MAC addresses to be changed freqntly
(i.e., temporary MAC addresses) we shold be discussing underlying
details (e.g. what happends to long-lived TCP connections when you
change the MAC address) and that would be out of scope of this document.

> included states that random should be the position.

FWIW, "public" and "random" seem to be talking about different
properties (see our terminology section in the
address-generation-privacy I-D).

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

>    before implementing any behavior described with this label.

FWIW, RECOMMENDED == SHOULD, and NOT RECOMMENDED == SHOULD NOT. so they
are the same in the RFC21119 sense...

Thanks!

Best regards,

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Jun 2015 17:25:16 +1000

Hi Fernando,

> On 06/30/2015 01:28 AM, Mark Smith wrote:

<snip>

> which should have a justification for doing so.

I'm fine with being less prescriptive with how to generate link-layer
addresses if they're going to be directly used as IPv6 IIDs.

> change the MAC address) and that would be out of scope of this document.

Agree, going down to layer 2 is unfortunately taking a bit of a peak
into a can of worms.

> draft-ietf-6man-ipv6-address-generation-privacy but it would seem out of

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.

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

Leaving just the first sentence by itself, or perhaps rephrasing it as:

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

should hopefully cause people who might have some possible reasons to
embed link-layer addresses in IIDs to thoroughly consider whether they
really need to, and allow for the corner cases if necessary that a
MUST would not.

Regards,
Mark.

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Tue, 30 Jun 2015 09:32:58 +0000

Hi Mark, Fernando, and the group,

I just want to say that I second Fernando here: the goal of this document is to specify requirements for the generation of IPv6 addresses, without discussing the specifics of any particular scheme. IMHO, getting into that level of detail would be out of the scope of this document, also fail in keeping the problem tractable.

Regards,
Will (Shucheng LIU)

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith
> Sent: Tuesday, June 30, 2015 3:25 PM
> To: Fernando Gont
> Cc: [email-masked]
> Importance: High
> I'm fine with being less prescriptive with how to generate link-layer addresses
> if they're going to be directly used as IPv6 IIDs.
> 
> > Getting into the details of what to do if you decide to generate IIDs
> > by embedding the MAC address is essentially putting effort in how to
> > do something that we're recommending against. Besides I think that
> > temporary MAC addresses can have such a number of implications that,
> > if we're going to advice for the MAC addresses to be changed freqntly
> Agree, going down to layer 2 is unfortunately taking a bit of a peak into a can
> of worms.
> 
> >>
> >> 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]"
> >
> > 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.
> 
> 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.)
> 
> "Future specifications that specify IPv6 address generation schemes SHOULD
> NOT embed the underlying link-address in any form in the IID."
> 
> embed link-layer addresses in IIDs to thoroughly consider whether they really
> need to, and allow for the corner cases if necessary that a MUST would not.
> 
> Regards,
> Mark.
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jun 2015 19:52:30 -0300

Hi, Mark,

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

> that they don't have to.)

You MAY implement it, but SHOULD NOT use it by default.

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.

Thanks!

Cheers,

---

From: Mark Smith <[email-masked]>
Date: Wed, 1 Jul 2015 14:33:31 +1000

Hi Fernando,

> You MAY implement it, but SHOULD NOT use it by default.

Re-quoting the text just to make the context clearer:

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.

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Jul 2015 02:20:46 -0300

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:

(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