Subject: Last Call: <draft-ietf-6man-stable-privacy-addresses-06.txt> (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 12 Apr 2013 08:34:53 -0700

The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'A method for Generating Stable Privacy-Enhanced Addresses with IPv6
   Stateless Address Autoconfiguration (SLAAC)'
  <draft-ietf-6man-stable-privacy-addresses-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2013-04-26. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document specifies a method for generating IPv6 Interface
   Identifiers to be used with IPv6 Stateless Address Autoconfiguration
   (SLAAC), such that addresses configured using this method are stable
   within each subnet, but the Interface Identifier changes when hosts
   move from one network to another.  The aforementioned method is meant
   to be an alternative to generating Interface Identifiers based on
   IEEE identifiers, such that the benefits of stable addresses can be
   achieved without sacrificing the privacy of users.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: SM <[email-masked]>
Date: Sat, 27 Apr 2013 08:35:34 -0700

At 14:32 25-04-2013, Alissa Cooper wrote:
>One comment and one nit below.

[snip]

>This implication seems misguided. Providing the ability to track and 
>correlate the communications of a device that never leaves a single 
>network is a significant concern. It is one concern among several 
>that the IEEE-identifier-based mechanism raises, but it is a big one 
>IMO. This algorithm does not appear to mitigate that concern, so any 
>implication that it does should be avoided. I would suggest using 
>"some of the privacy concerns" in place of "most of the privacy 
>concerns" in the two sections above.

Agreed.

Regards,
-sm

P.S. I hope that the 6MAN WG does not ignore Alissa's comment.

---

From: SM <[email-masked]>
Date: Sat, 27 Apr 2013 09:51:05 -0700

Hi Fernando,
At 12:13 26-04-2013, Fernando Gont wrote:
>In some scenarios, that's impossible. Trivial example: If you have a
>network with a single host attached to it, no matter whether you change
>your address periodically (*), it will be possible to correlate the
>hosts' activities.
>
>(*) That of changing your addresses *periodically* actually helps
>correlation.

What Alissa suggested is using "some" instead of "most".  It's a very 
small change to the draft.  The advantage of doing it is that you can 
tell a reader that the draft says "some" instead of "most" if there 
are ever any privacy issues.

Regards,
-sm

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 27 Apr 2013 18:51:46 +0200

[snip]

>network is a significant concern. It is one concern among several that 
>the IEEE-identifier-based mechanism raises, but it is a big one IMO. 
>This algorithm does not appear to mitigate that concern, so any 
>implication that it does should be avoided. I would suggest using "some 
>of the privacy concerns" in place of "most of the privacy concerns" in 
>the two sections above.

>Agreed.

I mentioned this comment in the first versions of this draft, but nobody
seemed to agree with me at that time so I stopped with the dialogue. 

Hosnieh

---

From: SM <[email-masked]>
Date: Sat, 27 Apr 2013 11:36:30 -0700

Hi Hosnieh,
>seemed to agree with me at that time so I stopped with the dialogue.

I gather that would be in the message at 
http://www.ietf.org/mail-archive/web/ipv6/current/msg16859.html  If 
there are any issues about privacy you could raise them on the 
[email-masked] mailing list.

Regards,
-sm

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 27 Apr 2013 21:20:32 +0200

I do not think repeating what I explained before will be of much help. I
never received any responses from my last discussions with Fernando so I am
not going to continue that discourse.  But here is a brief summary of I
tried to  explain.

I agree with the part where he focuses on an algorithm for IID generation,
but this will have no effect on  privacy so claiming to solve the privacy
problem by keeping the same IID for a node in a same network is not true.
This means that if I do not use a mobile node, I will generate the same IP
address until I receive another prefix from the router. He claims this is
good for printers or nodes that need a fixed IP address. He believes that
having a different IID from the same router prefix does not help with the
privacy. But I strongly disagree with this. During the time that the node
has the same IID, I as an attacker can easily track this node and, gain
enough information about this node, for later when the node comes with a
different router prefix, I have more chance to correlate this node with the
previous data I obtained from it while it had the IID with previous router
prefix.
About having the same IID for some nodes, I think that this is really
related to the network policy and has nothing to do to with standards but Is
more a deployment issue. Currently some network administrators themselves
consider this issue so there is no need to tell them how to do this. 

Best,
Hosnieh

-----Original Message-----
From: SM [mailto:[email-masked]] 
Sent: Saturday, April 27, 2013 8:37 PM
To: Hosnieh Rafiee
Cc: Alissa Cooper; [email-masked]
Subject: RE: Last Call: <draft-ietf-6man-stable-privacy-addresses-06.txt> (A
method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless
Address Autoconfiguration (SLAAC)) to Proposed Standard

Hi Hosnieh,
At 09:51 27-04-2013, Hosnieh Rafiee wrote:
>I mentioned this comment in the first versions of this draft, but 
>nobody seemed to agree with me at that time so I stopped with the dialogue.

I gather that would be in the message at
http://www.ietf.org/mail-archive/web/ipv6/current/msg16859.html  If there
are any issues about privacy you could raise them on the
[email-masked] mailing list.

Regards,
-sm

---

From: Fernando Gont <[email-masked]>
Date: Sat, 27 Apr 2013 20:34:02 -0300

Hosnieh,

On 04/27/2013 04:20 PM, Hosnieh Rafiee wrote:
> not going to continue that discourse.

FWIW, I responded to your messages. However, most of them did not really
have to do with this document.

> problem by keeping the same IID for a node in a same network is not true.

Please read:

Dupont, F., Savola, P. 2004. RFC 3041 Considered Harmful. IETF
Internet-Draft (draft-dupont-ipv6-rfc3041harmful-05.txt), work in progress.

Escudero, A. 2002. PRIVACY EXTENSIONS FOR STATELESS ADDRESS
AUTOCONFIGURATION IN IPV6 - ‘REQUIREMENTS FOR UNOBSERVABILITY.
RVK02, Stockholm. Available at:
http://web.it.kth.se/~aep/PhD/docs/paper3-rvk2002.pdf

> address until I receive another prefix from the router.

If you are a single node on a givn network, changing your address
doesn't help much.

> He claims this is
> good for printers or nodes that need a fixed IP address. 

I never claimed this. And discussion gets a little bit weird when you
argue that people claimed things they didn't.

> He believes that
> privacy. 

If you read draft-ietf-6man-stable-privacy-addresses, you'll realize
that this method is not meant to be a substitution of RFC4941. We just
note that, in some scenarios, it might be good enough.

> But I strongly disagree with this. During the time that the node

Not sure what you mean. Please elaborate.

> more a deployment issue. 

We do care about deployment, don't we?

> Currently some network administrators themselves

huh?

Thanks,
-- 
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: Sat, 27 Apr 2013 20:39:47 -0300

On 04/27/2013 01:51 PM, SM wrote:
> tell a reader that the draft says "some" instead of "most" if there are
> ever any privacy issues.

There are essentially three privacy issues:

* main one: IIDs that are constant across networks (this is the one that
is very harmful)

* second one: correlation of node activities within the same network. In
many cases, no matter whether you change your addresses, it won't be solved.

* third one: leaking information about the IID, which could allow
attackers to guess the addresses of other alive nodes.

This document fixes #1 and #3. Regarding #2, it may or may not be
"addressed" with RFC 4941. That's why this document says "addresses most
privacy issues...".

That said, I don't care s/most/some/ -- consider that change done, for
instance. -- the meat of the document is elsewhere, and not in that
sentence.

Thanks,

---

From: SM <[email-masked]>
Date: Sat, 27 Apr 2013 17:13:37 -0700

Hi Fernando,

I owe you an apology as one of the comments I made on this thread may 
be misinterpreted.  You responded to all the comments I read.

Regards,
-sm

---

From: Christian Huitema <[email-masked]>
Date: Sun, 28 Apr 2013 00:47:09 +0000

> * main one: IIDs that are constant across networks (this is the one that is very harmful)

I think outlining that issue is perhaps the most important aspect of Fernando's draft. The logic of automatic address configuration is that a host gets an IID, and use the same IID for all network prefixes, or even when roaming. That's true if the IID is derived from the MAC address, and also true with RFC 4941. This is indeed a major privacy concern, and solving it is quite important.

> * second one: correlation of node activities within the same network. In many cases, no matter whether you change your addresses, it won't be solved.

That's largely true, because hosts leak tons of information on the network they connect to. The MAC address of course, but also things like host names in DHCP requests, or even the DNS names queried by the host. Solving that will require a significant effort.

> * third one: leaking information about the IID, which could allow attackers to guess the addresses of other alive nodes.

That one is solved by RFC 4941, by this draft, or even by DHCP.

I read Fernando's draft as engineering privacy with an exception. The addresses are randomized and have many privacy features, but they remain the same in a local context, and are thus very observable in that local context. That's obviously a tradeoff. I see why IT departments would like that feature -- but then, they could get the same effect by just deploying a DHCP server. However, in the case of roaming the feature is highly debatable. If a host visits the same network multiple times, should it always reuse the same ID, or should it get a new identifier each time? It is very easy to argue that "different each time" has better privacy properties. 

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Sun, 28 Apr 2013 00:44:07 -0300

On 04/27/2013 09:47 PM, Christian Huitema wrote:
>> * second one: correlation of node activities within the same
>> network. In many cases, no matter whether you change your
>> addresses, it won't be solved.
> 
> That's largely true, because hosts leak tons of information on the
> network they connect to. The MAC address of course, but also things
> like host names in DHCP requests, or even the DNS names queried by
> the host. Solving that will require a significant effort.

That aside, if there's only one node active in a given network, then
changing your address periodically (particularly when you're making that
fact known) doesn't help much.

> That one is solved by RFC 4941, by this draft, or even by DHCP.

It *is* solved by DHCP, but not by RFC4941: RFC4941 addresses are
generated *in addition* to SLAAC addresses. That's why, I'm told,
Windows replaces traditional SLAAC addresses with a time-invariant
version of RFC4941 - besides *additionally* implementing RFC4941 for
temporary addresses.

Here we're mitigating address-scanning attacks, while bringing other
benefits such as privacy, by removing IIDs that are constant across
networks.

> I read Fernando's draft as engineering privacy with an exception. The
> addresses are randomized and have many privacy features, but they
> remain the same in a local context, and are thus very observable in
> that local context. That's obviously a tradeoff. I see why IT
> departments would like that feature -- but then, they could get the
> same effect by just deploying a DHCP server. 

This document aims to improve the case for SLAAC: There are many
scenarios in which SLAAC is desirable, without that meaning that you
really want a super cookie in the IPv6 addresses of nodes.

Or, put another way, from the pov of the user/host, you don't really
want to be trivially traceable even if you connect to a network that
uses SLAAC rather than DHCPv6.

> However, in the case of
> roaming the feature is highly debatable. If a host visits the same
> network multiple times, should it always reuse the same ID, or should
> it get a new identifier each time? It is very easy to argue that
> "different each time" has better privacy properties.

Agreed. For instance, draft-ietf-6man-stable-privacy-addresses-06.txt is
not a replacement for RFC4941. If you're a roaming node, you probably
want RFC4941 enabled (in addition to having
draft-ietf-6man-stable-privacy-addresses-06.txt enabled).

Cheers,

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 28 Apr 2013 11:21:48 +0200

>have to do with this document.

Your answered but your response unfortunately could not address to my
concerns.

>If you are a single node on a givn network, changing your address

I think, this is what should be taken into consideration based on the
network policy and not something as a "standard" track. Again, I strongly
disagree with you. Because you did not solve the privacy within the network
and probably not between networks. I had an experiment within the small size
network, my attacker node was not within the same network because I did not
want to test privacy in layer 2 (MAC address). It was really easier to
correlate the data to a node.

>argue that people claimed things they didn't.

Your first arguments were about the nodes which want to have a not
changeable IP address within the network (during the time they have the same
router prefix) and my response to this reason was, this is related to
network administrator. If they really want to have a node with a fixed IP
address, probably they want it to have a fixed IP address forever and not
change after the router prefix changes. They thus set it manually.  

>note that, in some scenarios, it might be good enough.

I read both RFCs about IID generation and what I understood is you wanted to
have something in between. But in my opinion, your draft does not solve the
privacy otherwise we are also talking about a short lifetime for the router
prefixes. Because as I explained in my last practical experiment, during the
time you have the same IID, I can gather enough information about your node.
It has a direct relationship with the lifetime of your IID. But when I could
have about 50% information about your node, I have a chance to correlate
your later connections with different router prefixes or probably I gathered
enough information about the nodes that I am tracking and do not need to
track them more after they have different router prefixes. What  would be so
helpful is you  merged both RFCs and replace them instead of having
something between that does not really help in privacy. 

>We do care about deployment, don't we?

What I meant is, standard should address to general issues but in your
draft, except the IID generation algorithm, I do not see a general issue.
Not having a fixed IID within the network or having it, is a network policy
and not a standard document. The privacy is something that some people want
to have it and some really do not. A standard document can explain to keep
the lifetime of IID for a short period of time but it might not explain that
It should be this or that and keep it like this or that. You can recommend
them but not focus the whole purpose of your draft on this solution.  If a
standard document tries to explain everything in more detail then it ties
the hands of network administrators. they will thus easily disable this
feature in their nodes. There are currently thousands of RFCs that never
been implemented or never been used. It is because many of them did not
focus on the general solutions. In my opinion it is not a general solution
to keep the lifetime of the IID like what you explained in your draft and
again I consider it as an issue related to the network policy and not a
standard document. So now the question is why we have to go in more detail
like this and decide for the administrators about the lifetime of the IID
when it is a simple things and related to the network policy? 

I ask others to judge and discuss about this... I am not going to continue.

Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 28 Apr 2013 17:28:04 +0200

>benefits such as privacy, by removing IIDs that are constant across

The node is still vulnerable to privacy attacks when you have an IID
lifetime for the IP address as explained in your draft.  Why offer a partial
solution to the problem with the implementation of two RFCs?! What needs to
be done is write one RFCs to address both issues. This can be done by more
generalizing the solution instead of focusing on a small group of people who
thinks having the same IID in the same network and changing it just among
two networks would solve the privacy problem. It is not really true.
As I wrote in the last email, standards documents should pertain to general
issues. With respect to your draft, the only general issue that is addressed
is that of the IID generation algorithm. Whether or not an IID in a network
is fixed or not is a network policy issue and not a standards issue. A
standard might suggest that the time frame for the use of an IID should be
kept short but nothing more.
If more management is needed in the generation of the IID then other
approaches can be used other that neighbor discovery. Again, there are
thousands of RFCs that have never been implemented or used because they do
not focus on general solutions. The lifetime of the IP address should be
left to the discretion of the users and not the standard except for
explaining the potential dangers inherent in using longer time periods. In
the standard, you just need to explain how the implementation should provide
a way to use a parameter containing the lifetime.  So then the
implementation could obtain this value during the installation of this
feature. This will generalize the solution and will give a possible way of
changing the lifetime based on the network policy so that the whole draft
does not focus on something that does not really solve the privacy issue.

Hosnieh

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Apr 2013 08:00:59 +1200

On 29/04/2013 03:28, Hosnieh Rafiee wrote:

> ... Whether or not an IID in a network
> is fixed or not is a network policy issue and not a standards issue.

You keep saying that, but it's a *host* IID and therefore primarily
a host issue. In some cases, hosts are subject to a local policy,
but in other cases they are completely autonomous. It's reasonable
to have several optional standards for how hosts autonomously create
their IID.

As has been accepted by Fernando, this draft only solves some aspects
of IID-based privacy. So what? That is quite typical of IETF standards.
We generally find it more useful to avoid trying to boil the ocean.

    Brian

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 28 Apr 2013 22:13:52 +0200

Dear Brian,

>You keep saying that, but it's a *host* IID and therefore primarily a host issue. In some cases, hosts are subject to a local policy, but in other cases they are completely autonomous. It's reasonable to >have several optional standards for how hosts autonomously create their IID.

I agree with what you said  that there are several options for generating IID. I have no problem with that.

>As has been accepted by Fernando, this draft only solves some aspects of IID-based privacy. So what? 

What I keep saying is this rfc draft does not have any effect on privacy and everything related to the router prefix. 

>We generally find it more useful to avoid trying to boil the ocean.

We are not boiling the ocean bucket by bucket as you seem to think. What we are doing is beating a dead horse.

Hosnieh

---

From: Mark Smith <[email-masked]>
Date: Sun, 28 Apr 2013 21:47:26 -0700 (PDT)

----- Original Message -----
> From: Hosnieh Rafiee <[email-masked]>
> To: 'Brian E Carpenter' <[email-masked]>
> Cc: 'Fernando Gont' <[email-masked]>; 'Alissa Cooper' <[email-masked]>; [email-masked]; 'Christian Huitema' <[email-masked]>
> Sent: Monday, 29 April 2013 6:13 AM
	method for Generating Stable Privacy-Enhanced Addresses with
	IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard
> 
> Dear Brian,
> 
> 
>> You keep saying that, but it's a *host* IID and therefore primarily a 
> host issue. In some cases, hosts are subject to a local policy, but in other 
> cases they are completely autonomous. It's reasonable to >have several 
> optional standards for how hosts autonomously create their IID.
> 

So privacy and security are relative, not absolute. I think this provides better privacy compared to the use of MAC addresses for IIDs, but doesn't provide as much privacy as RFC4941 addresses. If the level of privacy these stable privacy addresses provides is not adequate, then you don't use them. You either use RFC4941s, or you choose not to communicate at all.

Can you define the "privacy" you don't think it has any effect on? 

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Apr 2013 07:19:02 -0300

On 04/29/2013 01:47 AM, Mark Smith wrote:
>> What I keep saying is this rfc draft does not have any effect on
>> privacy and everything related to the router prefix.
>> 
> 
> So privacy and security are relative, not absolute. I think this
> provides better privacy compared to the use of MAC addresses for
> IIDs, 

Exactly.

> but doesn't provide as much privacy as RFC4941 addresses. If
> the level of privacy these stable privacy addresses provides is not
> adequate, then you don't use them. You either use RFC4941s, or you
> choose not to communicate at all.

Actually, if you use RFC4941, you probably want to use stable privacy
addresses to replace the traditional SLAAC addresses (or else you'd be
subject of the issues described in the Appendix of
draft-ietf-6man-stable-privacy-addresses)

Cheers,

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 29 Apr 2013 16:23:20 +0200

Dear Mark

>So privacy and security are relative, not absolute. I think this provides
better privacy compared to the use of MAC addresses for IIDs
 
Unfortunately that answer is not exactly true. As I explained in my last
messages, it is really related to the lifetime of the router prefix. In
reality, if you do not change it within a short period of time, like when a
MAC address is used, then an attacker will be  able to obtain enough
information about this node in order to prepare attacks against during the
time they use the same IID. Then later, the attacker will have the
opportunity to follow his victim  when he goes to a new network using the
information he obtained earlier. This means  that changing the IP address
now will be of no use . This is why I do not see how privacy is enhanced in
any way with this way of IID generation and I keep reiterating that what
this draft states about also providing privacy is not true. This draft is
just about the generation of IID in a manner not based on MAC addresses and
offers nothing of value concerning privacy issues.
 
Privacy and security are relative, that is true. But the way he wants to
maintain privacy is like someone who hides his head in a hole hoping  that
nobody will see him. I do not call this privacy. Privacy is relative when
you make as much effort as possible to keep the data confidential. If some
ingenious attackers can come up with new approaches to find your data, then
this is not your fault. I mean by this that  if one wants to claim that he
has enhanced privacy, then he will  have had to do everything possible to
prevent the currently known privacy attacks. But if you cannot accomplish
that in your solution, then you should not mislead readers by saying that
your solution does.. This is because privacy is like a bottle of water,
where your information is the water inside this bottle. It makes no
difference whether you do not close the tap or just don't close it as
tightly as you should (like this draft), The bottle will leak water, and for
some attackers even a few drops is all they need to initiate further attacks
which can result in much damage to the prey. So, if a draft claim to have
privacy, it cannot just say I will consider just this part of privacy not
others. This is why I suggested to him to just let the users decide on the
lifetime for their IP address when they want to install this feature. In
this case, he does not try to do anything about that bottle; the aim of the
draft is not about privacy but a randomized IID. That way  no one will have
any expectations for privacy. So, what I am saying here is  that having a
big title which alludes to privacy enhancements does not make sense.

> Can you define the "privacy" you don't think it has any effect on? 
 I have already answered this by what I said in my prior sentence.

Best,
Hosnieh

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Apr 2013 16:55:42 -0300

Hosnieh,

Quite a few times I have responded to your comments, and have even
provided pointers to publicly-available papers that you seem to have
ignored.

I disagree with your comments below... but cannot really invest more
time in writing responses you'll ignore.

This I-D improves at least two privacy related issues, with minimal
effort and complexity. That's usually referred to as "engineering".

As noted by others and myself in other messages, there are other aspects
that might not even be addressable, or that might be undesirable to
address for the general case. (e.g., from the pov of privacy you might
want to use a new random address for every new flow... but that
generally causes a lot of trouble and complexity).

That's as much as I will add to this sub-thread.

Thanks,
Fernando

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 29 Apr 2013 23:17:43 +0200

Fernando,

I guess that we are at an impasse again. I just want to make it clear to
everyone that this proposed draft of yours doesn't really do anything
substantial for privacy issues and I find it misleading to mention privacy
in the title. I too am extremely busy and cannot afford to devote any more
time debating this issue with you. I had stopped this discussion with you
once before but some other people asked me to bring it up with you again. I
see that it was for naught. Science is not absolute so what is written can
just be some ones opinion based on what was happening at that time. In
today's environment privacy has come to the fore front and the parameters
that were used to define privacy before have changed greatly. It is a much
bigger issue and getting bigger every day. 

Hosnieh 

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Monday, April 29, 2013 9:56 PM
To: Hosnieh Rafiee
Cc: 'Mark Smith'; 'Alissa Cooper'; [email-masked]; 'Christian Huitema'
Subject: Re: Last Call: <draft-ietf-6man-stable-privacy-addresses-06.txt> (A

Hosnieh,

Quite a few times I have responded to your comments, and have even provided
pointers to publicly-available papers that you seem to have ignored.

I disagree with your comments below... but cannot really invest more time in
writing responses you'll ignore.

This I-D improves at least two privacy related issues, with minimal effort
and complexity. That's usually referred to as "engineering".

As noted by others and myself in other messages, there are other aspects
that might not even be addressable, or that might be undesirable to address
for the general case. (e.g., from the pov of privacy you might want to use a
new random address for every new flow... but that generally causes a lot of
trouble and complexity).

Thanks,
Fernando

On 04/29/2013 11:23 AM, Hosnieh Rafiee wrote:
>> provides
> Unfortunately that answer is not exactly true. As I explained in my 
> last messages, it is really related to the lifetime of the router 
> prefix. In reality, if you do not change it within a short period of 
> time, like when a MAC address is used, then an attacker will be  able 
> to obtain enough information about this node in order to prepare 
> attacks against during the time they use the same IID. Then later, the 
> attacker will have the opportunity to follow his victim  when he goes 
> to a new network using the information he obtained earlier. This means  
> that changing the IP address now will be of no use . This is why I do 
> not see how privacy is enhanced in any way with this way of IID 
> generation and I keep reiterating that what this draft states about 
> also providing privacy is not true. This draft is just about the 
> generation of IID in a manner not based on MAC addresses and offers
nothing of value concerning privacy issues.
>  
> Privacy and security are relative, that is true. But the way he wants 
> to maintain privacy is like someone who hides his head in a hole 
> hoping  that nobody will see him. I do not call this privacy. Privacy 
> is relative when you make as much effort as possible to keep the data 
> confidential. If some ingenious attackers can come up with new 
> approaches to find your data, then this is not your fault. I mean by 
> this that  if one wants to claim that he has enhanced privacy, then he 
> will  have had to do everything possible to prevent the currently 
> known privacy attacks. But if you cannot accomplish that in your 
> solution, then you should not mislead readers by saying that your 
> solution does.. This is because privacy is like a bottle of water, 
> tightly as you should (like this draft), The bottle will leak water, 
> and for some attackers even a few drops is all they need to initiate 
> further attacks which can result in much damage to the prey. So, if a 
> draft claim to have privacy, it cannot just say I will consider just 
> this part of privacy not others. This is why I suggested to him to 
> just let the users decide on the lifetime for their IP address when 
> they want to install this feature. In this case, he does not try to do 
> anything about that bottle; the aim of the draft is not about privacy 
> but a randomized IID. That way  no one will have any expectations for
privacy. So, what I am saying here is  that having a big title which alludes
to privacy enhancements does not make sense.

---

From: Philipp Kern <[email-masked]>
Date: Tue, 30 Apr 2013 01:27:37 +0200

Hosnieh,

am Mon, Apr 29, 2013 at 11:17:43PM +0200 hast du folgendes geschrieben:
> in the title.

you seem to argue that privacy can only be mentioned if the protection is
absolute. Fernando argues that even small steps are worthwhile. The main
question seems to be if Fernando's draft has enough privacy value in itself
apart from stable addressing that is not based on Ethernet MAC addresses.

It does seem to me that to the outside world a globally unique identifier
is no longer presented to the world in an address that is fixed for a given
(network, host) tuple. Obviously this does not help against local attackers
that can query for the MAC and obviously this does not help against ongoing
tracking of the concrete host within that single network from the outside
world. Fernando does not argue against using privacy extensions as an addition
to this solution.

Windows resorted to use some random identifier instead of EUI64 addresses
by default in order not to leak the MAC address. This draft just proposes
a similar algorithm for stable autoconfiguration. The title says
"privacy-enhanced", maybe "Stable non-IEEE-identifier-based Addresses"
(with a cuter title made up by a native speaker) would explain the
goal in the title a bit more clearly. You wouldn't argue against
listing the privacy benefits this has over the traditional way of EUI64-based
SLAAC address assignment, I presume?

Kind regards
Philipp Kern

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 30 Apr 2013 17:38:33 +0200

Philipp,

I didn't really want to continue this debate as I have repeatedly stated my
views in my past responses, but if you like, I will once again explain it
from my point of view.

>you seem to argue that privacy can only be mentioned if the protection is
absolute.
 
No, absolute is too a big word to use but the definition of the relative is
also much different than when using it in reference to security. Unlike
security where you can provide relative security through the protection of
one protocol and  then claim protection for all the associated protocols,
privacy is not like that.  Because it is related to all data that can be
leaked at one time you have no way or partly protecting privacy. The problem
with people who think his approach provides privacy is that they compare the
relative definition of security with privacy. It is not comparable!
 
>Fernando argues that even small steps are worthwhile. The main question
seems to be if Fernando's draft has >enough privacy value in itself apart
from stable addressing that is not based on Ethernet >MAC addresses.
 
I call his approach a method for generating an IID without the use of MAC
addresses, but it is not an approach for privacy! Exposing a MAC address
alone, in the IP address, neither exposes privacy nor protects privacy. This
is the main problem with some people in this group that think that not
generating an IP address based on MAC will really help in protecting their
privacy. It does, but with certain conditions that Fernando's draft doesn't
explain. If I use the same IID for a long period of time, say one month or
so, what is the difference between having my address generated using a MAC
address or based on Fernando's approach?  
My answer to that is that I see no difference.
Why you might ask?  Well that is because there are two scenarios in play
here. In first scenario my node is not mobile and remains in the same
network forever. So my node expects  that the router prefix will be changed
so that a new IP address can be generated thus protecting  his privacy. But
what happens when the router prefix is not changed for a long time. The
attacker will then be able to gather enough information about this victim
node to allow him to do his dirty deeds. Privacy??! I see no privacy here.
 
Now consider the second scenario where my node is mobile. The victim node
joins network A, generates its IP address, and remains on the network for an
X amount of time. Since the victim node is really only temporary in that
network, then it can use the Privacy Extension RFC for generating its IP
address as it does not need to have a fixed IP address.
What is the benefit of having a fixed IP address when my node is only
temporary?? I myself see no benefit. He is just a visitor on that network so
why should it be important for him?
Suppose that a staff member always uses network A for connecting his laptop
to the network. He then moves to network B and then returns to network A.
Each time he will be using the same IP address in network A and the same
will be true for network B. How difficult would it be for the attacker to
understand that this is the same node moving from one network to another? So
once again I see no privacy here, even for mobile nodes. But what if he
generated his address based on the Privacy Extension RFC. In that case every
time he joined  network A or network B, he would have new IP addresses (new
IIDs) and it would not be easy for the attacker to detect that it is the
same node making the moves.  This shows that  there is already a solution
for my mobile node, so why should I use  the procedures outlined in this
draft??
 
>Windows resorted to use some random identifier instead of EUI64 addresses
by default in order not to leak the MAC address. This draft just proposes a
similar algorithm for stable autoconfiguration. >The title says
"privacy-enhanced", maybe "Stable non-IEEE-identifier-based Addresses"
>(with a cuter title made up by a native speaker) would explain the goal in
the title a bit more clearly. You wouldn't argue against listing the privacy
benefits this has over the traditional way of EUI64->based SLAAC address
assignment, I presume?
 
Yes, If the IETF wants to have an optional approach for IID generation then
""Stable non-IEEE-identifier-based Addresses" is  a viable means. However, I
assume that resolving the current issue using the current RFCs will be more
helpful than having a new document which could confuse users.
 
Finally, this approach does not have wide usage in the current context. As
others have also mentioned, if I need more management of my IP addresses or
need some fixed IP address on my node, then I could easily configure the
DHCP server. I would configure for other nodes and would configure my fixed
nodes manually. I will not use SLAAC, and if I want privacy and temporary
addresses, then I will use Privacy Extension RFC. If that RFC has any
problems with generating the IID then I would extend the algorithm for IID
generation there, without having something in between that does not have
wide usage.
 
I hope you and others who have the same questions receive the response.
 
Best,
Hosnieh

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Apr 2013 14:52:40 -0300

On 04/30/2013 12:38 PM, Hosnieh Rafiee wrote:
> 
> No, absolute is too a big word to use but the definition of the
> relative is also much different than when using it in reference to
> security. Unlike security where you can provide relative security
> through the protection of one protocol and  then claim protection for
> all the associated protocols, privacy is not like that. 

Privacy is handled in the same way as security. Perfect privacy (as with
perfect security) doesn't exist... and you usually must decide when
putting even more effort on it doesn't make any more sense.

> Because it
> is related to all data that can be leaked at one time you have no way
> or partly protecting privacy.

"The same thing could be said about security, if that's your point: your
whole system can be compromised at one time". -- Of course, that doesn't
make any sense.

> The problem with people who think his
> approach provides privacy is that they compare the relative
> definition of security with privacy.

THis approach mitigate a number of privacy issues that arise from using
traditional slaac addresses. In many cases, mitigating those is "good
enough".

> seems to be if Fernando's draft has >enough privacy value in itself
> apart from stable addressing that is not based on Ethernet >MAC
> addresses.

It does the following:

* prevents leaking address patterns
* prevents trivial host-tracking across networks.

For *me*, that's more than enough.

> I call his approach a method for generating an IID without the use of
> MAC addresses, but it is not an approach for privacy! 

If your concern is the name, let's call this "Fernando's addresses" :-)
or whatever -- the meat is in the mechanism, rather than the title.

> Exposing a MAC
> address alone, in the IP address, neither exposes privacy nor
> protects privacy. 

When it comes to host-tracking, what matters is that the IID is constant
across networs -- for instance, Windows' approach suffers the same problem.

OTOH, embedding the MAC address in the IID possibly leaks address
patterns of the local network.

> This is the main problem with some people in this
> group that think that not generating an IP address based on MAC will
> really help in protecting their privacy. It does, but with certain
> conditions that Fernando's draft doesn't explain.

Not sure what "conditions" you're referring to. Could you please elaborate?

> If I use the same
> IID for a long period of time, say one month or so, what is the
> difference between having my address generated using a MAC address or
> based on Fernando's approach?

Im not sure how many times I have repeated this already: traditional
slaac addresses have IIDs that **are constant across networks**.

This scheme results in addresses that have IIDs that **change across
networks**. --That's a big different, isn't it?

> My answer to that is that I see no
> difference. Why you might ask?  Well that is because there are two
> scenarios in play here. In first scenario my node is not mobile and
> remains in the same network forever. So my node expects  that the
> router prefix will be changed so that a new IP address can be
> generated thus protecting  his privacy. 

Why would you expect a *prefix* to change, if your node does not move,
when an *address* is supposed to be topologically-dependent??

> But what happens when the
> router prefix is not changed for a long time. The attacker will then
> be able to gather enough information about this victim node to allow
> him to do his dirty deeds. Privacy??! I see no privacy here.

No matter how short-lived you make addresses, this will still be the
case. FOr instance, with current tools and bandwidths, you do not need a
node to be connected for more than a few seconds to have a penetration
testing tool attempt what you refer to as "dirty deeds".

> Now consider the second scenario where my node is mobile. The victim
> node joins network A, generates its IP address, and remains on the
> network for an X amount of time. Since the victim node is really only
> temporary in that network, then it can use the Privacy Extension RFC
> for generating its IP address as it does not need to have a fixed IP
> address.

How many times do I need to repeat that RFC4941 addresses are generated
**in addition** to traditional slaac addresses?

So, if you do privacy extensions, you're still doing the MAC-based
addresses.

And, the fact that youre a mobile node doesn't mean you don't need a
stable address.

> What is the benefit of having a fixed IP address when my
> node is only temporary?? I myself see no benefit. He is just a
> visitor on that network so why should it be important for him? 

Because while you're still in that network, some of the protocols you
employ may need a stable address... and because you may not want your
e.g. ssh sessions to break every X minutes.

FWIW, I'm writing this email on a laptop, which is my mobile node. It
tends to stay cnnected for a few hours at home, then for a few hours at
my office, then for a few hours at some relative's home I'm visiting, etc.

> Suppose that a staff member always uses network A for connecting his
> laptop to the network. He then moves to network B and then returns to
> network A. Each time he will be using the same IP address in network
> A and the same will be true for network B. How difficult would it be
> for the attacker to understand that this is the same node moving from
> one network to another?

Certainly not obvious/possible by just looking at the IPv6 address. --
and if you don't think so, please explain your attack vector.

> So once again I see no privacy here, even for
> mobile nodes. But what if he generated his address based on the
> Privacy Extension RFC. In that case every time he joined  network A
> or network B, he would have new IP addresses (new IIDs) and it would
> not be easy for the attacker to detect that it is the same node
> making the moves.

I'd just need to learn the fixed address, and then actively poll it at
the two networks.

> the title a bit more clearly. You wouldn't argue against listing the
> privacy benefits this has over the traditional way of EUI64->based
> Yes, If the IETF wants to have an optional approach for IID
> generation then ""Stable non-IEEE-identifier-based Addresses" is  a
> viable means. However, I assume that resolving the current issue
> using the current RFCs will be more helpful than having a new
> document which could confuse users.

This one has been beaten to death. Please read the intro of
draft-ietf-6man-stable-privacy-addresses.

> Finally, this approach does not have wide usage in the current
> context. As others have also mentioned, if I need more management of
> my IP addresses or need some fixed IP address on my node, then I
> could easily configure the DHCP server. 

Since you don't control which networks employ DHCP, you cannot rely on
that -- you don't really want to reveal your node's identity and become
subject to host-tracking attacks when you connect to networks that
employ SLAAC, do you?

> I would configure for other
> nodes and would configure my fixed nodes manually. I will not use
> SLAAC, and if I want privacy and temporary addresses, then I will use
> Privacy Extension RFC. If that RFC has any problems with generating
> the IID then I would extend the algorithm for IID generation there,
> without having something in between that does not have wide usage.

It doesn't have any "problems". It fixes part of the problem. But the
stable addresses still have room for improvements -- and thats what this
document tries to do.

Thanks,