> > > 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.
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. > > 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. 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 > problematic: when do they time out? 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. > "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. 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
