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

From: "weigengyu" <[email-masked]>
Date: Mon, 9 May 2016 14:35:35 +0800

Hi，

> This document changes the default scheme for generating stable
   Interface Identifiers with SLAAC to that specified in RFC7217,

There is a question about RFC7217 as this draft is to promote it.
In RFC7217,  in Page 6 and page 7,  "5.  Algorithm Specification"
"1.  Compute a random (but stable) identifier with the expression:
       RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)
       Where:
       RID:
          Random (but stable) Identifier
       F():
          A pseudorandom function (PRF) that MUST NOT be computable from
          the outside (without knowledge of the secret key).  F() MUST
          also be difficult to reverse, such that it resists attempts to
          obtain the secret_key, even when given samples of the output
          of F() and knowledge or control of the other input parameters.
          F() SHOULD produce an output of at least 64 bits.  F() could
          be implemented as a cryptographic hash of the concatenation of
          each of the function parameters.  SHA-1 [FIPS-SHS] and SHA-256
          are two possible options for F().  Note: MD5 [RFC1321] is
          considered unacceptable for F() [RFC6151]. "

It seems it is a concept error for RID.
RID is not random or random identifier according to the context above.

F() is an inreverse function, not a pseudorandom function.
Within parameters of F(Prefix, Net_Iface, Network_ID, DAD_Counter, 
secret_key),
only the secret_key is generated by a pseudorandom function.
But the secret_key is also a constant because it keeps unchanged after being 
generated.

There are not random features.

The question is why it is called RID, Random ID?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Alissa Cooper
Sent: Thursday, April 28, 2016 10:41 PM
To: IETF IPv6 Mailing List
Subject: Re: I-D Action: draft-ietf-6man-default-iids-11.txt

This version incorporates comments based on discussion before and during 
IETF 95 (thanks to Fernando for spinning the rev). I think this version 
addresses the comments received and should be ready to move forward.

Alissa

> On Apr 27, 2016, at 5:49 PM, [email-masked] wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IPv6 Maintenance 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-11.txt
> Pages           : 23
> Date            : 2016-04-27
>
> Abstract:
>   This document changes the default scheme for generating stable
>   Interface Identifiers with 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, RFC5072, and RFC5121, by removing the text in these RFCs
>   that required the IPv6 Interface Identifiers to be derived from the
>   underlying link-layer address, and replacing the aforementioned text
>   with a pointer to this document.  Additionally, this document updates
>   RFC3315 by specifying additional requirements on the generation of
>   Interface Identifiers used in Dynamic Host Configuration Protocol
>   version 6 (DHCPv6).  It also provides advice to system administrators
>   who employ manual configuration.  This document does not change any
>   existing recommendations concerning the use of temporary addresses as
>   specified in RFC 4941.
>
>
> 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-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-11
>
>
> 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/
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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

---

From: Bob Hinden <[email-masked]>
Date: Wed, 11 May 2016 20:19:01 -0700

This message starts a two week 6MAN Working Group Last Call on advancing:

       Title           : Recommendation on Stable IPv6 Interface Identifiers
       Authors         : Fernando Gont
                         Alissa Cooper
                         Dave Thaler
                         Will Liu
	Filename        : draft-ietf-6man-default-iids-11.txt
	Pages           : 23
	Date            : 2016-04-27

as a Proposed Standard.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 25 May 2016.

We also need two people to volunteer to do a detailed reviews, and a volunteer to be the document Shepard.

Thanks,

Bob & Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 May 2016 18:03:21 +1000

Hi,

Identifiers
> as a Proposed Standard.  Substantive comments and statements of support
for publishing this document should be directed to the mailing list.
Editorial suggestions can be sent to the authors.  This last call will end
on 25 May 2016.

I support publication.

> We also need two people to volunteer to do a detailed reviews, and a
volunteer to be the document Shepard.

I'm willing to be a detailed reviewer too.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 May 2016 08:43:26 +1200

With the clarifying references to RFC4941, I think this document is
in good shape and ready to be advanced.

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Fri, 13 May 2016 10:55:16 -0700

At Wed, 11 May 2016 20:19:01 -0700,

> as a Proposed Standard.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This…

I've read version 11 of the document.  Personally I don't have a
strong objection to publishing it, but, if I understand the past
concerns correctly, I suspect this version don't fully address them.
I also have one non-trivial point, which I would like to be address
before publication.

If my understanding is correct, one major concern raised in the past
was that some implementors may simply not see the need for the
stability and just want to address the security/privacy issues in a
different way (such as just using randomized link-layer addresses).  I
don't have a strong opinion on this particular concern myself, but I
see the point of such concerns.  If the intent of this document is not
to refuse the concern (which I'm not sure about), the current tone
still seems to be too normative.  Again, I'm not sure if the intent is
to address the concern, but if it is, I think something like the
following will be necessary:

- clarify that this recommendation is only for environments where
  address stability is needed
- clarify that this document assumes "link layer addresses" are
  something permanent, such as MAC addresses that don't change
  throughout the lifetime of the node using the hardware
- update the requirement level and wording to existing RFCs.  For
  example, replaced text for RFC2462 provided in Section 6.1

   The Interface Identifier [AARCH] for an Ethernet interface MUST be
   generated as specified in [RFCXXXX].

  is probably too strong, since this would invalidate any
  implementation that doesn't implement or use RFCXXXX.  The same
  sense of comment applies to all similar changes.

And, one other point I want to be addressed: in Section 4 it states:

   By default, DHCPv6 server implementations SHOULD NOT generate
   predictable IPv6 addresses (such as IPv6 addresses where the IIDs are
   consecutive small numbers).  [I-D.ietf-dhc-stable-privacy-addresses]
   specifies one possible algorithm that could be employed to comply
   with this requirement.  Another possible algorithm would be to select
   a pseudo-random value chosen from a discrete uniform distribution,
   while avoiding the reserved IPv6 Interface Identifiers [RFC5453]
   [IANA-RESERVED-IID].

 I suggest just removing the second sentence.
 ietf-dhc-stable-privacy-addresses is not a dhc wg item anymore due to
 some controversy, and it's not clear what will happen to its
 successor in the form of individual submission:
 draft-gont-dhcpv6-stable-privacy-addresses-01
 Since this sentence is only to show an example, just showing the
 "another possible algorithm" would suffice.

Finally, one minor editorial nit: in section 6.14

   for instance, using a method described in [8], to autoconfigure one
   or more global unicast addresses.

there should be a 'cut here' line after this text.

--
JINMEI, Tatuya

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 13 May 2016 13:45:37 -0700

Thanks for these comments. Responses are in-line.

> On May 13, 2016, at 10:55 AM, 神明達哉 <[email-masked]> wrote:
> 

The document says exactly this in the introduction:

The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link layer address.  That is, this document does not
   change any existing recommendations concerning the use of temporary
   addresses as specified in [RFC4941 <https://tools.ietf.org/html/rfc4941>], nor does it introduce any new
   requirements regarding when stable addresses are to be configured.
   Thus, the recommendations in this document simply improve the
   security and privacy properties of stable addresses.

The two paragraphs prior to this one in the intro also serve to explain this. 

>  throughout the lifetime of the node using the hardware

The document purposefully does not assume that. We clarified this in the latest update to the introduction:

More generally, the reuse of identifiers that have their own
   semantics or properties across different contexts or scopes can be
   detrimental for security and privacy
   [I-D.gont-predictable-numeric-ids <https://tools.ietf.org/html/draft-ietf-6man-default-iids-11#ref-I-D.gont-predictable-numeric-ids>].  In the case of traditional
   stable IPv6 IIDs, some of the security and privacy implications are
   dependent on the properties of the underlying link-layer addresses
   (e.g., whether the link-layer address is ephemeral or randomly
   generated), while other implications (e.g., reduction of the entropy
   of the IID) depend on the algorithm for generating the IID itself.
   In standardized recommendations for IPv6 IID generation meant to
   achieve particular security and privacy properties, it is therefore
   necessary to recommend against embedding link-layer addresses in IPv6
   IIDs.

>  sense of comment applies to all similar changes.

I’m not sure what you mean by “invalidate,” but the recommendations in Section 3 around which schemes to employ or not employ are all SHOULD-level requirements, by design.

> "another possible algorithm" would suffice.

I’m fine with the above change.

> there should be a 'cut here' line after this text.

Good catch, thanks.

Alissa

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 14 May 2016 10:55:26 +0900

I continue to oppose this document.

This draft says that existing address generation mechanisms are bad for
privacy, and proceeds to change them. But there is nothing wrong with
the existing address generation mechanisms as if the link-layer addresses
are not stable, (e.g., random MAC addresses), and a growing body of IETF
work

This draft forbids implementations from using existing address generation
mechanisms using random MAC addresses, which is a perfectly valid way to
address the privacy problem this draft is purportedly solving, and is an
approach standardized in other IETF work, for example,
https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-08#section-2.1
(now in RFC editor queue).

Here are several examples of how this draft forbids using address
generation mechanisms with random MAC addresses.

   The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link layer address.
...
   In standardized recommendations for IPv6 IID generation meant to
   achieve particular security and privacy properties, it is therefore
   necessary to recommend against embedding link-layer addresses in IPv6
   IIDs.
...
   By default, nodes SHOULD NOT employ IPv6 address generation schemes
   that embed the underlying link-layer address in the IID.

These statements should not say "link-layer address". They should say
"stable link-layer-address" or "non-ephemeral link-layer-address" or
"link-layer address that are not known to be ephemeral".

Worse, consider this normative text:

   The entire text of Section 4 of [RFC2464] is replaced with the
   following text:

   ---------------- cut here -------------- cut here ----------------
   The Interface Identifier [AARCH] for an Ethernet interface MUST be
   generated as specified in [RFCXXXX].

This explicitly prohibits an implementation from taking a random MAC
address and forming an EUI-64 address out of it.

---

From: Mark Smith <[email-masked]>
Date: Sat, 14 May 2016 12:32:07 +1000

The thing wrong with "solving" a layer 3 problem at layer 2 is that it
makes the effectiveness of the layer 3 outcome entirely dependent on the
attributes of another layer. It's fundamentally a layer violation.

I think we have layers to try to minimise or avoid these dependencies.
Having a layer 3 privacy solution to this layer 3 privacy problem means
that it doesn't matter if the layer 2 privacy is terrible or not.

I don't think this draft is forbidding layer 2 privacy at all - it is
forbidding relying on it at layer 3, because it can't and I don't think
should be relied on.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 May 2016 14:45:37 +1200

On 14/05/2016 13:55, Lorenzo Colitti wrote:
...
> address and forming an EUI-64 address out of it.

Which is a good thing, since otherwise a bad actor could correlate the
layer 2 and layer 3 addresses, which is actually impossible with IPv4
but a current weakness in IPv6.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 14 May 2016 11:46:10 +0900

> that it doesn't matter if the layer 2 privacy is terrible or not.
Actually, it's the opposite: the reason we have layers is so that layer X
doesn't have to worry about reimplementing functionality provided by layer
X-1.

If we were to follow your argument, we would implement CRC checks, packet
retransmissions, and fragmentation into HTTP, because otherwise the
reliability of HTTP would be entirely dependent on the attributes of layers
2, 3, and 4. Guess what: the outcome of HTTP *is* entirely dependent on the
link-layer not scrambling data, on on TCP dealing with packet reordering
and packet loss by sequencing and retransmitting, etc.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 14 May 2016 11:46:48 +0900

> but a current weakness in IPv6.

And this is a weakness because...?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 May 2016 15:00:08 +1200

> And this is a weakness because...?

Because if someone is trying to correlate different types of my traffic,
let's say something sent over IPX and something sent over IPv6, the task
will be made easier if the lower 48 bits are the same in both types of
traffic. (Obviously, someone on-link can use ND to correlate MAC address
and IP address, so we're talking about someone observing off-link packets.)

Not that I use IPX, but that is one case where off-link packets definitely
contain the MAC address.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 14 May 2016 12:29:11 +0900

> and IP address, so we're talking about someone observing off-link packets.)

That seems extremely unlikely to happen in practice, given that the vast
majority of hosts either don't have an IPX stack at all or have it disabled
by default, and embedding a MAC address in a protocol payload is not very
useful so people tend not to do it.

By contrast, here is one weakness that is pretty much mandated by this
draft as written: because addresses have to be stable, any remote attacker
anywhere on the Internet that ever exchanges a packet with that host can
track it every time the host visits the same network, *forever*, with no
recourse. Section 3 point 1.

Either we fix that or we stop asserting that this draft is motivated by
privacy considerations.

---

From: "weigengyu" <[email-masked]>
Date: Mon, 16 May 2016 14:11:38 +0800

Hi all,

Is it not a problem to promote RFC7217 in which concept errors are existed?

RFC7217 did not only giving a definition of stable address, but also 
defining an algorithm to generate it.
The algorithm contains concept error in my opinion.

>   Identifiers.

Regards,

Gengyu WEI

-----原始邮件----- 
From: weigengyu
Sent: Monday, May 09, 2016 2:35 PM
To: Alissa Cooper
Cc: [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-11.txt

Hi，

Regards,

Gengyu WEI
-----原始邮件----- 
From: Alissa Cooper
Sent: Thursday, April 28, 2016 10:41 PM
To: IETF IPv6 Mailing List
Subject: Re: I-D Action: draft-ietf-6man-default-iids-11.txt

Alissa

---

From: Mark Smith <[email-masked]>
Date: Mon, 16 May 2016 17:40:30 +1000

Hi,

Fernando would have usually popped in by now. As he hasn't, I'll have a go.

The IIDs in this RFC are random in comparison to MAC address derived ones.
MAC address derived ones have a structure and values that can be predicted.

The IIDs are stable in comparison to RFC4942  privacy addresses, that
change every 24 hours.

These addresses aren't meant to be an alternative to privacy addresses. A
host will likely have both, with privacy addresses preferred as source
addresses for outbound connections.

For cases where privacy addresses would cause issues because they change
relatively often, these addresses would be used eg. incoming (stable)
destination addresses for servers/services that are put in DNS (eg. HTTP
server), or router interface addresses, decoupling the router interface
address from the interface/line card MAC address, so that the interface
could be swapped (meaning new MAC address) without the router's IPv6
address charging.

Regards,
Mark.

secret_key),
> But the secret_key is also a constant because it keeps unchanged after
being generated.
> -----原始邮件----- From: Alissa Cooper
directories.
Identifiers
submission

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 16 May 2016 10:13:43 -0700

Hi Lorenzo,

> On May 13, 2016, at 6:55 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> This draft says that existing address generation mechanisms are bad for privacy, and proceeds to change them. But there is nothing wrong with the existing address generation mechanisms as if the link-layer addresses are not stable, (e.g., random MAC addresses), and a growing body of IETF work 
> 
> This draft forbids implementations from using existing address generation mechanisms using random MAC addresses,

The draft does not forbid anything. It has two MUST-level requirements: that mechanisms be defined, and that those mechanisms meet certain requirements. The other requirements in the draft are SHOULD/SHOULD NOT-level requirements, about what nodes should and shouldn’t do. IIRC there was a bunch of discussion early on about the normative strength of these requirements and landed on SHOULD/SHOULD NOT rather than MUST/MUST NOT purposefully because there were known exception cases.

> which is a perfectly valid way to address the privacy problem this draft is purportedly solving, and is an approach standardized in other IETF work, for example, https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-08#section-2.1 <https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-08#section-2.1> (now in RFC editor queue).
> 
> Here are several examples of how this draft forbids using address generation mechanisms with random MAC addresses.
> 

I disagree that any of the text above forbids anything, certainly not normatively.

> 
> These statements should not say "link-layer address". They should say "stable link-layer-address" or "non-ephemeral link-layer-address" or "link-layer address that are not known to be ephemeral".
> 
> This explicitly prohibits an implementation from taking a random MAC address and forming an EUI-64 address out of it.

Again, because the contents of Section 3 do not prohibit anything, I don’t see how this could be interpreted to prohibit anything.

Alissa

> 
> On Fri, May 13, 2016 at 5:43 AM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 16 May 2016 10:25:22 -0700

At Fri, 13 May 2016 13:45:37 -0700,

>    security and privacy properties of stable addresses.

This text specifically talks about RFC4941 as the "environments where
address stability is NOT needed", and, with the 'That is,' only talks
about it.  On the other hand, my understanding of previous concerns in
this context is to also cover other types of such environments,
specifically the one using randomized link-layer addresses with the
traditional algorithm of forming the IID from such LL addresses.

>From this one, and your response to the next point, it seems you are
saying the decision was to refuse to address that concern.  Am I
understanding it correctly?

--
JINMEI, Tatuya

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 16 May 2016 10:29:20 -0700

Hi Lorenzo,

> On May 13, 2016, at 8:29 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Sat, May 14, 2016 at 12:00 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> That seems extremely unlikely to happen in practice, given that the vast majority of hosts either don't have an IPX stack at all or have it disabled by default, and embedding a MAC address in a protocol payload is not very useful so people tend not to do it.
> 
> By contrast, here is one weakness that is pretty much mandated by this draft as written: because addresses have to be stable,

The draft does not require addresses to be stable. It changes the recommendations about how to generate an address in cases where a stable address was desired anyway.

> any remote attacker anywhere on the Internet that ever exchanges a packet with that host can track it every time the host visits the same network, *forever*, with no recourse. Section 3 point 1.
> 
> Either we fix that or we stop asserting that this draft is motivated by privacy considerations.

I would frankly be thrilled if we could get away from stable addresses altogether. But I’m skeptical about the feasibility of achieving consensus around that at present. Defining the approach in this draft in the meantime is certainly motivated by consideration for privacy improvement for me, even if that improvement is incremental.

Alissa

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 May 2016 08:08:41 +1200

Hi Gengyu,

>> F() is an inreverse function, not a pseudorandom function.

I agree that this is incorrect use of terminology; an irreversible hash is
not mathematically equivalent to a pseudo-random number generator. But the
effect is the same: an attacker has no way to predict the next F(x) or to
obtain the value of x. As far as practical engineering goes, F() can be treated
as a random number. So I don't see why this invalidates the use of RFC 7217.

You could submit an erratum for RFC 7217 at http://www.rfc-editor.org/errata.php#reportnew
so that the terminology can be corrected when the document is updated.

Regards
   Brian Carpenter

On 16/05/2016 18:11, weigengyu wrote:
> RFC7217 did not only giving a definition of stable address, but also defining an algorithm to generate it.
> -----原始邮件----- From: weigengyu
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> Please note that it may take a couple of minutes from the time of submission

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 May 2016 08:30:27 +1200

...
> I would frankly be thrilled if we could get away from stable addresses altogether. But I’m skeptical about the feasibility of achieving consensus around that at present. Defining the approach in th…

Exactly. There is a tussle between enterprise or campus network operators who
have a strong desire for stable addresses (such that they can identify miscreants)
and individuals who want to avoid tracking (such that they can avoid surveillance).
That tussle is not going to go away any time soon, so stable client IIDs are not
going away either.

I don't expect enterprise or campus operators to react well to pseudo-random MAC
addresses, either.

    Brian

---

From: joel jaeggli <[email-masked]>
Date: Mon, 16 May 2016 14:15:34 -0700

> I don't expect enterprise or campus operators to react well to pseudo-random MAC

So long as they're as long lived as your 802.1x or wpa2 enterprise
association, it's not really a big deal what your mac address is.
port-security methods already get tetchy when you abandon your previous
identity in favor of a new one without disconnecting or re-authentication.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 16 May 2016 21:38:33 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

> I don't expect enterprise or campus operators to react well to pseudo-random

And also, let's not forget that IP nets are not used exclusively for consumer oriented appliances. In addition to enterprise nets, which have different criteria from private users over ISPs, there are control system networks. On factory floors, in all manner of vehicles, and so on. Networks running machinery, providing navigation data, and on and on.

Privacy of an individual user, or of an individual host, is exactly what these networks cannot allow. So no, I don't see a future in which there are no stable addresses.

Bert

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 May 2016 20:33:01 +0900

On Tue, May 17, 2016 at 2:13 AM, Alissa Cooper <[email-masked]> wrote:

> mechanisms using random MAC addresses,
>
> The draft does not forbid anything.
>

Ok, then let me restate the objection:

The draft strongly recommends against implementations using existing
address generation mechanisms using random MAC addresses which is a
perfectly valid way to address the privacy problem this draft is
purportedly solving, and is an approach standardized in other IETF work,
for example,
https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-08#section-2.1
(now in RFC editor queue).

> It has two MUST-level requirements: that mechanisms be defined, and that
> those mechanisms meet certain requirements.
>

But that makes no sense at all. It's circular reasoning: this document says
that link layers MUST define mechanisms. To do so it proceeds to update a
number of RFCs, including RFC 2464, to say that interface identifiers MUST
be generated as specified in this document... which only says that
link-layers MUST define mechanisms. So the updated text violates the very
document you're updating it to refer to.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 May 2016 20:48:52 +0900

On Tue, May 17, 2016 at 2:29 AM, Alissa Cooper <[email-masked]> wrote:

> draft as written: because addresses have to be stable,
>
> The draft does not require addresses to be stable. It changes the
> recommendations about how to generate an address in cases where a stable
> address was desired anyway.
>

No, that's not correct. This draft makes recommendations about how to
generate an address "where implementations otherwise would have configured
a stable IPv6 IID containing a link layer address". On many link layers
(e.g., Ethernet), it is currently the case that implementations MUST
generate IIDs based on link layer addresses. Therefore, the recommendations
apply 100% of the time on those link layers. In effect, this draft is
saying that Ethernet addresses SHOULD be stable.

> I would frankly be thrilled if we could get away from stable addresses
> altogether. But I’m skeptical about the feasibility of achieving consensus
> around that at present. Defining the approach in this draft in the meantime
> is certainly motivated by consideration for privacy improvement for me,
> even if that improvement is incremental.
>

A much greater improvement in terms of privacy, and a much easier one in
terms of sheer number of RFCs that need to be updated, would derive from
forbidding or recommending against embedding *stable* link layer addresses
in IIDs.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 17 May 2016 08:32:07 -0700

On 5/17/16 4:48 AM, Lorenzo Colitti wrote:
> On Tue, May 17, 2016 at 2:29 AM, Alissa Cooper <[email-masked]
> <mailto:[email-masked]>> wrote:
>  
> 
>     I would frankly be thrilled if we could get away from stable
>     addresses altogether. But I’m skeptical about the feasibility of
>     achieving consensus around that at present. Defining the approach in
>     this draft in the meantime is certainly motivated by consideration
>     for privacy improvement for me, even if that improvement is incremental.
> 
>  
> forbidding or recommending against embedding *stable* link layer
> addresses in IIDs.

which sounds fine by me.

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 May 2016 08:23:09 +1000

Already fixed, RFC6724:

"5. Changed the default recommendation for Source Address Selection Rule 7
to prefer temporary addresses rather than public addresses, while providing
an administrative override (in addition to the application-specific
override that was already specified). This change was made because of the
increasing importance of privacy considerations, as well as the fact that
widely deployed implementations have preferred temporary addresses for many
years without major application issues."

Most hosts that will use these addresses as source addresses for their
packets are unlikely to move around and will value stability - servers
providing services to clients and router and other infrastructure devices'
interfaces.

If a client hosts use these types of addresses for their out bound
connection source addresses, then privacy addresses have been actively
switched off for some reason or are not and have never been available (e.g.
router interfaces). In other words, a conscious choice has been made to
disable privacy. That may or may not be a good idea in that context and in
others' external opinion, however we can't stop people doing stupid things,
we've just got to encourage them to do the right thing either implicitly or
explicitly by choosing good defaults.

This is a better default than EUI-64 based IIDs for when privacy addresses
aren't used or available (by choice).

Regards,
Mark.

privacy considerations.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 May 2016 10:27:30 +1200

>> forbidding or recommending against embedding *stable* link layer

Well, we could have the draft say this, but I think it would still be a
normative update to all the v6-over-foo RFCs for the case where randomized
MAC addresses are not active (i.e. basically 100% of the installed base).

    Brian

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 17 May 2016 16:26:55 -0700

> On May 17, 2016, at 3:27 PM, Brian E Carpenter <[email-masked]> wrote:
> 

And the layer violation would still create the possibility for correlating activities between entities that see layer 3 identifiers and entities that see only layer 2 identifiers.

What if we dropped requirement #1 in Section 3, but left the rest the same? This would open the door such that people who wanted to comply with the SHOULD-level recommendation in this spec in the presence of randomized MAC addresses still could (e.g., by implementing 7217 and using the randomized MAC as the Net_Iface parameter), but directly embedding a MAC address in the IID would still go against the SHOULD NOT recommendation here.

Alissa

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 May 2016 11:20:51 -0400

Hi, Jinmei,

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

On 05/13/2016 01:55 PM, 神明達哉 wrote:
[....]
> still seems to be too normative.

There are multiple reasons for which that is the wrong approach and/or
incorrect.

They are stated in the I-D as:
   [I-D.gont-predictable-numeric-ids].  In the case of traditional

A more thorough explanation was provided by Alissa during the last IETF
meeting, and can be summarized as:

* Using an ID in a different context or different scope (than originally
meant for), or with additional semantics than those required for
interoperability results in security/privacy implications. Please read:
draft-gont-predictable-numeric-ids

* Sticking to MAC-based IIDs (when randomizing MAC addresses) is not a
good idea because:
  + Attempts to ignore a flaw, relying on something the host does not
control
     e.g. we do not control whether MAC addr randomization algorithm is
     appropriate or if it is actually possible Wastes 18 bits of entropy

 + Might even lead to interoperability problems
     There's no recovery strategy for DAD failures in traditional SLAAC

* RFC7217 and default-iids is about replacing the
default scheme for generating stable addresses

* Don't want stable addresses?
  1) Update RFC 4941 such that stable addresses are not required (huge
potential for interoperability problems)
  2) Use the randomized MAC address as the Net_Iface parameter of RFC7217.
  3) Note: IEEE has RFC7217-like stable per network MAC addresses

Besides the "concerns" raised by Lorenzo assume you use RFC7217-only. If
you care about privacy, you should be using RFC4941, in which all
outgoiing connections would prefer the temporary addresses, rather than
the stable ones -- that's what RFC4941 is about, anyway.

> Again, I'm not sure if the intent is

This is already noted in the current version of this document.
That said, the current specs (see RFC4941) essentially require stable
addresses 8temp addresses are generated along the traditional/stable ones).

Another way to put is s that this recommendation applies where hosts
would otherwise embed a link-layer address in the IID (this is stated in
the draft already, anyway).

> - update the requirement level and wording to existing RFCs. 

We don't really need to make assumptions about layer-2
addresses/identifiers -- we're standardizing what we do at layer-3.

The root of this and many other flaws is making assumptions at layer N
regarding things at layer (N-1) where there's no reason at all to make
such assumptions.

>   For

RFCXXXX essentially just says what the default algorithm should be.

>  "another possible algorithm" would suffice.

I will check what the status of the corresponding draft-gont version of
the I-D is. To the extent that is possible, I'd keep it, since
ietf-dhc-stable-privacy-addresses leads to stable addresses, while a
simple randomization scheme doesn't.

> there should be a 'cut here' line after this text.

Good grief!

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 May 2016 11:41:28 -0400

On 05/13/2016 11:29 PM, Lorenzo Colitti wrote:
> On Sat, May 14, 2016 at 12:00 PM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> That seems extremely unlikely to happen in practice,

Yes... as was "pervasive monitoring" and others. -- C'mon...

That's not how you think security&privacy wise: either provide numbers
that show that that can't happen (which you really can't), or assume it
will happen. You have to fail on the safe side, not on the other. And
since you cannot predict the standardization of other technologies
(either) -- which might happen outside the IETF --- I'm not sure how you
can make this sort of claim.

> draft as written: because addresses have to be stable, any remote
> attacker anywhere on the Internet that ever exchanges a packet with that
> host can track it every time the host visits the same network,
> *forever*, with no recourse. Section 3 point 1.

Use RFC4941 for that -- that's why they were standardized in the first
place. And you choose how you employ your addresses.

And if you just hate the fact of having a stable address, please write a
proposal to update RFC4941, such that stable addresses (alongside
temporary addresses) are not required.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 May 2016 12:21:35 -0400

Lorenzo,

On 05/13/2016 09:55 PM, Lorenzo Colitti wrote:
> the existing address generation mechanisms as if the link-layer
> addresses are not stable, (e.g., random MAC addresses), and a growing
> body of IETF work 

Yes, there is *a lot* wrong about that. Actually, the fact that we've
been embedding MAC addresses in the IID is the reason why we're having
this discussion.

Please read: draft-gont-predictable-numeric-ids for a discussion of why
embedding MAC addresses in the IID is bad.

Among others (and besides the reasons Brian already mentioned):

* Attempts to ignore a flaw, relying on something that we do not
control, and that the host may not control
  + e.g. we do not control whether MAC addr randomization algorithm is
appropriate or if it is actually possible to randomize it
  + it may be impossible for the node to randomize the MAC address

* Wastes 18 bits of entropy

* May lead to interoperability issues

> This draft forbids implementations from using existing address
> generation mechanisms using random MAC addresses, which is a perfectly
> valid way to address the privacy problem this draft is purportedly
> solving, 

It is not, as noted above. And I'm puzzled that after 30+ years of
improper numeric ids (draft-gont-predictable-numeric-ids), you keep
insisting on this.

>    containing a link layer address.

Would "apply only in cases where implementations otherwise would embed a
link-layer address in the IID, as for traditional SLAAC addresses"?

>    necessary to recommend against embedding link-layer addresses in IPv6

Yes, this is intended. And too bad that you seem to keep pushing a
flawed scheme.

> "link-layer address that are not known to be ephemeral".

No. It says what it is meant to say. Please read:
draft-gont-predictable-numeric-ids

> address and forming an EUI-64 address out of it.

Exactly: you don't reuse identifiers in different layers, for different
scopes, etc. That's a horrible thing to do security&privacy-wise. I'm
glad that, at the very least, you're on record for proposing that and
that I'm on record for noting this is a bad idea. -- so that none can
say "we didn't know this could happen" when s* happens.

Thanks,

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 May 2016 10:55:07 -0700

At Tue, 17 May 2016 11:20:51 -0400,

>    of the IID) depend on the algorithm for generating the IID itself.

I know there's this text, but it's too vague to me to interpret it as
this draft tries to reject the concern.  That's why I've been asking
the intent of the draft several times.  And this vagueness is the main
point of mine, rather than the specific claims themselves.  So I'm
not going to respond to each defense arguments for the claims, but
rather focusing on the higher level point: to me, the current form of
draft is vague about the following two points:

1. Whether it assumes (or introduces itself) that a stable address is
   required to be configured (banning non-stable only operation).
2. Whether the case where "link-layer addresses" are randomized is
   also covered by this draft (in that it prohibits embedding such
   addresses in IID)

According to the discussion in this thread, my latest understanding is
that the answer is "yes" to both points.  In that case, I'd then
request these points to be stated more explicitly and clearly in the
draft, and see clear wg consensus on these points.

I myself don't have a strong opinion (yet) on these points, but I see
some controversy in the wg.  For example, some responses in the latest
sub-thread on RFC4941 seem to indicate opinions on point #1 vary (and
some people even say RFC4941 does not necessarily require a public
address).  I also see that some people think that point #2 can be
loosened so that it only covers "permanent-and-predictable link-layer
addresses".  So I don't think we have a clear wg consensus on these
yet.  And, if this draft tries to achieve something that relies on
these points, IMO it can't pass the wg last call yet.

> simple randomization scheme doesn't.

This logic seems awkward to me.  For
draft-gont-dhcpv6-stable-privacy-addresses-01 to be a better example
despite its uncertain future for that reason, I'd expect the stability
is also included in the updated text of RFC3315.  Otherwise, just
showing a simple randomization is a far better example since it
exactly meets the revised text.  I'd also note another recent trend in
dhc, where randomizing DUID may become a new norm as described in
RFC7844 (a standards track RFC).  Since the stability of
draft-gont-dhcpv6-stable-privacy-addresses depends on the stability of
DUID, the stability argument doesn't hold for client implementations
supporting and enabling RFC7844.

For all these reasons, I'd still suggest just removing the reference.
But if the idea of draft-gont-dhcpv6-stable-privacy-addresses is too
loved to be removed, my secondary suggestion is to move it to an
auxiliary example after the simple randomization, noting that it's
listed because it has an additional property of stability and that it
has a limitation that it's not compatible with RFC7844.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 May 2016 09:43:23 +1200

Hi,
On 19/05/2016 05:55, 神明達哉 wrote:
...
> ...but

I think this draft is correct to leave this question open. It's
a deployment decision which will be very different for (e.g.) a
tablet connected for half an hour in a coffee shop versus a desktop
connected indefinitely in an office of a large enterprise.

>    also covered by this draft (in that it prohibits embedding such

I agree, I think the text should allow (but not require) the traditional
form of modified EUI-64 in the case of pseudo-random MAC addresses.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 May 2016 22:18:11 -0400

On 05/16/2016 01:29 PM, Alissa Cooper wrote:
> altogether. But I’m skeptical about the feasibility of achieving
> consensus around that at present. Defining the approach in this draft in
> the meantime is certainly motivated by consideration for privacy
> improvement for me, even if that improvement is incremental.

There are scenarios in which you simply don't want that.

It might be desirable in the "roaming" case, but certainly not in others
(that's why RFC4941 keeps being disabled in enterprise deployments, for
instance).

Side note: Curiously enough, I'm told that:

* Some folks ding MAC address randomization randomize the layer-2
address when prbing networks, but employ a real address when associating
with the AP.

* OTOH, other folks implement RFC7217-like scheme for layer-2, but
rather than getting the RFC7217 outcome statelesly, they keep track of
networks visited, and the MAC addresses employed in each of them.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 May 2016 22:13:36 -0400

On 05/16/2016 01:25 PM, 神明達哉 wrote:
> address stability is NOT needed",

Please let me clarify this.

IPv6 nodes employ, by default, stable addresses. The only standardized
things that's different from that is temporary addresses, which
essentially specify how to generate temporary addresses *in addition* to
the stable ones.

If you want to do temporary-addresses-only, you need to update RFC4941,
because it says that you should have both stable and temporary addresses.

What we say in our document is: "where you'd configure a stable
addresses, do RFC7217 rather than embed link-layer addresses". We do not
argue whether you should have/use stable addresses in the first place.
Such requirements are elsewhere, and not in this document.

>  and, with the 'That is,' only talks

No. My take is that the concern is flawed. Please read
draft-gont-predictable-protocol-ids, and even RFC4941, which talks at
length about security and privacy issues regarding reusing identifiers
in different context, for different scopes, etc.

Let's call a lemon a lemon: Asking to embed a layer-2 identifier/address
in a layer-3 address is extremely bad.

After 30+ years of experience with flaws related to improper selection
of numeric identifiers, it's really bad that people keep pushing this
sort of thing.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 May 2016 22:19:44 -0400

> so that the terminology can be corrected when the document is updated.

FWIW, the term "PRF" (as *opposed*) to PRNG was suggested by Alfred
Hoenes -- IIRC, a mathematician. IIRC, he noted that a hash function is
simply one possible way of a PRF.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 May 2016 22:24:36 -0400

Hi, Bert,

Thanks for the note. Comments in-line...

> Privacy of an individual user, or of an individual host, is exactly what these networks cannot allow. So no, I don't see a future in which there are no stable addresses.

That's what this document is all about: to improve stable addresses such
that, from an operational pov, they are still stable, while they prevent
address scanning and network tracking.

We do not mandate thier use. We just say that, by default, folks should
stop using a scheme with known flaws.

Thanks!

Cheers,

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 May 2016 16:22:25 -0700

At Tue, 17 May 2016 22:13:36 -0400,

> in a layer-3 address is extremely bad.

I don't have a strong position on this matter itself, but my
understanding of the sense of the wg is that this is controversial,
and at least far from a clear consensus.  To repeat myself, *my*
concern on this last call is that it's not even clear, at least to me,
if this draft tries to say embedding a link-layer address is, whether
it's randomized or not, "extremely bad" (and must therefore be
prohibited).  If that's the intent, it should be clearly stated and
backed by a clear consensus from the wg.  Right now I don't see either
such a clear statement or clear wg consensus.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 May 2016 12:03:10 +1200

> simply one possible way of a PRF.

Well, it's complicated (https://en.wikipedia.org/wiki/Pseudorandom_function_family).
As engineers, I think we do better to focus on what matters to us: we need
an unpredictable and unguessable bit string, which we carelessly call 'random'.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 May 2016 10:00:10 +0900

> in different context, for different scopes, etc.

Fernando, please stop arguing that a random MAC address is a "predictable
ID". That statement is false and continuing to argue for it is not helping
this document advance.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 18 May 2016 22:19:57 -0700

> On May 18, 2016, at 4:22 PM, 神明達哉 <[email-masked]> wrote:
> 
> prohibited).  If that's the intent, it should be clearly stated

The draft makes just about a clear a statement in this vein as is possible:

"By default, nodes SHOULD NOT employ IPv6 address generation schemes
   that embed the underlying link-layer address in the IID.”

Note that this statement does not prohibit anything, nor does it make a normative (in the moral sense) judgment. It just states the recommendation, which is the point of the document.

I appreciate that not everyone on the list agrees with this recommendation. But I find the claim that this recommendation is unclear to be difficult to understand. That is, I can’t think of a way to convey the same recommendation that would be clearer. If you can, please suggest text.

Alissa

> and

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 May 2016 15:10:32 +0900

On Thu, May 19, 2016 at 2:19 PM, Alissa Cooper <[email-masked]> wrote:

> Note that this statement does not prohibit anything, nor does it make a
> normative (in the moral sense) judgment. It just states the recommendation,
> which is the point of the document.
>
> I appreciate that not everyone on the list agrees with this
> recommendation. But I find the claim that this recommendation is unclear to
> be difficult to understand. That is, I can’t think of a way to convey the
> same recommendation that would be clearer. If you can, please suggest text.
>

Alissa,

I don't think anybody is claiming that the recommendation itself is
difficult to understand. What is difficult to understand is how the
document justifies that claim.

It looks like the main argument used to justify this recommendation is
major privacy risks. But embedding a link layer identifier into an IP
address is not a major [1] privacy risk. It is only embedding a *STABLE*
link-layer address that is a major privacy risk.

Recommending that link-layer address be embedded only if they are ephemeral
would address the privacy concerns just as well as (or maybe even better)
than the approach proposed in this document.

I think what people are do not understand is why this document recommends
one but not the other. I certainly don't.

Cheers,
Lorenzo

[1] I argue that cross-referencing IPX traffic to IP traffic is not a major
privacy risk because IPX is so uncommon.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 May 2016 09:50:56 +0200

Le 19/05/2016 à 01:22, 神明達哉 a écrit :
> At Tue, 17 May 2016 22:13:36 -0400, Fernando Gont
> <[email-masked]> wrote:
>
>>> From this one, and your response to the next point, it seems you
>>>  are saying the decision was to refuse to address that concern.
>>> Am I understanding it correctly?
>>
>> draft-gont-predictable-protocol-ids, and even RFC4941, which talks
>>  at length about security and privacy issues regarding reusing
>> identifiers in different context, for different scopes, etc.
>>
>> Let's call a lemon a lemon: Asking to embed a layer-2
>> identifier/address in a layer-3 address is extremely bad.
>
> concern on this last call is that it's not even clear, at least to
> me, if this draft tries to say embedding a link-layer address is,
> whether it's randomized or not, "extremely bad" (and must therefore
> be prohibited).

This explanation makes me think of the following.

A true link-layer address, or a randomized link-layer address, embedded
(or not) in an Interface ID - is a matter of Ethernet only.  That could
lead to update "IPv6 over Ethernet" RFC 2464, and not create a new RFC
default-iids.

Moreover, it may be that people on cable Ethernet in Enterprise have
less privacy concern.  It's people on WiFi who do because they're more
mobile and no subject to internal codes of conduct.  And, unfortunately,
there is no "IPv6 over WiFi" RFC to update with this true link-layer vs
randomized link-layer address.  First, one should write an "IPv6 over
802.11" RFC.  Then we can talk about link-layer vs randomized in IID for
WiFi.

Second, this (true link-layer or radomized link-layer address in IID)
is not relevant for other link layers such as USB, or cellular wireless
access links, or others.  There is no worry here about 'true' vs
'random' link-layer address in the first place (whether in IID or not),
because there is no 'true' (i.e. IEEE-assisgned) link-layer address.  In
addition, on cellular links the prefix advertised in RA is unique per
terminal - so _that_ could be a privacy issue (not the IID).

Before privacy concerns, there is an issue to make IPv6 does run on
these links: people struggle to create 48bit addresses which can fill
the structures needed in IPv6 programming.  These addresses may look
random, but are actually based on hints, thus creating something
predictable.  The issue here is that is not standardized and may lead to
conflicts.  _After_ that conflict issue is solved, can we talk about
IID privacy issues of true-vs-random link-layer address in these links.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 May 2016 10:09:29 +0200

Le 19/05/2016 à 07:19, Alissa Cooper a écrit :
>>>> From this one, and your response to the next point, it seems
>>>> you are saying the decision was to refuse to address that
>>>> concern.  Am I understanding it correctly?
>>>
>>> draft-gont-predictable-protocol-ids, and even RFC4941, which
>>> talks at length about security and privacy issues regarding
>>> reusing identifiers in different context, for different scopes,
>>> etc.
>>>
>> understanding of the sense of the wg is that this is
>> controversial, and at least far from a clear consensus.  To repeat
>> myself, *my* concern on this last call is that it's not even clear,
>> at least to me, if this draft tries to say embedding a link-layer
>> address is, whether it's randomized or not, "extremely bad" (and
>> must therefore be prohibited).  If that's the intent, it should be
>> clearly stated
>
> Note that this statement does not prohibit anything, nor does it make
> a normative (in the moral sense) judgment. It just states the
> recommendation, which is the point of the document.
>
> recommendation. But I find the claim that this recommendation is
> unclear

I think that recommendation is too generic.

I think it should say:
"If a human user can be reassured during a privacy worry (avoid
  traceability of IP address by surveillance or commercial interests) -
  the EUI-64 SHOULD NOT contain the company_id (the first three octets),
  nor 0xFFFE, nor the last three octets of the Ethernet address"
  - and add it to RFC2464 section 4:
    https://tools.ietf.org/html/rfc2464#section4

I think on some non-Ethernet links there are some 48bit identifiers
which are not assigned by IEEE, but imagined by programmers. They are
not used as a link-layer address (they are not in src/dst headers of
link-layer messaging), but are there only to fill in IPv6 data
structures. Some times they are based on hints, other times they are
random. When they are Unix rand(), and if this can reassure the privacy
worry of a user: they could be put in the IID.

Alex

> to be difficult to understand. That is, I can’t think of a way to
> convey the same recommendation that would be clearer. If you can,
> please suggest text.
>
> Alissa
>
>
>> and backed by a clear consensus from the wg.  Right now I don't see
>> either such a clear statement or clear wg consensus.
>>
>> -- JINMEI, Tatuya
>
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 May 2016 18:38:21 +1000

>
> Recommending that link-layer address be embedded only if they are
ephemeral would address the privacy concerns just as well as (or maybe even
better) than the approach proposed in this document.

So how would the IPv6 layer test that, and if it was tested properly, what
happens if the test fails?

I think the testing of layer 2 address randomisation, and coming up with a
both a user acceptable and friendly scheme to deal with a test failure is
harder and more complex that just universally applying RFC7217 to all past,
current and future link layers, regardless of how good or bad their link
layer addresses are.

It fits the principle of having a single and general solution for all cases
rather than having tests, dealing with exceptions and individual
case-by-case solutions.

IPv6 has followed a theme of trying to generalise functions from layer 2
into layer 3 (e.g.,  ND over ICMPv6 rather than link specific versions of
ND, DHCPv6 over IPv6 over PPP rather than DNS etc. in IPV6CP etc.).

This IPv6 address privacy problem exists at the IPv6 layer. Solve it at the
IPv6 layer and it has only needed to be solved once, rather than
repeatedly, and has been solved universally.

RFC1958 explains it:

"The Internet level protocol must be independent of the hardware medium and
hardware addressing."

RFC7217 is fixing a mistake as well as increasing privacy.

Regards,
Mark.

> Cheers,
> Lorenzo
>
> [1] I argue that cross-referencing IPX traffic to IP traffic is not a
major privacy risk because IPX is so uncommon.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 May 2016 18:03:53 +0900

> happens if the test fails?
The code that configures both layer 2 and layer 3 can simply call
arc4random_buf (or your favourite random function) and then "ifconfig wlan0
hw ether <foo>", and then pick an EUI-64 IID based on that. Even if the
hardware does not support the hardware address and does not return an
error, but silently continues to use the hardware MAC address, the
resulting IPv6 address is still random and free from privacy concerns.

> current and future link layers, regardless of how good or bad their link
This is really not hard to test in any hardware qualification lab. Really,
it isn't.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 May 2016 11:10:23 +0200

Le 19/05/2016 à 11:03, Lorenzo Colitti a écrit :
> On Thu, May 19, 2016 at 5:38 PM, Mark Smith <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> So how would the IPv6 layer test that, and if it was tested properly,
> what happens if the test fails?
>
> arc4random_buf (or your favourite random function)

I think the question is to decide when to call that random
function.

A 48bit identifier is often there already, but we need to use if it's
random, or generate one if it's not random.  So how to test whether it's
random?

> and then "ifconfig wlan0 hw ether <foo>", and then pick an EUI-64 IID
> based on that. Even if the hardware does not support the hardware
> address and does not return an error, but silently continues to use
> the hardware MAC address, the resulting IPv6 address is still random
> and free from privacy concerns.
>
> I think the testing of layer 2 address randomisation, and coming up
> with a both a user acceptable and friendly scheme to deal with a test
> failure is harder and more complex that just universally applying
> RFC7217 to all past, current and future link layers, regardless of
> how good or bad their link layer addresses are.
>
> This is really not hard to test in any hardware qualification lab.
> Really, it isn't.

On the contrary, I think it is very hard to test a number to see whether
it's random - you need a very expensive lab and out-of-band info.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 May 2016 00:26:54 +0900

> it's random - you need a very expensive lab and out-of-band info.

Sure, but the same can be said of any RFC 7217 implementation. Doing
blackbox testing of that sort of thing is hard.

On the other hand, it is very easy to test that when the device
disconnects/reconnects, the new connection has a different MAC address and
a different IPv6 address. That's the most important thing.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 19 May 2016 08:33:57 -0700

At Wed, 18 May 2016 22:19:57 -0700,
Alissa Cooper <[email-masked]> wrote:

> Note that this statement does not prohibit anything, nor does it
> make a normative (in the moral sense) judgment. It just states the

I've heard phrases like "it does not prohibit anything", and it always
confused me.  So let me ask essentially the same question again.
Assume there's an implementation that uses randomized link-layer
addresses and that implementation builds the IID for IPv6 address by
embedding that link-layer addresses by default.  Would that
implementation be considered to be non-compliant to the above SHOULD
NOT?  Without any qualifier to the link-layer address, I would
interpret it as such implementation is non-compliant.  But if so, that
contradicts statements like "it doesn't prohibit anything".  Hence my
confusion.  So, what's the author's intent?  Would such an
implementation be considered non-compliant to this SHOULD NOT?

> unclear to be difficult to understand. That is, I can’t think of a
> way to convey the same recommendation that would be clearer. If you
> can, please suggest text.

See above, it's not about agree or disagree with a recommendation.  I
didn't even know a particular type of implementation would be
considered non-compliant to a specific normative text of this draft.
Once I understand the intent, then I can agree or disagree with it,
or, if we agree with the intent but the text isn't clear enough I'm
willing to suggest alternative text.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 May 2016 08:34:27 +1200

On 19/05/2016 21:10, Alexandre Petrescu wrote:
...
> So how to test whether it's random?

Answering your question in case anybody doesn't realise that it is rhetorical:

It is impossible (actually, meaningless) to test whether a single value is random.

1234 is a perfectly fine random decimal number. So 14159265358979323846.

0xE8039A3C677A is a perfectly fine random hexadecimal number. It might be
an Ethernet address. Or not.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 May 2016 08:43:20 +1200

> privacy risk because IPX is so uncommon.

I only chose that example because it's an obvious one. Do we know all the contexts
in which a MAC address may appear in an off-link packet? I doubt it.

A privacy risk doesn't have to be "major" to be important. If we are concerned
about massive-scale surveillance, where the opponent is using Hadoop and machine
learning technologies to glean information, minor risks become significant. So
I support the draft as it stands: any case in which a layer 2 identifier is
embedded *in clear* in a higher layer identifier is a bad thing, even if it's
a temporary and pseudo-random bit string.

[I hadn't remembered that RFC1958 already said that ;-)]

I think this is completely orthogonal to whether stable IIDs should be used
by clients at all - that's an operational choice that we can only leave to site
operators.

Regards
   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 May 2016 09:48:18 +0900

Brian,

I will concede that there might be theoretical threats involving ephemeral
link layer addresses and non-IP protocols that we have not yet thought of.
However, the key thing to note is that even if these threats exist, their
impact is limited in time. By contrast, any threat involving a stable IP
address, in addition to being much easier to carry out because it's
available off-link, causes permanent impact because the stable address
never changes.

So if you think about it, your argument is actually in favour of link layer
address randomization, not against it. Assuming that the link layer address
will leak sometimes (here's a real-world example that's affects a lot more
people than IPX: captive portal redirect URLs that contain the MAC address
in the clear), it's much safer for that link address to be ephemeral than
to be permanent.

As to your statement that "whether people use stable IIDs is an operational
choice we can only leave to site operators" - this document is not leaving
it to site operators.

Let's all always keep in mind that the current text of the draft says that
on every network, hosts SHOULD configure an IPv6 address that never changes
until the end of time. I think that recommendation is irresponsible.

Cheers,
Lorenzo

On Fri, May 20, 2016 at 5:43 AM, Brian E Carpenter <
[email-masked]> wrote:

> unclear to
> ephemeral

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 20 May 2016 01:17:05 +0000

I'm not sure why this is still being debated. Lorenzo's suggestion, I thought, was really clear and to the point. The issue here is not what 64-bit gets used in the IID. The only question is whether a permanent 64-bit IID is desirable for security concerns.

Why is it difficult to only make that point?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 May 2016 14:18:15 +1200

On 20/05/2016 12:48, Lorenzo Colitti wrote:
...
> until the end of time. I think that recommendation is irresponsible.

Thus, I'm continuing to run my laptop with only an RFC4941 address for a few
days to see whether it has any negative impact at all. So far, so good.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 May 2016 15:19:23 +0900

> days to see whether it has any negative impact at all. So far, so good.

Excellent! Now, if we can only make this draft stop saying that that you
SHOULD NOT do that...  :-)

---

From: [email-masked]
Date: Fri, 20 May 2016 09:04:09 +0200

> Excellent! Now, if we can only make this draft stop saying that that you SHOULD NOT do that...  :-)

Everything has to be read in context. My reading of this document is that it says what an implementation SHOULD do _iff_ a stable IID is to be generated. It says nothing about what to do if a stable IID is not required.

I find the current text quite clear on that, but clearly you don't.
Would it help with some sort of clearer applicability statement in this document? Can you propose text?

Cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 May 2016 16:20:44 +0900

On Fri, May 20, 2016 at 4:04 PM, <[email-masked]> wrote:

> Everything has to be read in context. My reading of this document is that
> it says what an implementation SHOULD do _iff_ a stable IID is to be
> generated. It says nothing about what to do if a stable IID is not required.
>

On Ethernet, it is always required. The reason is this text:

Currently, implementations must configure a EUI-64 IID, per RFC 2464
section 4. Thus, by definition any currently-compliant implementation of
RFC 2464 "configures a stable IPv6 IID", all the time. If this document
becomes an RFC, a compliant implementation will thus have to follow the
recommendations of this document all the time.

If we want to clarify this, then I propose this text:

   The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link layer address. Configuring a stable IPv6 IID is
   OPTIONAL.

Cheers,
Lorenzo

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 20 May 2016 09:59:59 +0200

Le 19/05/2016 à 17:26, Lorenzo Colitti a écrit :
> On Thu, May 19, 2016 at 6:10 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> disconnects/reconnects, the new connection has a different MAC address
> and a different IPv6 address. That's the most important thing.

I agree, it is easy to test the Interface ID changes or not upon 
reconnection (possibly delivered by ppp).

As an exception, this 'connection' tends to no longer be that simple 
yes/no state of earlier ppp.  These days an M2M module has multiple 
states of being connected.  Some-times it is connected yet it receives 
different prefixes in Router Advertisements.  In that case the privacy 
could be respected despite the IID being the same.

In these cases I noticed that the computer forms multiple different IIDs 
for each prefix in a received RA.  The computer ends with with about 10 
addresses in little time (depends on movement, and connectivity). 
That's not good either - too many addresses.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 20 May 2016 10:06:21 +0200

Le 19/05/2016 à 22:34, Brian E Carpenter a écrit :
> On 19/05/2016 21:10, Alexandre Petrescu wrote: ...
> 0xE8039A3C677A is a perfectly fine random hexadecimal number. It
> might be an Ethernet address. Or not.

Yes, and the surveillant knows it: seeing a number does not mean it's a
MAC address.  Always seeing the same number does not mean it's the same
person (maybe it's someone pretending to be that poor person, in order
to fool the surveillant).

Alex

---

From: 神明達哉 <[email-masked]>
Date: Fri, 20 May 2016 09:04:55 -0700

> I find the current text quite clear on that, but clearly you don't.

It's not clear to me either.  I commented on this exact point in my
first response to the last call.  Its followup discussion actually
confused me further:
http://www.ietf.org/mail-archive/web/ipv6/current/msg24391.html

In this discussion, I suggested "clarifying that this recommendation
is only for environments where address stability is needed".  The
response to that part of comment refers to a paragraph of the
introduction section:

   addresses as specified in [RFC4941], nor does it introduce any new

At least to me, this is not the same as "this recommendation is only
for environments where address stability is needed".  So I tried to
understand the actual intent with followup questions, but the
subsequent discussions only introduced more confusion for me (because
of discussions on other points like whether using randomized
link-layer address is "extremely bad").

> this document? Can you propose text?

I've been unwilling to propose text as I didn't even understand the
authors' actual intent, but if it's actually that "it says what an
implementation SHOULD do _iff_ a stable IID is to be generated", I'd
suggest revising the above paragraph as follows:

   The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link layer address.  For example, this document does
   not change any existing recommendations concerning the use of
   temporary addresses as specified in [RFC4941], nor do the
   recommendations apply to cases where the link layer address is not
   stable (e.g., it is periodically randomized) in the first place,
   nor does it introduce any new requirements regarding when stable
   addresses are to be configured.  Thus, the recommendations in this
   document simply improve the security and privacy properties of
   stable addresses.

If the intent of this document is really just that it applies iff a
stable IID is to be generated and does not make any judgment on, e.g.,
use of randomized link-layer addresses, this proposed text shouldn't
be a problem for anyone. (for some, it may seem to say the obvious and
therefore redundant, but given that whether randomized LL address is
good or bad was so controversial here, I think it's helpful to
explicitly clarify that).  But I was not sure if it's really
acceptable, especially for the authors, by seeing opinions like
the "extremely bad" comment.

To be clear, I'm not particularly an advocator of the use of
randomized link-layer addresses.  But I've seen this as one central
point concerning how to move forward for this document, so I believe
we should be at least clear on this in the document text.

--
JINMEI, Tatuya

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 20 May 2016 23:06:31 +0200

> On May 18, 2016, at 1:26 AM, Alissa Cooper <[email-masked]> wrote:
> 

I don’t think I saw anyone respond to this suggestion, so I’d like to ask again for people’s opinions about this.

To my eye this is a nice compromise.

Alissa

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 May 2016 12:55:59 -0400

On 05/18/2016 09:00 PM, Lorenzo Colitti wrote:
> On Wed, May 18, 2016 at 11:13 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Fernando, please stop arguing that a random MAC address is a
> "predictable ID". That statement is false and continuing to argue for it
> is not helping this document advance.

I simply referenced a draft. When I referred to embedding MAC addresses
in IPv6 IIDs, I said "improper" IDs, rather than "predictable".

Reusing IDs in different layers for different scopes, etc., is a bad
thing. It just takes some else making the same bad decision, an now an
attacker can correlate traffic because you and other guy thought that
embedding an identifier from a lower layer in your own protocol, in a
different context, with a different scope, for a different purpose.

Brian noted, just as an example, the ability to correlate IPv6 and IPX
traffic. But this is obviously just an example that shows why something
that might seem benign in some environment may show up as being a real
bad idea.

The fact that you'd be wasting 18 bits of entropy in your IIDs (if you
generate them by embedding a MAC address -- even if randomized) is yet
another datapoint that you're doing the wrong thing: an indication that
you're trying to combat the symptom, rather than the disease.

Thanks,

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 20 May 2016 23:23:22 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Alissa Cooper

> > What if we dropped requirement #1 in Section 3, but left the rest the same?
> This would open the door such that people who wanted to comply with the
> SHOULD-level recommendation in this spec in the presence of randomized MAC
> addresses still could (e.g., by implementing 7217 and using the randomized
> MAC as the Net_Iface parameter), but directly embedding a MAC address in the
> IID would still go against the SHOULD NOT recommendation here.
> 

Alissa, I'm starting to think that SLAAC is analogous to diesel engines. Everyone thought it was a great idea for the longest time, and now it's getting a bad rap.

The requirement in Section 3 #1 still has to hold, for any form of stable address developed with SLAAC, I would think. If one reboots the host, the address on that subnet has to reappear as it was before. If you drop the requirement, people will just assume that it's obvious anyway, I would think.

Bert

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 21 May 2016 10:40:15 +0900

On Sat, May 21, 2016 at 6:06 AM, Alissa Cooper <[email-masked]> wrote:

> (e.g., by implementing 7217 and using the randomized MAC as the Net_Iface
> parameter)

An implementer can't do that because it would be a violation of RFC 7217,
which explicitly defines Net_Iface as "An implementation-dependent stable
identifier". (The key word here being "stable").

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 May 2016 17:44:30 +1200

> To my eye this is a nice compromise.

Unfortunately I'm not sure it would change anything. The requirement 1 property
seems to be exactly what a site operator who wants stable addresses will need.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 May 2016 20:37:40 -0400

On 05/19/2016 02:10 AM, Lorenzo Colitti wrote:
> On Thu, May 19, 2016 at 2:19 PM, Alissa Cooper <[email-masked]
> ephemeral would address the privacy concerns just as well as (or maybe
> even better) than the approach proposed in this document.
> 
> I think what people are do not understand is why this document
> recommends one but not the other. I certainly don't.
> 
> Cheers,
> Lorenzo
> 

1) Do you have data to back the claim that such traffic is uncommon?

2) As noted by Brian, this was just an example. You cannot tell e.g.
what other protocols will do in the future, where they might also embed
the same link-layer address, etc.

3) Your approach wastes 18 bits of entropy for no reason. RFC7217 doesn't

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 May 2016 18:49:34 -0400

On 05/20/2016 02:19 AM, Lorenzo Colitti wrote:
> On Fri, May 20, 2016 at 11:18 AM, Brian E Carpenter

This draft does not say and never say that. Please stop saying that, or
quote the offending text, such that we remove it, and we can make progress.

Ok?

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Sat, 21 May 2016 11:16:11 -0400

> days to see whether it has any negative impact at all. So far, so good.

This is a key test: Open a bunch of ssh sessions, and check if they
break overnight.

RFC4941 would make them break. That's an interoperability problem that,
in the general case, you don't want to have, I think.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Sun, 22 May 2016 11:48:35 +1000

> in the general case, you don't want to have, I think.

I think there would be a lot of very persistent connections (e.g.,
last weeks and months) within Enterprise networks that aren't typical
on the Internet e.g., long lived connections between database clients
and servers, where the database client in this example is part of the
application middle tier.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 May 2016 14:10:44 +1200

>> in the general case, you don't want to have, I think.

Well, my SSH sessions seem to time out anyway, because the server end
is unhappy about long sessions with no traffic. Look, it all depends on
the user scenario. It's pretty clear that for casual (coffee shop or
such like) use stable addresses are pointless. But for any scenario
with connections that might last for days, it's different.

Anyway, my point is that this is an issue with RFC4941. Since your draft
is an if statement with no else clause:
 if stable_address_wanted
   then RFC7217
issues in RFC4941 are out of scope.

> and servers, where the database client in this example is part of the

Yes. In that case stable_address_wanted == True.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 22 May 2016 13:20:45 +0900

>    document simply improve the security and privacy properties of

+1 to Jinmei's proposed text.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 22 May 2016 13:23:56 +0900

> quote the offending text, such that we remove it, and we can make progress.

Let me restate it again: the draft says "hosts SHOULD use RFC7217 when they
would otherwise have configured a stable IID". By my reading, that is
equivalent to saying "hosts SHOULD use RFC7217 all the time", because
currently hosts MUST configure stable IIDs all the time.

I already proposed a solution: say that generating a stable IID is OPTIONAL.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 22 May 2016 19:17:30 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti

> Let me restate it again: the draft says "hosts SHOULD use RFC7217 when
> they would otherwise have configured a stable IID". By my reading,
> that is equivalent to saying "hosts SHOULD use RFC7217 all the time",
> because currently hosts MUST configure stable IIDs all the time.

That's not stated in this draft, though. This draft only applies to hosts which must use stable addresses. It doesn't talk about anything else. As a matter of fact, the use of stable addresses has already been de-emphasized in this draft, by this text:

   Furthermore, some popular IPv6 implementations have already deviated
   from the traditional stable IID generation scheme to mitigate the
   aforementioned security and privacy implications [Microsoft].

   As a result of the aforementioned issues, this document changes the
   default IID generation scheme for SLAAC to that specified in
   [RFC7217], and recommends against embedding link-layer addresses in
   IPv6 Interface Identifiers, such that the aforementioned issues are
   mitigated.  That is, this document simply replaces the default
   algorithm that must be employed when generating stable IPv6 IIDs.

So this tangential discussion, a "side bar" wrt this draft, should be left at that, as far as I'm concerned.

> I already proposed a solution: say that generating a stable IID is

That point should be made, if anywhere at all, in RFC 2460-bis. Not here. Why not here? Because those who read this draft couldn't care less. They are reading this draft only because they know they want stable addresses. That introductory paragraph says as much as needs to be said, I think, about this side bar discussion.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 May 2016 01:36:21 -0400

Lorenzo,

On 05/20/2016 03:20 AM, Lorenzo Colitti wrote:
> On Fri, May 20, 2016 at 4:04 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Everything has to be read in context. My reading of this document is
>     that it says what an implementation SHOULD do _iff_ a stable IID is
>     to be generated. It says nothing about what to do if a stable IID is
>     not required.
> 
> 

Your assessment is kind of correct.

Note, that we noted multiple times that what we try to do with this
document is to improve stable addresses, and that we're not changing any
requirements regarding whether one should configure stable addresses in
the first place.

You're asking this document to do more than what it was meant to do.
That's not a bad thing. But this is not the document to blame for the
"requirement to configure stable addresses". If anything, we're just
relaying the requirement that's in RFC2464 and RFC4941.

>    containing a link layer address. Configuring a stable IPv6 IID is

I'm not necessarily opposed to your text. Actually, I think making
stable addresses optional could be a good thing for scenarios (e.g.,
roaming/coffee store) where you might live without them.

However, please note this is a different change from the one we have
been pursuing with this document. I'm not saying that I'm opposed to the
change, nor that I'm opposed to "augment" this I-D to relax the
requirement regarding stable address. I'm just saying that this I-D was
not meant to do that.

I guess a document that gets rid off stable addresses should analyze the
tradeoffs involved, and the possible implications. e.g., relying on
temp-only could make long-lived ssh connections fail, and a requirement
of "OPTIONAL" would mean that that's just fine.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 May 2016 01:39:22 -0400

On 05/20/2016 03:04 AM, [email-masked] wrote:
>>> Let's all always keep in mind that the current text of the draft
>>> says that on every network, hosts SHOULD configure an IPv6
>>> address that never changes until the end of time. I think that
>>> recommendation is irresponsible.
>> 
>> Thus, I'm continuing to run my laptop with only an RFC4941 address
>> for a few days to see whether it has any negative impact at all. So
>> far, so good.
>> 

It turns out that Lorenzo wants this I-D to make an additional change:
flag stable addresses as optional. Currently, such a change is out of
the scope for this document.

I'm not saying that this dcument should not make that change or the
like... but rather noting that Lorenzo concern is not really about what
this document is meant to do (improve stable addresses *if* you're going
to configure one).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 May 2016 15:40:52 -0400

> To my eye this is a nice compromise.

That's a bad idea.

The reason why is  draft-gont-predictable-numeric-ids-00, RFC4941, and
even some RFC (?) by the IAB.

The root of this whole problem is embedding a layer-2 id in a layer-3
field in the first place.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 May 2016 15:53:52 -0400

On 05/22/2016 12:23 AM, Lorenzo Colitti wrote:
> On Sat, May 21, 2016 at 7:49 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> they would otherwise have configured a stable IID". By my reading, that
> is equivalent to saying "hosts SHOULD use RFC7217 all the time", because

This goes beyond what this document was meant to do. BUt if the wg wants
this document to also do that, I'm fine. I guess that if we were to do
that, this document now also needs to update RFC4941, or can we keep it
otherwise "as is"?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 May 2016 16:04:34 -0400

Jinmei,

On 05/20/2016 12:04 PM, 神明達哉 wrote:
>>> Thus, I'm continuing to run my laptop with only an RFC4941
>>> address for a few days to see whether it has any negative impact
>>> at all. So far, so good.
>>> 
>> Everything has to be read in context. My reading of this document
>> is that it says what an implementation SHOULD do _iff_ a stable IID
>> is to be generated. It says nothing about what to do if a stable
>> IID is not required.
>> 
> is only for environments where address stability is needed".

FWIW, that's fine with me (including Lorenzo's suggestion of
"OPTIONAL"). The only thing I tried to note is that saying so goes
beyond the original intent of this ID: we were just improving stable
addresses, without saying any word regarding whether you should use
them, whether they are optional, or whatever.

>  The 
> for environments where address stability is needed".

We were not saying that because the current specs say/assume that they
are always needed, and "changing" that was ging one step further. That
said, I'm not opposed to this document going that step further.

>  So I tried to 
> subsequent discussions only introduced more confusion for me
> (because of discussions on other points like whether using
> randomized link-layer address is "extremely bad").

That's orthogonal. Again, please read:
draft-gont-predictable-numeric-ids-00

> suggest revising the above paragraph as follows:

Yes, that's the intent of this I-D (but please note my comment above
regarding the *current* specs assumming stable addresses are always there).

> containing a link layer address.  For example, this document does not
> addresses as specified in [RFC4941], nor do the recommendations apply
> to cases where the link layer address is not stable (e.g., it is
> periodically randomized) in the first place, nor does it introduce
> any new requirements regarding when stable addresses are to be
> configured.

The root of this problem is reusing a link-yaer ID at layer-3. THat's
bad, and we have to recommend against that.

Brian already provided an example of IPv6/IPX traffic correlation... and
there could be other protocols reusing the MAC address which, even if
randomized, allows for correlation.

REusing IDs a different places, ifor different scopes, etc., is bad, and
is the root of all of this. Please check:
draft-gont-predictable-numeric-ids-00

> stable IID is to be generated and does not make any judgment on,
> e.g., use of randomized link-layer addresses, this proposed text
> shouldn't be a problem for anyone. 

We don't care about what you do at layer-2. Randomie as much as you
want. Just don't include layer-2 IDs in layer-3 IIDs.

> randomized link-layer addresses.

I'm fine with layer-2 adddr randomization. Could even consider myself
and advocator of that (in a number of scenarios). HOwever, I'm against
reusing numeric IDs in different places, for the reasons stated above.

Thughts?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 May 2016 16:13:38 -0400

> and servers, where the database client in this example is part of the

*Exactly*. S, the question is: can we really flag stable addresses as
optional when such connections might break as a result of that? aybe we
should note that if we flag them as optional?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 May 2016 16:11:49 -0400

On 05/21/2016 10:10 PM, Brian E Carpenter wrote:
> is unhappy about long sessions with no traffic. 

The question is (*question*, not objection) is whether one can really
say that stable addresses are optional when using temp addresses only
might cause w.g., breakage of ssh sessions.

> Look, it all depends on

*Exactly*!

Cheers,

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 May 2016 10:12:08 +0900

> field in the first place.

No, the root of this whole problem is embedding a *stable* layer-2 ID in a
layer-3 field.

---

From: [email-masked]
Date: Mon, 23 May 2016 09:59:37 +0200

[...]

> the "extremely bad" comment.

I think we have an assumption embedded in most of our documents that a stable IID is generated on all interfaces.
I don't think this document is the place to to clarify that there might be interfaces with only short-lived IIDs.

This document tries to improve the security and privacy of the default IID generation mechanism. I think it is clear on that. It's in the title, it is in the abstract. I'm not sure how much clearer it is possible to make it.

The other consequence of this document is that it forces changes in implementations that don't necessarily benefit from the privacy improvements. Public servers, router interfaces and so on. Is a consequence of updating 2464 that I now have to go and retrofit 7217 style IID generation in lots of code? I'm not sure I want to accept the collateral damage.

> we should be at least clear on this in the document text.

With regards to random MAC addresses, I see the arguments that we in general shouldn't couple the L3 address with the L2 address.
In that aspect randomized MAC should not have any implication on this document.
On the other hand I do see how it would make for a very easy implementation change to do random MACs (which you probably have to do on certain devices anyway), and keep the current IID generation mechanism.

I have to admit that I'm unsure of what the right thing to do is. I'm uncomfortable with removing the existing mechanism from all the IPv6 over foo documents. I'm not convinced that we are in a position to make a recommendation for all scenarios and all devices at this point.Î

cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 23 May 2016 11:13:20 +0200

Le 22/05/2016 à 22:04, Fernando Gont a écrit :
[...]

> and advocator of that (in a number of scenarios). HOwever, I'm
> against reusing numeric IDs in different places, for the reasons
> stated above.
>
> Thughts?

Do you think of other reasons than privacy for not including numeric
IDs in different places (e.g. use L2 address in L3 address)?

(privacy may be a valid reason; but hybrid addresses mixing IDs from
different layers is common elsewhere, wonder why opposing)

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 23 May 2016 11:16:57 +0200

Le 23/05/2016 à 03:12, Lorenzo Colitti a écrit :
> On Mon, May 23, 2016 at 4:40 AM, Fernando Gont <[email-masked]
> No, the root of this whole problem is embedding a *stable* layer-2 ID in
> a layer-3 field.

We can move away from this problem by increasing the size of that 
layer-2 ID (rather than destabilizing it) such that it no loger fits 
into a layer-3 address.

Alex

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 May 2016 07:59:53 -0400

> No, the root of this whole problem is embedding a *stable* layer-2 ID in

You're wrong. I've provided references that explain why, and Brian has
provided examples. There's not much I can do other than that.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 May 2016 00:41:29 +0900

> provided examples. There's not much I can do other than that.

Instead of telling me I'm wrong, I would suggest convincing the WG that I'm
wrong, because if you do, it doesn't matter what I think.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 May 2016 11:51:54 -0400

Lorenzo,

On 05/23/2016 11:41 AM, Lorenzo Colitti wrote:
> On Mon, May 23, 2016 at 8:59 PM, Fernando Gont <[email-masked]
> Instead of telling me I'm wrong, I would suggest convincing the WG that
> I'm wrong, because if you do, it doesn't matter what I think. 

The fact that your scheme wastes 18 bits of entropy, and requires that
only a single layer-3 protocol is used, and only a single IPv6 prefix is
employed (so that its exploitation for correlation does not become
obvious) shows that the scheme is flawed, and that the scheme itself is
what allows for correlation.

My apologies for my writing style. My goal is not to prove you wrong.
But rather than there's a reason for not wanting the layer-2 id in the
IPv6 address.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 May 2016 11:51:09 +1200

Alex,
On 23/05/2016 21:13, Alexandre Petrescu wrote:
...
> different layers is common elsewhere, wonder why opposing)

Well yes, it seems to be that we have all followed the OSI method,
where a TSAP is an NSAP+something, etc. But that isn't actually a
rqeuirement of the OSI model, iirc. Privacy would indeed argue for
a layer N+1 address not to be a simple extension of a layer N address.
That was not a big consideration in the past, unfortunately.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 24 May 2016 10:55:00 +0200

Le 24/05/2016 à 01:51, Brian E Carpenter a écrit :
> Alex, On 23/05/2016 21:13, Alexandre Petrescu wrote: ...
>> (privacy may be a valid reason; but hybrid addresses mixing IDs
>> from different layers is common elsewhere, wonder why opposing)
>
> rqeuirement of the OSI model, iirc. Privacy would indeed argue for a
> layer N+1 address not to be a simple extension of a layer N address.

Is it only about [N; N+1] or also about [N; N] (e.g. an IPv6 address 
embedding an IPv4 address)?

Alex

---

From: "weigengyu" <[email-masked]>
Date: Wed, 25 May 2016 10:58:29 +0800

Hi Fernando,

Would you please provide the published refereces of Alfred Hoenes -- IIRC, a 
mathematician.
IIRC, he noted that a hash function is simply one possible way of a PRF.

It is interested for the proof of Hash function to be a PRF.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Fernando Gont
Sent: Wednesday, May 18, 2016 10:19 AM
To: Brian E Carpenter ; weigengyu
Cc: [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-11.txt

On 05/16/2016 04:08 PM, Brian E Carpenter wrote:
> You could submit an erratum for RFC 7217 at 
> http://www.rfc-editor.org/errata.php#reportnew

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 May 2016 16:27:41 +1200

A few years ago I found that the academic literature on hash functions seems
extremely weak. Actually a very good theoretician of randomness that I know
referred me to a paper from 1951*. Most of the "literature" appears
to be experimental results ("this algorithm seems to work better than
that algorithm").

http://www.isthe.com/chongo/tech/comp/fnv/index.html for example.

Regards
   Brian

* J. von Neumann, Various techniques used in connection with random digits, National
Bureau of Standards Applied Math Series 12, 36-38, 1951.

On 25/05/2016 14:58, weigengyu wrote:
> Hi Fernando,
> 
> Would you please provide the published refereces of Alfred Hoenes -- IIRC, a mathematician.
> -----原始邮件----- From: Fernando Gont