Subject: draft-gont-6man-managing-privacy-extensions-00.txt

From: Ran Atkinson <[email-masked]>
Date: Wed, 9 Mar 2011 05:01:39 -0500

<http://www.ietf.org/internet-drafts/draft-gont-6man-managing-privacy-extensions-00.txt>

I recommend that folks read the above draft.  I haven't seen the
I-D announcement get cross-posted to the IPv6 WG, perhaps due to
the volume of recent I-D postings, and the topic seems relevant.

Cheers !

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 9 Mar 2011 12:17:05 +0100 (CET)

> the volume of recent I-D postings, and the topic seems relevant.

I don't think it solves what it thinks it solves, but if this REALLY 
should be implemented, it's my initial thinking that the H flag should be 
a MUST demand to only have ONE and only one MAC-based IPv6 address 
according to EUI64. I would appreciate some reasoning in the draft why 
this was chosen as a SHOULD option.

I do not like the "disable Privacy"-flag thinking at all and I really 
oppose going with that solution.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: huabing yu <[email-masked]>
Date: Wed, 9 Mar 2011 20:19:28 +0800

2011/3/9 Mikael Abrahamsson <[email-masked]>

>> <
>> http://www.ietf.org/internet-drafts/draft-gont-6man-managing-privacy-extensions-00.txt
>> >
>>
> I don't think it solves what it thinks it solves, but if this REALLY should
> be implemented, it's my initial thinking that the H flag should be a MUST
> demand to only have ONE and only one MAC-based IPv6 address according to
> EUI64. I would appreciate some reasoning in the draft why this was chosen as
> a SHOULD option.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

(1)If "H" ("Hardware-derived addresses") flag is 1, it indicates that
the host SHOULD generate hardware-derived addresses, and doesn't
generate privacy addresses.
(2)If "H" ("Hardware-derived addresses") flag is 0, the author say that
this bit indicates that Privacy Extensions SHOULD be enabled
when configuring IPv6 addresses as a result of Stateless Address
Autoconfiguration,
*but many people will think that it indicates that the host doesn't
generate *
*hardware-derived addresses, and SHOULD generate privacy addresses. It may *
*result in a misunderstanding.*
*I think "DisablePrivacy" proposed by "draft-yhb-6man-ra-privacy-flag-01"*
*is better than "H",although some people don't like the problem to be
solved.*
*
*
*Yu Hua bing*

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 9 Mar 2011 15:57:11 +0100 (CET)

> generate privacy addresses.

I think it should indicate that ONLY hw-derived address should be created, 
which by defintion is only ONE, and not more, and this is the ONLY one.

> *is better than "H",although some people don't like the problem to be

Well, I don't think the problem is solved by these proposals, but if the 
RA standard should be changed, then I want the solution to be what I wrote 
before.

SLAAC means the host can take any address it wants as long as it's not 
already in use. Privacy Extensions is not the only mechanisms that might 
create an address to be used, thus I think the "disable privacy" flag is 
meaningless.

If you want to know the mac address of the computer who used an IP address 
at a certain time, then you need to tell the host to only use EUI64 based 
address and nothing else, you don't tell it to disable privacy extensions. 
Just because privacy extensions is the only address widely seen today as 
being non-EUI64, doesn't mean that if you disable privacy, you get only 
single EUI64.

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 9 Mar 2011 10:51:59 -0500

On 09  Mar 2011, at 09:57 , Mikael Abrahamsson wrote:
> Privacy Extensions is not the only mechanisms that might create an
> address to be used, thus I think the "disable privacy" flag is meaningless.
> 
> If you want to know the mac address of the computer who used an
> IP address at a certain time, then you need to tell the host
> to only use EUI64 based address and nothing else, you don't tell it
> to disable privacy extensions.
> 
> Just because privacy extensions is the only address widely seen
> today as being non-EUI64, doesn't mean that if you disable privacy,
> you get only single EUI64.

The above is a very helpful clarification.  

Based on that, I agree with Mikael that the correct semantic 
to the flag should be to require direct/embedded use of a 
hardware MAC value for the IPv6 IID.  That would disallow 
not only the (pseudo-)Privacy addresses, but any other kind 
of addressing that would not embed a hardware address in the IID.

REQUEST for Fernando G/Ron B:
	Separately, keeping the quoted comments above in mind, the I-D
	draft-gont-6man-managing-privacy-extensions needs clarification 
	edits to avoid using the phrase "hardware-derived" anywhere.

REASON:
	Any (pseudo-) Privacy address is derived ("computed") using the 
	MAC address as a seed (at least originally). [RFC-3041, Seection 3.2]

	So it is confusing and not clear to say "hardware-derived",
	when one means that the system ought to only use IIDs that
	are embedded IEEE MAC addresses (whether 802, Firewire, or BlueTooth)
	or some other embedded hardware address type.

Cheers,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Mar 2011 07:49:29 +1300

On 2011-03-10 00:17, Mikael Abrahamsson wrote:
> should be implemented, it's my initial thinking that the H flag should
> be a MUST demand to only have ONE and only one MAC-based IPv6 address

For the reason I just gave against the disable-private flag: this
violates the host's right to use an untraceable address.

It may be that in corporate deployments, that right can be removed.
But removing it for public subscribers would be a political blunder.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Wed, 09 Mar 2011 11:08:04 -0800

> the volume of recent I-D postings, and the topic seems relevant.

About the H-bit in the PIO it proposes, the draft says this:

   When set, this bit indicates that
   hardware-derived addresses SHOULD be used when configuring IPv6
   addresses as a result of Stateless Address Autoconfiguration.  When
   not set, this bit indicates that Privacy Extensions SHOULD be enabled
   when configuring IPv6 addresses as a result of Stateless Address
   Autoconfiguration

Which makes the bit worse than useless.  If the PIO contains A=1, then both EUI-64 and privacy IID are eligible under the current regime, but this draft says only that one or the other SLAAC alternative SHOULD be used depending on the state of the bit, without explicitly saying whether the complementary alternative SHOULD NOT be used.

I'm not sure if the intent is to make a signal for hosts that network administration regards any particular SLAAC alternative as NOT RECOMMENDED, but if it is, then the draft should explicitly say so.  Of course, if the draft were to changed to do that, then I would lodge the same complaints that I lodged previously against I-D.yhb-6man-ra-privacy-flag... for the same reasons.

This draft has a long struggle ahead of it, if you ask me.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 9 Mar 2011 14:17:12 -0500

> violates the host's right to use an untraceable address.

(Hardware I am familiar with is not sentient.  So I don't know 
what it means to talk about the rights of a host, as above ---
I'll assume the meaning is that human users have privacy rights. :-)

> It may be that in corporate deployments, that right can be removed.

At least within the US, I am told that multiple courts have ruled 
that when an employee is using employer-owned equipment attached 
to an employer-owned network, then a reasonable expectation of 
privacy does not exist.  My examples and discussion have solely
focused on this "corporate deployment" scenario.

[ASIDE:  I am also told that the courts have ruled differently with 
respect to people accessing the Internet from their own home when 
using their own equipment.]

[ASIDE: Of course the IETF is global; legal systems vary from one place
to another.  So the above is intended narrowly as a practical example. :-]  

> But removing it for public subscribers would be a political blunder.

Earlier, I specifically noted that the privacy issue ought to be 
discussed in the Security Considerations section of (any) I-D on 
this topic, in (2A) and (2B) of this previous list email:

	<http://www.ietf.org/mail-archive/web/ipv6/current/msg13489.html>

Cheers !

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Mar 2011 14:32:45 -0500

I would observe that we have multiple documents which note the 
importance of traceability for "problem" resolution.  Treating privacy 
as an all-or-nothing thing is probably a misleading perspective.
It is extremely likely that privacy addresses, and their bindings to 
homes or office desktops, will be logged.  I would hope that said logs 
will be handled in a manner that preserves privacy in the normal course 
of events.

Pretending that such things will not happen strikes me as even sillier 
than assuming that a malicious host will cooperate with some unenforced 
flags.

Yours,
Joel

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Mar 2011 06:43:28 +1030

On Wed, 09 Mar 2011 14:32:45 -0500

> than assuming that a malicious host will cooperate with some unenforced 

I also think there is a fundamentally incorrect assumption is being
made - that IPv6 addresses and humans are tightly coupled. An IPv6
address identifies an end-node, and the traffic to or from it, but does
not always identify the human that caused that traffic to occur. If you
truly need auditable access/traffic logs, you need to identify the
human at the time via "human-facing" authentication methods e.g.
802.1x.

IOW, machines (and their IPv6 addresses) aren't really the security
threat, it's the people behind them.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Mar 2011 07:14:58 +1030

Hi Ran,

On Wed, 9 Mar 2011 10:51:59 -0500

> of addressing that would not embed a hardware address in the IID.

That may have unintended consequences. If a hardware address isn't
available, IIDs can be generated randomly, so if this flag was
properly obeyed, these random IID end-nodes should not acquire
addresses.

An example of where this might matter is on a large scale PPP
deployment. If an ISP switched this flag on in the RAs it sends over PPP
sessions on the BRAS, and the CPE PPP implementations did not use
hardware derived IIDs (i.e. sourced from another interfaces), the PPP
session may not come up. Another property of IPV6CP is to negotiate
IIDs, to overcome collisions if they occur. On a BRAS, the scope of the
collision detection may not only be within a single PPP session, but
across all of them, which may number in the 10s of 1000s.

Taking a step back, I'm wondering what the actual problem with privacy
addresses is - neither of the drafts have specifically said. Is it that
they're a random, non-hardware derived IID, or is it that they're
random, non-hardware derived IID and that they change over time?

If hardware derived IIDs are enforced, there aren't any guarantees that
the underlying hardware address isn't random either, or won't be made
so intentionally by somebody who wants to preserve their network layer
anonimity. Temporarily changing MAC addresses on Ethernet cards is easy
if you've got admin access to an OS (or at least, on Windows and Linux
it is, not sure about Mac OS X).

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Mar 2011 07:19:25 +1030

On Thu, 10 Mar 2011 07:49:29 +1300

> But removing it for public subscribers would be a political blunder.

I agree. I sort of accept that an ISP can know my addresses in use, in
part because they gave them to me. However, for an ISP to not let me
choose if I want to use privacy addresses on the Internet would
be completely unacceptable.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Mar 2011 15:15:08 +1300

> be completely unacceptable.

Right, and since that sentiment is shared by the human hosts of
millions of Internet hosts, we have to make sure that our standards
allow for it. Of course, there will be situations where local laws
don't grant a right to privacy, but we need to be sure that IETF standards
allow for the preservation of privacy. That has been established as a
pretty strong consensus in the IETF a number of times.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Mar 2011 23:34:13 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Wednesday, March 09, 2011 10:49 AM
> To: Mikael Abrahamsson
> Cc: [email-masked]; Ran Atkinson
> Subject: Re: draft-gont-6man-managing-privacy-extensions-00.txt
> 

Nobody wants it removed in corporate deployments, either.  Consider
for a moment an IPv6-enabled telephone, on the desk of a Very 
Important Person at a company, who is calling the CEO of some
Itty Bitty Company.  And then the CEO calls.  Then someone on
the acquisition team calls.  It hardly matters what they're talking 
about -- just seeing that traffic with those IPv6 addresses is
sufficient to decide to buy (or sell) stock in Itty Bitty 
Company.  

We should, instead, look at how a host's privacy address can
be reported and recorded, so the network administrator has all
the necessary ability to determine which host is using which
address now or in the past.  This is easily done -- without 
changing RA.

If we don't have IPv6 privacy addresses, we will also soon
see NAPT66 (with UDP and TCP port rewriting) in order to 
achieve the same result as privacy addresses:  trying to 
obfuscate which host is communicating.

-d

---

From: Ran Atkinson <[email-masked]>
Date: Thu, 10 Mar 2011 07:10:05 -0500

On 10  Mar 2011, at 02:34 , Dan Wing wrote:
> Nobody wants it removed in corporate deployments, either.  

That statement is far too strong; it simply is not true.

> Consider for a moment an IPv6-enabled telephone,
> on the desk of a Very Important Person at a company, ...

(Laugh.  I don't believe in that untrue example for a second,
but thanks for the humorous start to my morning.  :-)

Oh, and consider that Caller-ID, usually including a full name,
is already widely deployed in many countries.  It is so
much simpler just to read the Caller-ID string off of the
telephone handset.  

If one wants to intercept traffic, it is MUCH simpler to intercept 
the SIP traffic -- which is never encrypted in real-world corporate 
deployments because that would make VoIP too hard to debug.

> obfuscate which host is communicating.

It seems pretty clear that Fred's NPTv6 is going to be
deployed in at least some locations, albeit for entirely 
different reasons.  I'm not sure if that meets your 
definition of NAPT66 or not.

Cheers,

Ran

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 10 Mar 2011 07:36:11 -0800

> obfuscate which host is communicating.

+1.  Assume media and signalling are encrypted, node to node communication
can still reveal a lot.

Cb

---

From: james woodyatt <[email-masked]>
Date: Thu, 10 Mar 2011 08:02:06 -0800

On Mar 10, 2011, at 4:10 AM, Ran Atkinson wrote:
> 
> It seems pretty clear that Fred's NPTv6 is going to be deployed in at least some locations, albeit for entirely  different reasons.  I'm not sure if that meets your definition of NAPT66 or not.

It does not.  NPTv6 only translates the network prefix; it therefore doesn't prevent global tracking of hosts that use EUI-64 interface identifiers.

---

From: Paul Chilton <[email-masked]>
Date: Thu, 10 Mar 2011 19:18:12 +0100

Doesn't a combination of RFC4941 and NPTv6 produce the necessary privacy over both parts of the IPv6 address? 
(BTW thats a question from an interested observer new to this topic, not a statement - I started following this thread and ended up digging around in the RFCs and drafts the thread uncovered)

Paul Chilton
Low Power RF Solutions (formerly Jennic)
NXP Semiconductors

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Mar 2011 11:53:12 -0800

> Ran Atkinson
> Sent: Thursday, March 10, 2011 4:10 AM
> To: [email-masked]

Laughing at IPv6, or an IP telephone on someone's desk, or
the combination of the two?

> deployments because that would make VoIP too hard to debug.

Ergo, we should let it all hang out?

We have many customers which enable encryption on their IP PBXs.
All of our telepresence systems ship with encryption enabled 
by default (both signaling and media).

If you didn't like the SIP example, is SIP the one and only case 
where an IPv6 privacy address is useful?

> definition of NAPT66 or not.

It doesn't; NPTv6 does not provide obfuscation of the endpoint,
because it only rewrites the IPv6 prefix.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Mar 2011 11:57:25 -0800

> Sent: Thursday, March 10, 2011 10:18 AM
> To: james woodyatt
> Cc: [email-masked]
> Subject: RE: draft-gont-6man-managing-privacy-extensions-00.txt
> 
> Doesn't a combination of RFC4941 and NPTv6 produce the necessary
> privacy over both parts of the IPv6 address?
> (BTW thats a question from an interested observer new to this topic,
> not a statement - I started following this thread and ended up digging
> around in the RFCs and drafts the thread uncovered)

RFC4941 by itself does the trick.

But draft-gont-6man-managing-privacy-extensions (the subject of
this thread) says "you can't use RFC4941".

I'm saying the reasons people are tempted to disable RFC4941 are
misplaced.  Really, they want the same tracking of 
which-host-is-using-which-address that they have, today, with
DHCPv4 (by examining the DHCP server's logs) and have, today,
with DHCPv6 (by examining the DHCPv6 server's logs).  Thus the
desire to simply throw away RFC4941 (sorry, "disable on this 
network") is misplaced.  We should devote our energies 
elsewhere and provide the means to log use of a SLAAC address.

-d

> james woodyatt
> > It seems pretty clear that Fred's NPTv6 is going to be deployed in at
> least some locations, albeit for entirely  different reasons.  I'm not
> sure if that meets your definition of NAPT66 or not.
> 
> It does not.  NPTv6 only translates the network prefix; it therefore
> doesn't prevent global tracking of hosts that use EUI-64 interface
> identifiers.
> 
> 
> --

---

From: Christian Huitema <[email-masked]>
Date: Fri, 11 Mar 2011 02:32:32 +0000

> I'm saying the reasons people are tempted to disable RFC4941 are misplaced.  

+1

Consider that if I want privacy and you won't let me use RFC4941, I might just make up a new MAC address each time I connect.

Consider also the effect of unique identifiers on tracking. The MAC address follows you when you roam. By embedding it in the IPv6 address, we are effectively offering a "super cookie" to all web services. Is it really what we want? In addition to privacy issues, displaying the MAC address allows third parties to track hardware purchase, and enables other attacks by providing the data necessary for MAC spoofing. In short, it looked like a great idea at the time... but wasn't.

-- Christian Huitema

---

From: Doug Barton <[email-masked]>
Date: Thu, 10 Mar 2011 18:53:29 -0800

On 03/09/2011 06:57, Mikael Abrahamsson wrote:
> If you want to know the mac address of the computer who used an IP
> address at a certain time, then you need to tell the host to only use
> EUI64 based address and nothing else, you don't tell it to disable
> privacy extensions. Just because privacy extensions is the only address
> widely seen today as being non-EUI64, doesn't mean that if you disable
> privacy, you get only single EUI64.

Right. When I was at Yahoo! we had a db of mac addresses of authorized 
hosts, and used that to drive configuration of the switches, dhcp, dns, 
etc. that way we could be sure that only authorized hosts had access to 
the network. If you don't manage access at the switch level, you can't 
guarantee what the client is going to do, regardless of what flags are 
sent in SLAAC.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Thomas Narten <[email-masked]>
Date: Fri, 11 Mar 2011 07:51:29 -0500

Mark Smith <[email-masked]> writes:

> made - that IPv6 addresses and humans are tightly coupled.

Actually, if you look at trends, they are increasingly tightly
coupled.

Internet access by humans is increasingly through single-owner devices
(recently laptops, but increasingly smart phones and the like, which
are typically single-owner). Indeed, I've seen projections that assert
that sometime this year more people will access the Internet though
Mobile Wireless devices than through traditional computers. The
primary method of Internet access is changing...

> An IPv6 address identifies an end-node, and the traffic to or from
> it, but does not always identify the human that caused that traffic
> to occur.

True, but if it correctly identifies the human in 70, 80, or 90% of
the cases, that's likely good enough for "innovation" to move in and
exploit such characteristics.

Up levelling, this draft simply reopens a discussion that was had back
when stateless addrconf was first defined. Today, there is no easy way
for the network adminstrator to "configure" clients. When stateless
addrconf is used, there are pretty much no mechanisms for
communicating network preferences or policy.

Allowing/disallowing temporary addresses is one instance of a broader
problem. Another example of policy that would be useful to commnicate
is address selection preferences. Hence, if we are going to define
something like an "H bit", we should really look at the more general
problem.

And, even if there was a mechanism for the network to communicate its
preferences/policies, we'd still have the problem that end hosts could
simply ignore or override those preferences. 

There is no good/easy/simple answer here folks.

Thomas

---

From: Mark Townsley <[email-masked]>
Date: Fri, 11 Mar 2011 13:53:58 +0100

> elsewhere and provide the means to log use of a SLAAC address.

In addition to the logging, don't forget the MAC-IP mappings in switches (SAVI) and wi-fi access points (AP roaming). Talking with our friends at Microsoft, their recommendation was to plan for accommodating 9 IPv6 addresses per interface for hosts with privacy addressing (vs. one of course for IPv4). None of that is rocket science, nor beyond our ability to build hardware for, but it certainly doesn't help the IPv4 vs. IPv6 cost equation at these points in the network :-/

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 11 Mar 2011 14:01:57 +0100

> Consider also the effect of unique identifiers on tracking. The MAC address follows you when you roam. By embedding it in the IPv6 address, we are effectively offering a "super cookie" to all web s…

One person's attack is another's targeted ad business case ;-)

That aside, the considerations proposed in this document may be relevant to this discussion:

http://tools.ietf.org/html/draft-brim-mobility-and-privacy-00

- Mark

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2011 07:56:36 -0300

Hi, Mikael,

On 09/03/2011 08:17 a.m., Mikael Abrahamsson wrote:
> according to EUI64. 

Not sure what you mean... If H is set, why should we prevent generation
of MAC-based addresses of different scopes?

> I would appreciate some reasoning in the draft why

Because a "SHOULD" allows the host to override this policy if it has
good reasons to do so.

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, 12 Mar 2011 08:04:39 -0300

> *result in a misunderstanding.*

I don't really follow the potential misunderstanding. Anyway see version
-01 of the document (that I've just posted).

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2011 08:06:39 -0300

On 09/03/2011 11:57 a.m., Mikael Abrahamsson wrote:

> privacy extensions. 

This was exactly the rationale for the "H" bit in version -00 of the
document. And the current version (-01) follows the same principle.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2011 08:09:00 -0300

Hi, Ran,

> of addressing that would not embed a hardware address in the IID.

Will clarify this in the next rev of the document.

> 	edits to avoid using the phrase "hardware-derived" anywhere.

Will do.

> 	or some other embedded hardware address type.

Will do. And will reference the corresponding RFCs (EUI-64 stuff).

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2011 08:11:56 -0300

> But removing it for public subscribers would be a political blunder.

The requirements in draft-gont-6man-managing-privacy-extensions are
SHOULDs, for this very reason.

How about including some text that explicitly states that a host can
always override the desired policy (with a system toggle) if it desires
to do so?

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2011 08:29:24 -0300

> this was chosen as a SHOULD option.

I realize I misunderstood your comment.

The intention of the I-D is/was that if the "H" bit is set, you SHOULD
generate your addresses corresponding to this prefix ONLY with according
to EUI64.

The above requirement is a "SHOULD" (rather than a MUST), since a hosts
that has good reasons to do so (e.g., privacy concerns) is allowed to
override the policy specified by the router.

Thanks,

---

From: Scott W Brim <[email-masked]>
Date: Sat, 12 Mar 2011 10:14:25 -0500

On Fri, Mar 11, 2011 at 08:01, Mark Townsley <[email-masked]>
wrote:
>> misplaced.
>> Consider that if I want privacy and you won't let me use RFC4941, I
>> might just make up a new MAC address each time I connect.
>>
>> Consider also the effect of unique identifiers on tracking. The MAC
>> address follows you when you roam. By embedding it in the IPv6
>> address, we are effectively offering a "super cookie" to all web
>> services. Is it really what we want? In addition to privacy issues,
>> displaying the MAC address allows third parties to track hardware
>> purchase, and enables other attacks by providing the data necessary
>> for MAC spoofing. In short, it looked like a great idea at the
>> time... but wasn't.
>
> http://tools.ietf.org/html/draft-brim-mobility-and-privacy-00 - Mark

Since you called it out :-) ... I think less in terms of privacy than
confidentiality scopes.  Privacy is the right to withhold information.
Confidentiality is an agreement that a second party will honor your
wish for privacy from others, i.e. that information you give them will
not be given to others.  We give others information all the time,
including hardware addresses.  Confidentiality issues are at least as
important as privacy.

Forcing people to reveal information to a larger scope than they wish,
i.e. forcing loss of privacy, is a significant issue that must be
taken into account by everyone doing protocol work.  If we design our
systems so that non-privacy addresses used locally must be also be
used globally, we are designing away the possibility of both privacy
and confidentiality.  Requiring an end user to use a MAC or any
persistent identifier for all communications with everything else on
the Internet is probably illegal in an increasing number of countries
around the world.  (On the other hand, in some countries it is
probably illegal to NOT require it.)
However, it's perfectly legitimate to require an identifier within an
enterprise -- there is a confidentiality agreement.

How can the enterprise get the information it needs without requiring
users to give away privacy for other communications?  An algorithmic
mapping from a hardware identifier to a different one at the
enterprise boundary does not solve the problem, because (1) all those
problems around non-globalness of addresses/locators/identifiers, and
(2) that mapped identifier is also persistent, and usage can be
tracked.

Blue sky: Could the SP allow privacy addresses, at least for global
use, and log its own mappings between privacy addressses and MACs or
other persistent identifiers?  Then it can always trace back to
determine who did what if necessary.

Scott

---

From: [email-masked]
Date: Sat, 12 Mar 2011 17:08:31 +0100 (CET)

> determine who did what if necessary.

I'm sure service providers *could* do this. But it's probably not
significantly simpler than just assigning an address using DHCPv6
or Radius - so where's the incentive for the service provider to do
such logging?

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Sat, 12 Mar 2011 16:40:58 +0000

> Blue sky: Could the SP allow privacy addresses, at least for global use, and log its own mappings between privacy 
> addressses and MACs or other persistent identifiers?  Then it can always trace back to determine who did what if necessary.

That's more or less what Windows does by default. The persistent address is not derived from the MAC, but from a hash of the prefix and the MAC id. Like a privacy address, it does not expose the MAC. Unlike a privacy address, its lifetime is as long as the routers will allow. This means nodes have a stable address in the corporate network, and can be easily traced within that network. But they get different addresses when they move around, and cannot be easily traced by third parties.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Mar 2011 08:02:17 +1300

> always override the desired policy (with a system toggle) if it desires

Yes, I think so, clearly labelled as "Privacy Considerations".

Otherwise we'll just have a re-run of the Jasmine thread right here.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2011 21:25:09 -0300

Hi, Dan,

> this thread) says "you can't use RFC4941".

It doesn't. The I-D aims at allowing routers specify which policy they
want hosts to employ when generating their IPv6 addresses.

Version -01 of the document probably makes this even more clear: the
router can actually advice nodes to use privacy addresses. -- As an
example, please note that while some stacks implement "privacy
extensions", they do not enable them by default. Thus, use of the
mechanism specified in this document could result in those boxes
*enabling*¨privacy addresses (if desired).

This document aims to improve the ability of the network administrator
of managing the generation of IPv6 addresses. It is not mean, per se, to
disable privacy addresses.

Thanks,

---

From: Christian Huitema <[email-masked]>
Date: Sun, 13 Mar 2011 00:44:34 +0000

> It doesn't. The I-D aims at allowing routers specify which policy they want hosts to employ when generating their IPv6 addresses.

Uh? I definitely don't want to give the router at Starbucks the means to specify the privacy configuration of my laptop.

I understand that corporation want to enforce policies so PC and routers are easier to manage, but we have to be careful. If we define that policy as part of the address configuration standard, then it will apply everywhere, not just in the corporate network where the laptop is managed. That seems a terrible idea. 

If we want policy options to be applied safely, they have to be propagated by trusted mechanism, where the host can verify the authority of the policy source. Anything else is abuse waiting to happen.

-- Christian Huitema

---

From: Doug Barton <[email-masked]>
Date: Sat, 12 Mar 2011 16:50:15 -0800

> If we want policy options to be applied safely, they have to be propagated by trusted mechanism, where the host can verify the authority of the policy source. Anything else is abuse waiting to happ…

Please consider this my periodic repetition of support for what 
Christian is saying here, along with my periodic repetition of 
opposition to (further) modifying RA/SLAAC to do things that DHCP 
can/does do, or should be doing.

And to state publicly something that I discussed in private, I'm 
completely unsympathetic to the viewpoint that "we need to show to the 
auditors that we tried to prevent hosts from doing bad things" in the 
absence of rigorous security steps to _actually_ prevent them.

Doug

--

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2011 21:57:14 -0300

On 12/03/2011 09:44 p.m., Christian Huitema wrote:

>> It doesn't. The I-D aims at allowing routers specify which policy
>> they want hosts to employ when generating their IPv6 addresses.
> 
> Uh? I definitely don't want to give the router at Starbucks the means
> to specify the privacy configuration of my laptop.

Override the advice provided by the router at Starbucks, and you're done
(e.g., I guess this could even be automatically done by the OS depending
on how you tag the network you're connecting to (e.g., Public, Home,
whatever)).

> If we want policy options to be applied safely, they have to be
> propagated by trusted mechanism, where the host can verify the
> authority of the policy source. Anything else is abuse waiting to
> happen.

The threat model for this case is no different to that for ND in general...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2011 22:23:22 -0300

Hi, James,

On 09/03/2011 04:08 p.m., james woodyatt wrote:
> When set, this bit indicates that hardware-derived addresses SHOULD
> be used when configuring IPv6 addresses as a result of Stateless
> Address Autoconfiguration.  When not set, this bit indicates that
> Privacy Extensions SHOULD be enabled when configuring IPv6 addresses
> as a result of Stateless Address Autoconfiguration
> 
> Which makes the bit worse than useless.  If the PIO contains A=1,
> then both EUI-64 and privacy IID are eligible under the current
> regime, but this draft says only that one or the other SLAAC
> alternative SHOULD be used depending on the state of the bit, without
> explicitly saying whether the complementary alternative SHOULD NOT be
> used.
> 
> I'm not sure if the intent is to make a signal for hosts that network
> administration regards any particular SLAAC alternative as NOT
> RECOMMENDED, but if it is, then the draft should explicitly say so.

Will do. The idea is that there's a policy that SHOULD be used, with the
others being "NOT RECOMMENDED".

> Of course, if the draft were to changed to do that, then I would
> lodge the same complaints that I lodged previously against
> I-D.yhb-6man-ra-privacy-flag... for the same reasons.

I will dig the archives. :-)  However, as noted in other posts, this is
not about "disabling privacy addresses", but about allowing admins to
communicate policies to hosts. i.e., this mechanism might be used for
*enabling* privacy addresses (rather than disabling them), too.

> This draft has a long struggle ahead of it, if you ask me.

Comments on specific issues would be very welcome, such that we can work
on fixing/improving them. ;-)

Thanks!

Best regards,

---

From: Mark Smith <[email-masked]>
Date: Sun, 13 Mar 2011 12:34:21 +1030

On Sat, 12 Mar 2011 21:57:14 -0300

> on how you tag the network you're connecting to (e.g., Public, Home,

I doubt typical end-users will be capable of getting this right often
enough for them to accept the possible privacy compromise when they
don't.

So what is wrong with the record and observe model, avoiding modifying
existing protocols and end-nodes to achieve your goal?

I don't understand why proactively putting an entry in a
neighbor cache when an end-node performs DAD, on a designated audit
device, and then letting NUD observe and report state changes for that
neighbor cache entry won't achieve the goal. There may need to be some
minor changes to ND state mechanisms to achieve this (e.g. ignore the
DAD if there is already an entry for the DAD tentative IPv6 address,
as DAD will fail, and maybe report it), however those changes
would only be required to be deployed to the audit device.

> The threat model for this case is no different to that for ND in general...

Existing addressing mechanisms in ND only have a goal of advising
end-nodes what method they should use to acquire their IPv6 addresses.
The end-node has a vested interest in following that advice, as it
will provide connectivity to other peer nodes as well as off-link
connectivity. However, end-nodes can ignore it, and e.g. use static
addressing or link-local addressing to still achieve useful
connectivity, albeit more limited than if they followed the advice in
an RA.

If you want to place far more trust in the end-nodes' address
selection choice, for audit purposes, I think you're going to have to
build much more complicated mechanisms that the one proposed, that allow
you to be assured that they've followed your advice.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Sun, 13 Mar 2011 08:37:55 +0100

> Please consider this my periodic repetition of support for what Christian is saying here, along with my periodic repetition of opposition to (further) modifying RA/SLAAC to do things that DHCP can/does do, or should be doing.

+1

> And to state publicly something that I discussed in private, I'm completely unsympathetic to the viewpoint that "we need to show to the auditors that we tried to prevent hosts from doing bad things" in the absence of rigorous security steps to _actually_ prevent them.

+1

Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Mar 2011 08:55:10 -0300

> be completely unacceptable.

Why would you find it acceptable to have the ISP assign you the complete
address e.g. with DHCP, then?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 11:16:59 +1300

Fernando,

> address e.g. with DHCP, then?

In the context of a user requiring privacy protection, it isn't acceptable.
As far as I know, what the ISP will assign is a prefix; the individual
host addresses are locally assigned by the CPE.

Thus, in an Internet cafe, a user using privacy addresses can be traced
to the cafe but no further, even if the cafe is also using DHCP to
assign addresses.

This is also why we accept the negligible risk of address collisions
referred to in another thread.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Mar 2011 22:46:18 -0300

Hi, Brian,

> In the context of a user requiring privacy protection, it isn't acceptable.

Then what's all this controversy with
draft-gont-6man-managing-privacy-extensions? :-) -- That aside, there
have been quite a few publications asessing the real "privacy" provided
with the so-called privacy-extensions....

> host addresses are locally assigned by the CPE.

Yep, sorry. I meant "CPE", not "ISP".

> to the cafe but no further, even if the cafe is also using DHCP to

If your threat model is that the CPE is maliciously recommending hosts
not to use privacy addresses, the CPE might as well claim that DHCP is
needed, and assign to each host an IPv6 address that is based on the
EUI-64 of that host...

P.S.: Bottom-line is: This is about improving the manageability of the
address generation policy. Thus, even if different systems have
different defaults, a router can provide advice such that they all
employ the same address generation policy (whether EUI-64, privacy
addresses, or whatever).

Thanks,

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 Mar 2011 06:30:46 +0000

> Then what's all this controversy with draft-gont-6man-managing-privacy-extensions? :-) -- That aside, there have been quite a few publications asessing the real "privacy" provided with the so-called privacy-extensions....

Using randomized host identifiers is way more private than sticking a MAC address in the IPv6 address. In fact, rather than your draft proposing to not use privacy addresses, we should pursue the deprecation of using EUI-64 in addresses.

The worst part of your draft is that , if we published it, it would give the impression that for the IETF, EUI-64 addresses are more secure than privacy addresses. This is obviously false.

-- Christian Huitema

---

From: [email-masked]
Date: Wed, 16 Mar 2011 08:34:47 +0100 (CET)

> host addresses are locally assigned by the CPE.

Or the host could be connected to a bridge, and assigned a /128 using
DHCPv6 IA_NA (RFC 3315).

As an ISP: I would *prefer* to require each customer to have a router,
and assign a /56 using DHCPv6 IA_PD. However, the reality is that many
customers today are using a PC behind a bridge, and such customers
would then be assigned a /128.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Mar 2011 09:32:15 -0300

On 16/03/2011 03:30 a.m., Christian Huitema wrote:
>> draft-gont-6man-managing-privacy-extensions? :-) -- That aside,
>> there have been quite a few publications asessing the real
>> "privacy" provided with the so-called privacy-extensions....
> 
> Using randomized host identifiers is way more private than sticking a
> MAC address in the IPv6 address. 

Agreed. Also in some scenarios privacy extensions may give a false sense
of privacy (see e.g. some of the pointers in our I-D).

> In fact, rather than your draft
> proposing to not use privacy addresses, we should pursue the
> deprecation of using EUI-64 in addresses.

Our draft is not meant to propose "not to use privacy addresses" -- as
noted a few times, already, the proposed mechanism could be used to turn
"privacy addresses" on for some systems that have decided not to enable
them by default (e.g., FreeBSD).

I realize that the case is made only for those scenarios in which an
admin might want to disable privacy addresses, though.

> The worst part of your draft is that , if we published it, it would
> give the impression that for the IETF, EUI-64 addresses are more
> secure than privacy addresses. This is obviously false.

We didn't argue that "privacy addresses" should be off by default.
Actually, I'd probably argue the opposite: for the general case they
should probably be "on"... but the admins should have the means to
manage how address are selected (whether privacy addresses, EUI-64, or
anything else).

Thanks,

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 16 Mar 2011 13:48:05 +0100 (CET)

> them by default (e.g., FreeBSD).

As RFC 4941 says:

Changed the default setting for usage of temporary addresses to be 
disabled.

and also:
"
Additionally, sites might wish to selectively enable or disable the
    use of temporary addresses for some prefixes.  For example, a site
    might wish to disable temporary address generation for "Unique local"
    [ULA] prefixes while still generating temporary addresses for all
    other global prefixes.  Another site might wish to enable temporary
    address generation only for the prefixes 2001::/16 and 2002::/16,
    while disabling it for all other prefixes.  To support this behavior,
    implementations SHOULD provide a way to enable and disable generation
    of temporary addresses for specific prefix subranges.  This per-
    prefix setting SHOULD override the global settings on the node with
    respect to the specified prefix subranges.  Note that the pre-prefix
    setting can be applied at any granularity, and not necessarily on a
    per-subnet basis.
"

Best Regards,
 		Jans Mohacsi

---

From: "Yu Hua bing" <[email-masked]>
Date: Wed, 16 Mar 2011 22:14:19 +0800

>them by default (e.g., FreeBSD).

Windows provides the command line to turn on or off the privacy extension.
Is your meaning is that if the user turn off the privacy extension, the RAG
flag in the router advertisement can turn on the privacy extension?

---

From: Brian Haley <[email-masked]>
Date: Wed, 16 Mar 2011 12:51:59 -0400

> override the policy specified by the router.

I have an almost off-topic comment, but since I've seen no mention of it
in any of these privacy threads...

You have to assume in a large data center that almost every MAC address you
encounter is going to be randomly generated.  This is because there are
*lots* of virtual machines out there, and the density of them is increasing
exponentially.  Their MACs could change daily as they are deployed and
decommissioned, but from their perspective their MAC is hardware-based.
I know you have this as a "SHOULD" requirement, but figured I should mention
it since it's one of those places where this bit will be completely ignored.

-Brian

---

From: Rémi Després <[email-masked]>
Date: Wed, 16 Mar 2011 18:03:09 +0100

Le 16 mars 2011 à 07:30, Christian Huitema a écrit :
...

> In fact, rather than your draft proposing to not use privacy addresses, we should pursue the deprecation of using EUI-64 in addresses.

-1

> The worst part of your draft is that , if we published it, it would give the impression that for the IETF, EUI-64 addresses are more secure than privacy addresses. This is obviously false.

But they are more stable by default, a feature that can be useful where privacy isn't a must.

RD

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Mar 2011 22:10:46 -0300

> flag in the router advertisement can turn on the privacy extension?

No.

A host could have two knobs, e.g.:
DefaultAddressPolicy = PrivacyExtensions/EUI64
EnableAddressPolicyConfiguration = Enabled/Disabled

If EnableAddressPolicyConfiguration is Enabled, then the host will
employ whatever address policy is advised by the router (or, if no
specific advice is provided, it would use DefaultAddressPolicy).

If EnableAddressPolicyConfiguration is Disabled, then the host would
employ DefaultAddressPolicy regardless of what the router is advising.

The aforementioned knobs might be configured with different
granularities. For example, on a "per wireless network" basis, or whatever.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Mar 2011 21:59:36 -0300

>    setting can be applied at any granularity, and not necessarily on a

The proposed modification to the Prefix Information option would enable
administrators to avoid the pain of having to do this manually on each
node attached to their site -- which in some cases could be impossible.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Mar 2011 01:30:48 -0300

On 16/03/2011 01:51 p.m., Brian Haley wrote:

> encounter is going to be randomly generated.  

Are they actually random? i.e., I'm curious about the algorithm used for
generating the Interface IDs.

> This is because there are

>From the point of view of the VMs, they would still be using Modified
EUI-64 Interface Identifiers. This is not that different from the case
in which the admin sets the MAC address of an interface to some value
that he wants (other than the *real* address of the interface). IMHO,
this is out-of-scope for this document.

Thanks!

Best regards,

---

From: Mark Smith <[email-masked]>
Date: Fri, 25 Mar 2011 17:51:15 +1030

On Fri, 25 Mar 2011 01:30:48 -0300

> generating the Interface IDs.

Here's the routine typically used under Linux to generate these types
of addresses -

include/linux/etherdevice.h

/**
 * random_ether_addr - Generate software assigned random Ethernet
address
 * @addr: Pointer to a six-byte array containing the Ethernet address
 *
 * Generate a random Ethernet address (MAC) that is not multicast
 * and has the local assigned bit set.
 */
static inline void random_ether_addr(u8 *addr)
{
        get_random_bytes (addr, ETH_ALEN);
        addr [0] &= 0xfe;       /* clear multicast bit */
        addr [0] |= 0x02;       /* set local assignment bit (IEEE802) */
}