Hi, On Fri, Apr 5, 2013 at 7:41 AM, Roger Jørgensen <rog...@gmail.com> wrote: > On Thu, Apr 4, 2013 at 3:13 AM, Michael Richardson > <mcr+i...@sandelman.ca> wrote: > <snip> > >> If I can derive the VIN from the prefix, I agree that it helps identify >> the vehicle, but not really. If any of this stuff is going to be >> useful, there will already be a collision avoidance protocol that will >> tell each car (even when they are parked) where the other vehicles are, >> so that they can be avoided. >> >> If I can rederive the prefix from the VIN, then it seems we also have >> problems. >> >> What I'm saying is that I don't >> think that there are *new* >> privacy problems here. > > it's nothing really new with VIN's and IPv6, it's more that we again > was on the way of doing what has been done before and considered a not > so good idea. Doing 1 to 1 match between a hardware address and an > IPv6 address, and add meaning into the IPv6 address instead of > treating it for what it is, just an address that should be generated > somehow other than directly from a hardware address. >
*Concerning the Interface ID part* I guess you're referring to the EUI-64 (MAC) -> IPv6 address. While that mapping (L2->L3 to form a L3 address) is clearly wrong (tying one *interface* identifier to the whole *prefix* with no notion of the *endpoint ID*, please have a look at Saltzer and Soch discussions about naming and addressing and the comments of John day among others), you could consider the IID generated from the VIN as a *Site Identifier*. The fact that it is similar and fits in the same IID part of the IPv6 address does not mean they map the same way. Our mapping could be used with more than one prefix as it does not relate to one interface. In a multi-homing scenario (3GPP + 11p) this could be useful. > That it also has a privacy side issue with it don't make it any > better. Plenty of suggestion on how that can be used have been > mention. > > *Concerning the prefix generation part* The privacy concerns are tied to the address scope used with your ID (the ID being the information you don't want to give). You can have a look at : http://tools.ietf.org/html/draft-brim-mobility-and-privacy-01 for more information. - With the ULA scope (*local* with a border router *to be defined*), the VIN-based ULA does not change the privacy concerns of RFC 4193 if defined internally, meaning that the Mobile Router is a border router. This is *exacltly* what our draft says. - When trying to define a larger scope, our draft says it is possible in the exact same way that RFC 4193 does: by exchanging the routes among the participants. Meaning, two peers with two ULA prefixes could exchange the routes and start communicating. Policy could be installed in order not to allow such exchanges to occur between random unknown vehicles. In our testing, we assume a closed loop under the control of one operator. - The case where global communications based on such prefixes traverse the infrastructure *are not defined in our draft*. Again, our draft has the same RFC 4193 security concerns but addresses the collisions problems related to the random-generation method of the prefix in a vehicular only context and assures the generation of a collision-free Provider-Independent addressing space. The argument that *ties the privacy to the ID* and *not to the scope of the addresses (actual definition of provacy)* could be addressed by one-way hashing a part of the VIN. Using this approach results in a randomization of certain parts (or all) of the VIN before mapping into IPv6 addresses. *We'll obviously lose the collision-free characteristic of this addressing space which can be guaranteed only by the use of bijective conversion methods*. The modelisation of the tussle between uniqueness requirements and privacy concerns (dilemma) by the use of VIN addressing is an ongoing work. Sofiane -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
