Subject: Router advertisement based privacy - I-D: Action :draft-rafiee-6man-ra-privacy

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 23 May 2013 16:53:40 +0200

I first want to thank Dave who took the time to read and comment on my draft
and to discuss the problems associated with it. Based on some offline
discussions with Dave, I have changed this document to better address the
current issues with RFC 4941 which are actually related to differences in
interpretation of the wording used in the that document. In many cases the
wording used gives implementations the choice of how best to accomplish the
goal which can lead to bad choices being made which negates the purpose of
the document. This draft is thus an update to the Privacy Extension document
and also, because it does not allow a node to generate and use an IID based
on a MAC address, an update to one section of RFC 4862 which pertains to
this.

In this document an approach is recommend that doesn't make use MAC
addresses in the generation of public addresses. It does, in fact, endorse
the use other approaches that aren't based on the use of MAC addresses in
the generation of public addresses. Public addresses can be valid forever
but it is recommended that, for privacy purposes, a node not make use of
public addresses.

The definition of public addresses here is the same as what Dave explained
in his last responses to the people on this list, i.e., the addresses that
need to have DNS records. In my opinion, these addresses are more useful for
servers than other nodes.

I appreciate your support and any and all comments that you might proffer. 

Thank you,

Best,

Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 23 May 2013 17:04:34 +0200

Follow up,

I forgot to post the link to the draft :-)

http://tools.ietf.org/rfcdiff?url2=draft-rafiee-6man-ra-privacy

Thanks,

Best,

Hosnieh

Thank you,

Best,

Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 23 May 2013 17:16:31 +0200

follow up to the follow up:

sorry, I sent the wrong link the last time. this is the correct link:

http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy 

:-|  it is not my day.. :-/

Hosnieh

---

From: Ray Hunter <[email-masked]>
Date: Thu, 23 May 2013 19:36:27 +0200

Hosnieh Rafiee wrote:
> :-| it is not my day…… :-/
>
> Hosnieh
>
I have read this draft and I don't particularly like it for several
operational reasons.

1) Use of purely random unpredictable IIDs appears to impose an ISP
model of working where there is no trust relationship between the end
node and the network infrastructure.

In corporate environments it is very important that cross-correlation of
log events can occur to support various operational processes (also over
longer periods of time and for examining historical records). IPv4 did
not randomly rotate end node identifiers in an uncorrelated manner, and
the consequences of this new behaviour could be far reaching.

Even in an ISP environment, there is a requirement in many countries for
a log of identifiers that have been used for communication to be
available to law enforcement agencies. It could be argued that
maintaining the relationship between the /64 prefix and the natural
person holding the ISP contract would be sufficient, but some countries
might not accept this, and impose a requirement to log all IIDs that
have been used, which would be a significant burden on storage.

2) Section 3.1. Updating the IID after DAD has completed may disrupt
existing communications and applications.

Also if there is a collision, simply incrementing the modifier will
guarantee another collision if two colliding nodes are operating
draft-rafiee-6man-ra-privacy-03.

3) Section 5 & Section 6 requires dynamic DNS updates. In the event that
an implementer wishes to rotate these records for privacy reasons, there
may be unexpected consequences in the name space, especially in the
presence of distributed DNS with e.g. caching only servers. How would
they know to update their cached records? I think there's a lot more
detail required here on treatment of TTL of e.g. AAAA records, plus
handling of existing sessions. Applications using UDP could also be
problematic: when do they time out?

"In cases where the router prefix changes, the node MUST cut the
connection."
Hmmm unhappy eyeballs and potential negative impact on graceful
renumbering of RFC2894.

4) rotating the IID of link local address and other addresses could have
other unforeseen operational consequences on e.g. static routes, dynamic
routes that point to the end node, ACLs, DSCP QoS, Bandwidth Policing,
VPN tunnel endpoints, Intrusion Detection Systems, load balancers,
outbound firewall access authorisation .... everything where the IPv6
address is assumed to be largely time invariant and is used as a key to
some other relationship. I'd like some more detail of that.

regards,
RayH

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 May 2013 12:33:53 +0100

Hi,

Can you clarify, succinctly, what your proposal adds that you cannot achieve by a combination of http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ and RFC4941?

It seems a key point is that 4941 "only" says SHOULD for the IID regeneration when the prefix changes.  Yet afaics all implementations do this?

Tim

On 23 May 2013, at 16:04, "Hosnieh Rafiee" <[email-masked]> wrote:

> I first want to thank Dave who took the time to read and comment on my draft and to discuss the problems associated with it. Based on some offline discussions with Dave, I have changed this document to better address the current issues with RFC 4941 which are actually related to differences in interpretation of the wording used in the that document. In many cases the wording used gives implementations the choice of how best to accomplish the goal which can lead to bad choices being made which negates the purpose of the document. This draft is thus an update to the Privacy Extension document and also, because it does not allow a node to generate and use an IID based on a MAC address, an update to one section of RFC 4862 which pertains to this.
>  
> In this document an approach is recommend that doesn't make use MAC addresses in the generation of public addresses. It does, in fact, endorse the use other approaches that aren't based on the use of MAC addresses in the generation of public addresses. Public addresses can be valid forever but it is recommended that, for privacy purposes, a node not make use of public addresses.
> The definition of public addresses here is the same as what Dave explained in his last responses to the people on this list, i.e., the addresses that need to have DNS records. In my opinion, these addresses are more useful for servers than other nodes.
>  
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 May 2013 12:36:20 +0100

> the consequences of this new behaviour could be far reaching.

Well, I think the jury is out on use of 4941 in enterprise environments. There are advantages and disadvantages. Accountability is still manageable.

But in general I agree with Ray's points.

Tim

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 24 May 2013 14:20:15 +0200

> > In corporate environments it is very important that cross-correlation
> > of log events can occur to support various operational processes (also
> > over longer periods of time and for examining historical records).
> > IPv4 did not randomly rotate end node identifiers in an uncorrelated
> > manner, and the consequences of this new behaviour could be far
reaching.
> 
> Well, I think the jury is out on use of 4941 in enterprise environments.
There
> are advantages and disadvantages. Accountability is still manageable.
> 

If the monitoring is the key role in your network and you have access to the
inside of your whole network, the question is why you sacrifice your users
privacy by having the same IID forever in the same network? You can use a
monitoring system where log the MAC and IP addresses of the pcs. If the IP
addresses changes, you can still monitor them based on their MAC and log
this new IP address for this computer for further usage or any new events
and keep this log for a certain period of time. 

Thanks for your comments.
Regards,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 24 May 2013 15:32:41 +0200

Hi Tim,
>Can you clarify, succinctly, what your proposal adds that you cannot
achieve by a combination
of http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/
 and RFC4941?

I do not want to open up the old discussion here again. If you use RFC 4941
or in other word you enable the current implementations of RFC 4941 with any
other documents, you did not address the problems explained in my draft
about RFC 4941. You just used the current implementations with their current
problems. The reason that I wrote this draft was that the "stable addresses"
wanted to keep its IID within the same network and not assign several IIDs
within the same networks, in contrary with RFC 4941. In my opinion, there is
problems of leakage of users' private information such as bank accounts,
names, pictures, etc during the time that the node has the same IID. This
problem is more remarkable when the time the node is in the same network for
a long time or permanently. 
RFC 4941 could better handle the privacy consideration but It also has some
problems such as:
- still the IID generated based on the MAC might be valid
- cutting the  connections to other nodes when the lifetime of the IID is
expired.
-etc

>It seems a key point is that 4941 "only" says SHOULD for the IID
regeneration when the prefix changes.  Yet afaics all implementations do
this?

Yes because many of them did not choose the best option for IID generation
and there might be a correlation between their generated IID which helps the
attacker understand this is the same node.

Thanks,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 24 May 2013 17:17:58 +0200

> I have read this draft and I don't particularly like it for several
operational
> reasons.
> 
> 1) Use of purely random unpredictable IIDs appears to impose an ISP model
of
> working where there is no trust relationship between the end node and the
> network infrastructure.
> 
log
> events can occur to support various operational processes (also over
longer
> periods of time and for examining historical records). IPv4 did not
randomly
> rotate end node identifiers in an uncorrelated manner, and the
consequences
> of this new behaviour could be far reaching.
> Even in an ISP environment, there is a requirement in many countries for a
log
> of identifiers that have been used for communication to be available to
law
> enforcement agencies. It could be argued that maintaining the relationship
> between the /64 prefix and the natural person holding the ISP contract
would
> be sufficient, but some countries might not accept this, and impose a
> requirement to log all IIDs that have been used, which would be a
significant
> burden on storage.

I just wonder why, when you can use a monitoring system to log all your
events (MAC + IP) when you are inside a corporate network, you see this as a
big issue. You can also rotate your logs so that a large amount of storage
is not necessary. Why would you sacrifice your user's privacy over a
logging issue? If you really have no concern about  user privacy,  then that
become another decision and you can use public IP addresses, that are not
generated based on MAC addresses, and use them for an unlimited time which
is explained in the draft. You can use either this draft or any other
approach.

> 2) Section 3.1. Updating the IID after DAD has completed may disrupt
existing
> communications and applications.
> 
guarantee
> another collision if two colliding nodes are operating
draft-rafiee-6man-ra-
> privacy-03.

This is not true. Of course if your two nodes can predict the future, then
that becomes another issue which is not in the scope of my draft : -) . What
is the probability of the node choosing the same modifier  (16 bytes number)
and reading the computer time at the same instant in order to pick up the
same timestamp? And, if there is collision, what is the probability of the
node being able to repeat this process at the same time? 
CPU load and many other factors have an effect on this process which, in
general, makes the probability so low that it can be ignored.

> 3) Section 5 & Section 6 requires dynamic DNS updates. In the event that
an
> implementer wishes to rotate these records for privacy reasons, there may
be
> unexpected consequences in the name space, especially in the presence of
> distributed DNS with e.g. caching only servers. How would they know to
update
> their cached records? I think there's a lot more detail required here on
> treatment of TTL of e.g. AAAA records, plus handling of existing sessions.

Here you are talking about the use of public addresses which is explained in
the draft. About Dynamic Update, I do not believe that today anybody uses
open DNS update or allows nodes to update their DNS records without the use
of a security mechanism. Using security for DDNS is inevitable. So when you
use security for DNS, you can simply use one of the security approaches of
DDNS. One example is  the CGA-TSIG draft for a secure dynamic update and for
observing privacy.  

> Applications using UDP could also be

It is application based and as such the connection can be maintained for as
long as this application needs the connection.  I also have another
suggested  improvement to the draft for application layer connections that
is one of the key topics for discussion in the ra-privacy draft.

connection."
> Hmmm unhappy eyeballs and potential negative impact on graceful

I will change this sentence to the following:  "still can keep the old
connections but MUST use a new IID with the new RAs" . This addresses the
renumbering issue. I will improve this part as I did not consider
renumbering.

> 4) rotating the IID of link local address and other addresses could have
other
> unforeseen operational consequences on e.g. static routes, dynamic routes
that
> point to the end node, ACLs, DSCP QoS, Bandwidth Policing, VPN tunnel
> endpoints, Intrusion Detection Systems, load balancers, outbound firewall
> access authorisation .... everything where the IPv6 address is assumed to
be
> largely time invariant and is used as a key to some other relationship.
I'd like
> some more detail of that.

In the draft there is an explanation about link local addresses that is
different than privacy addresses. This is because it is not really important
to change the local link addresses  when others can see your MAC address.
When you expose your Identity via MAC, then privacy does not make sense.
Here I will give a brief explanation about the other issues. If you are
using VPN, then you can keep your connection for as long as you are using
it. I am not sure, but I think you use bandwidth policy not based on the IP
but based on the usernames or flow based control.  If the application needs
a fixed public address, then the question becomes why would you use  this
draft or any other documents that pertain to privacy?
If we are talking about privacy, then we need to also make changes to the
firewalls, like the way  DDNS does. This all pertains to application
considerations for privacy. When we want to take steps toward privacy, we
need to improve many of the current systems. This will not happen in one or
two days as this or many other drafts will not be implemented in one or two
days.

@ Tim: Sorry for bad English in the last messages. When I use a touch screen
device with a small screen to send messages it is really hard to recheck the
sentences.

Thanks,
Regards,
Hosnieh

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 May 2013 17:07:19 +0100

Comments in-line...

> is explained in the draft. You can use either this draft or any other

At our site we do just this; an SNMP-based tool harvests IP/MAC/port data from the switches,routers etc.  I agree that it works very well.

That said, I expect quite a few (enterprise) sites will try to disable 4941. Or if they use ULAs as well, to disable for ULAs for internal traffic. That's their choice. 

The question is just what additional privacy you're delivering. In principle, 4941 addresses could be put in the DNS, or could be passed to peers to use for communications. Conceptually, it may be simpler to have just two classes of address; stable privacy addresses (as per Fernando's text) and "temporary" privacy addresses which change over time (RFC 4941), whether the addresses are used to initiate or receive connections.

My current feeling is that we have Fernando's stable privacy draft that's getting quite close to being done (I hope :) and we of course have 4941.  I would personally prefer to see Fernando's text published, and then - if you feel it necessary - you could issue a proposal for any additional functionality you believe is needed beyond that, or for perceived fixes to 4941. You may have valid points to make, e.g. regarding requirements on dynamic DNS when using that, but it would be easier to assess them after the publication of Fernando's work.

In the meantime, it would be helpful if your draft listed the existing privacy concerns you have, and the key benefits of your proposed mechanism(s) as easy-to-parse bullet points in your text.  You can take out some of the more general comments about privacy, e.g. the first paragraph of the introduction.  Make the abstract more snappy, move the points in there to bullet-point concerns in the main body, and make your proposed solution clearer.  I think that would help other readers as well.  Just a suggestion at least.

> renumbering issue. I will improve this part as I did not consider

Check RFC4192 about non-flag day renumbering.  In homenet though, we might see such "flash" renumbering.  These are important considerations.

> When you expose your Identity via MAC, then privacy does not make sense.

This is a nice property of Fernando's draft. A "random" IID per prefix, with non-disclosure of MAC.

> two days as this or many other drafts will not be implemented in one or two

Well, there are many knock-on effects of peers changing IP addresses over time. Many of these have been discussed in the context of renumbering.

> device with a small screen to send messages it is really hard to recheck the

Actually, Ray wrote the comments above, but I'm impressed how much you wrote on a small screen :)

Tim

---

From: Ray Hunter <[email-masked]>
Date: Fri, 24 May 2013 18:53:44 +0200

> Thanks for your comments.

I think you greatly underestimate and trivialise the proliferation of
operational processes and systems that use an IP address as a node
identifier and as a key to other data, and that rely on it being largely
time invariant/ stable (at the very least for a decent caching interval
so that it doesn't have to be resolved for every inbound
packet/connection being processed, or for the time that the machine is
switched on). I think that risk is well worth noting in your draft.

You only have to look at something like ~/.ssh/known_hosts, where a flat
file uses an IP address to associate a server with a public key, to see
how widespread this practice is. If you want it to stop this practice 1)
it's going to be a long and painful process 2) you'll probably need to
provide a viable alternative source for node identifiers and/or user
identifiers.

Otherwise if something like my SSH server process decides to time cycle
it's IP address and dynamically update DNS due to a lifetime timing out
1) it is likely that every single long-lived remote SSH session will be
broken at some point,
2) upon reconnection to the new server address registered in DNS, all
users will likely be asked to relearn/reconfirm the trust relationship
with the server.

That trust association can't be trivially repaired for an automatic/cron
process without an alternative trusted source of node identifier.

This is just one of a myriad of examples.

regards,
RayH

---

From: Doug Barton <[email-masked]>
Date: Fri, 24 May 2013 20:26:11 -0700

On 05/24/2013 08:17 AM, Hosnieh Rafiee wrote:
> big issue.

I work primarily with customers who implement networks inside their own 
borders. Ray is 100% correct that stable addressing for end users is a 
very high priority for things like access control, accountability, 
reporting, SOX, etc. Whether or not it should  be so is an entirely 
different question. For the middle of the bell-shaped curve, it IS so.

For IPv6 purposes, I can tell those customers to turn off 4941 addresses 
and they're good to go. What I cannot do is tell them, "IPv6 addresses 
constantly rotate, so you will have to log every data connection, keep 
those logs for N {weeks|months|years}, and use them to find out who did 
what when, instead of going to the tool you use now which will tell you 
that in 2 seconds." If I tell customers that this is the cost of IPv6, 
they will simply tell me "No thank you," and continue using their 
(comfortable, familiar) 1918 addresses internally behind their NAT.

We have to stop the line of thinking that goes, "We can introduce $this 
cool new feature to IPv6, and the cost is only $so_much." "The Market" 
has already responded with deafening silence to the costs that already 
exist to migrate to IPv6. Adding more is not an option.

Doug

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 25 May 2013 17:30:57 +0200

> At our site we do just this; an SNMP-based tool harvests IP/MAC/port data
from
> the switches,routers etc.  I agree that it works very well.
> 
> That said, I expect quite a few (enterprise) sites will try to disable
4941. Or if
> they use ULAs as well, to disable for ULAs for internal traffic. That's
their
> choice.
> 
> The question is just what additional privacy you're delivering. In
principle, 4941
> addresses could be put in the DNS, or could be passed to peers to use for
> communications. Conceptually, it may be simpler to have just two classes
of
> address; stable privacy addresses (as per Fernando's text) and "temporary"
> privacy addresses which change over time (RFC 4941), whether the addresses
> are used to initiate or receive connections.

This is not something different from RFC 4941 or new, but just an update to
clarify the choice of  words used in the RFC that deals with the handling of
the lifetime. Some implementations did not make a good option choice which
then allowed for a correlation to be made between their generated IIDs. It
will not change the main nature of RFC 4941. Thus, if an enterprise wants to
use it, then they can do so. You can also use the privacy addresses in DNS,
but in this case I think it would be better to   generate the privacy
addresses using CGA or SSAS (new version). 
http://www.ietf.org/mail-archive/web/ipv6/current/msg17760.html
You can then use CGA-TSIG for dynamic DNS updates and solve both the problem
for privacy and DNS update. 

> In the meantime, it would be helpful if your draft listed the existing
privacy
> concerns you have, and the key benefits of your proposed mechanism(s) as
> easy-to-parse bullet points in your text.  You can take out some of the
more
> general comments about privacy, e.g. the first paragraph of the
introduction.
> Make the abstract more snappy, move the points in there to bullet-point
> concerns in the main body, and make your proposed solution clearer.  I
think
> that would help other readers as well.  Just a suggestion at least.

Thanks , I will do it in the next version.

Thanks again,
Regards,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 25 May 2013 18:06:39 +0200

> borders. Ray is 100% correct that stable addressing for end users is a
very high
> priority for things like access control, accountability, reporting, SOX,
etc.
> Whether or not it should  be so is an entirely different question. For the
middle
> of the bell-shaped curve, it IS so.

As I explained in my answer to Ray in my last message, if monitoring and
other things are your first priority, then you can use another approach
rather than that of RFC 4941. But  you cannot say that this RFC will not be
used in future because we think that our customers won't want to spend any
more pennies on their current systems. It is again their choice. There are
also customers who would prefer to use that RFC rather than another
approach. 
What I am trying to do in my draft is give customers, who want to use this
RFC 4941, have a better choice of implementation options than they do now
(it might be used along with any other approach that is not based on the use
of a MAC address) 
About privacy. The laws of many countries are not concerned with privacy
which is actually the opposite of what is true in other countries. An
example can be found in the EU  where there are two DPDs, one promulgated in
1995 and the other in 2012. Both were concerned with privacy, but after the
first one was not interpreted correctly by all countries the second one was
promulgated.  Your country might be among those countries where privacy
makes little sense to them. Some countries talk about privacy, but in action
and reality, there is no privacy for users.

Regards,
Hosnieh

---

From: Doug Barton <[email-masked]>
Date: Sat, 25 May 2013 15:39:00 -0700

On 05/25/2013 09:06 AM, Hosnieh Rafiee wrote:
> more pennies on their current systems.

Hosnieh,

You are responding to something I didn't write, and ignoring what I did. :)

I'm ambivalent about your draft itself. What I responded to was your 
reply to Ray that organizations that need accountability can simply do 
more network probing, more logging, etc.

Doug

---

From: Fernando Gont <[email-masked]>
Date: Sun, 26 May 2013 14:27:31 +0200

On 05/24/2013 03:32 PM, Hosnieh Rafiee wrote:
> within the same networks, in contrary with RFC 4941. 

This is plain wrong.

RFC4941 calls for stable *and* temporary addresses.
draft-ietf-6man-stable-privacy-addresses improves the current stable
addresses.

You keep making statements that you don't back in any way... and that's
an inappropriate way of having a technical discussion.

> In my opinion, there is

Please add and elaborate on this in your I-D, because I don't follow the
relationship between bank accounts and IPv6 addresses.

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