Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Feb 2013 14:40:46 +0000

I do not understand the following:

>    Bits 55 and 56 that correspond to U/L bits are set accordingly to the
>    recommendations. 

I suppose the reference is to the U and G bits (in positions 6 and 7
in the IID, or 70 and 71 in the IPv6 address, in IETF notation).
But what "recommendations" apply? The description in RFC 4291
refers to the equivalent bits in an IEEE address, so there is
no recommendation that is relevant to a VIN.

Also, I do not wish to broadcast my VIN number to the world.
While VIN numbers are not a big secret, associating my on line
transactions with my car's identity is definitely a big no-no.

Regards
   Brian

---

From: Scott Brim <[email-masked]>
Date: Tue, 19 Feb 2013 09:50:26 -0500

> transactions with my car's identity is definitely a big no-no.

Right.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Feb 2013 16:40:07 +0100

Le 19/02/2013 15:40, Brian E Carpenter a écrit :
>> Bits 55 and 56 that correspond to U/L bits are set accordingly to
>> the recommendations.
>
> in the IID, or 70 and 71 in the IPv6 address, in IETF notation). But
> what "recommendations" apply? The description in RFC 4291 refers to
> the equivalent bits in an IEEE address, so there is no recommendation
> that is relevant to a VIN.

(will check)

> Also, I do not wish to broadcast my VIN number to the world. While
> VIN numbers are not a big secret, associating my on line transactions
> with my car's identity is definitely a big no-no.

YEs, I agree with the concern.

Such a concern would be all the more valid if there were a specification
which said 'each vehicle MUST form its IIDs based on their VINs'.  But
this is not the case.  We are not trying for such a definitive document.

We are certain that some vehicles will never use this VIN-based
addressing scheme.  At that point, someone receiving a packet with a
certain source address will never know whether that packet is from a
vehicle or from something else.  A reversal of the IP into a number will
never be sure to be a VIN.

Alex

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

---

From: Doug Barton <[email-masked]>
Date: Tue, 19 Feb 2013 09:39:10 -0800

> never be sure to be a VIN.

But the fact that _some_ of them may be VINs make it a potential source 
of data mining, which should be avoided if at all possible.

There is no reason that manufacturers cannot keep their own mapping of 
VIN to IID, and making this process NON-standard (that is, not 
documenting a standard way to do it) will slightly decrease the value of 
that data, although wouldn't necessarily help the Ferrari-nee-Fiat 
problem. :)

Doug

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Feb 2013 21:40:14 +0100

Le 19/02/2013 18:39, Doug Barton a écrit :
>> Such a concern would be all the more valid if there were a
>> specification which said 'each vehicle MUST form its IIDs based on
>>  their VINs'.  But this is not the case.  We are not trying for
>> such a definitive document.
>>
>> addressing scheme.  At that point, someone receiving a packet with
>>  a certain source address will never know whether that packet is
>> from a vehicle or from something else.  A reversal of the IP into a
>> number will never be sure to be a VIN.
>
> But the fact that _some_ of them may be VINs make it a potential
> source of data mining, which should be avoided if at all possible.

Data mining should be avoided if possible.  The methods proposed are not
final, and they should be improved.

I would like to add about data mining.

Outside the VIN discussion, it is already possible to not use Privacy
Addresses.  For example, a recent experiment with IPv6 cellular client
shows me that the IPv6 addresses of the smartphone has the IID derived
from a manufacturer's ID.

To some extent this is a privacy issue, because data mining could find
out that the manufacturer of my equipment is that brand, and propose me
that brand when I buy a tablet on amazon.

In that sense, I doubt it is possible for anybody to impose the use of
Privacy Addresses (randon number in IID, if I am not wrong) to e.g. many
cellular operators.  It is still seen as an option (I think).

The same for VIN - if a use is found about the conversion of VIN to an
IP address, it is good to build in privacy, in a certain sense.  But
it's hard to make sure it's accepted.

Rejecting VIN-based addresses just because of privacy aspects is
debatable, IMHO.

> There is no reason that manufacturers cannot keep their own mapping
> of VIN to IID, and making this process NON-standard (that is, not
> documenting a standard way to do it) will slightly decrease the value
> of that data, although wouldn't necessarily help the Ferrari-nee-Fiat
> problem. :)

I agree.  Manufacturers may indeed keep their own mapping VIN-to-IID, or
other VIN-to-prefix mappings.  This would not be visible to Internet.

I would to stress further that the two drafts we propose are simply
methods.  One is to generate an IID and the other is to generate a ULA
prefix, each from same VIN.

Depending on how IID and ULA are combined, and how the connection to
Internet is made (tunnel or not, IPsec or not, etc) and how the address
architecture plan for vehicles is made, various Privacy issues may
arise, or may not.

I think I may need to actually better expose the problem: how to form
IPv6 addresses for vehicles. (yes we know these already exist: DHPCv6,
PRefix Delegation on cellular, stateless autoconf, NAT, NPT, 64share).

Alex

---

From: Scott Brim <[email-masked]>
Date: Tue, 19 Feb 2013 16:07:33 -0500

> final, and they should be improved.

Great.

> from a manufacturer's ID.

...

> Rejecting VIN-based addresses just because of privacy aspects is

"Here we need a change of approach: Businesses must use their power of
innovation to improve the protection of privacy and personal data from
the very beginning of the development cycle. Privacy by Design is a
principle that is in the interest of both citizens and businesses.
Privacy by Design will lead to better protection for individuals, as
well as to trust and confidence in new services and products that will
in turn have a positive impact on the economy. I have seen some
encouraging examples, but much more needs to be done." -- Viviane
Reding, Jan 2010

> PRefix Delegation on cellular, stateless autoconf, NAT, NPT, 64share).

That would be good.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 19 Feb 2013 13:08:21 -0800

> PRefix Delegation on cellular, stateless autoconf, NAT, NPT, 64share).
One of the questions I have in that context what special property of 
cars make them need a new method?
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 19 Feb 2013 22:49:41 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru
> Petrescu
> Sent: Tuesday, February 19, 2013 9:40 PM
> To: [email-masked]
> Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
 
> from a manufacturer's ID.

Of course it is, if it is not enabled, it's not enabled ... 

btw. The 3GPP specs forbid to base the IID on your number/MSISDN, IMSI 
or any other identifier. (just in case someone would want to make their life 
easier)

> cellular operators.  It is still seen as an option (I think).

Mobile Operators (following their Privacy departments) are very likely to request 
handsets with Privacy Extensions enabled by default, the same could be the case 
for all 'good' mobile stuff vendors.

Ales

---

From: Doug Barton <[email-masked]>
Date: Tue, 19 Feb 2013 19:19:21 -0800

> final, and they should be improved.

What the replies so far have said is that they should not be done at all.

> Addresses.

The fact that it's possible for people to voluntarily configure their 
system to be less private doesn't have anything to do with creating a 
system to tie VINs and IIDs that the user will not be able to opt out 
of. There are valid reasons not to use privacy addresses, there are no 
good reasons to do the latter at all, and many reasons that you shouldn't.

I snipped the rest of your argument along this line because it falls 
into the "faulty premises lead to faulty conclusions" fallacy.

> Rejecting VIN-based addresses just because of privacy aspects is

Any argument to the effect that there should be a way to tie together 
VINs and IIDs should come with sufficient justification to overcome the 
privacy concerns that have been almost universally expressed by a wide 
variety of posters (at least twice now). I haven't seen such a 
justification.

> other VIN-to-prefix mappings.  This would not be visible to Internet.

Then the problem is solved, full stop.

Doug