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

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Apr 2013 12:00:23 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    >> On 04/02/2013 12:55 PM, Alexandru Petrescu wrote:
    >>>> IMO, you should follow what appears to be the consensus on the
    >>>> subject: set the IID in whatever way you want,
    >>> 
    >>> About this there is a tendency to agreement.  The privacy aspect
    >>> should be considered, balanced by a privacy-to-mobility tradeoff.
    >> 
    >> Which privacy aspect?

    Alexandru> Offer privacy by default: avoid a reversible mapping VIN-to-
    Alexandru> InterfaceID.  Because, if a reversible mapping
    Alexandru> VIN-to-InterfaceID 
    Alexandru> existed, then it could be exploited by attackers by
    Alexandru> reversing the 
    Alexandru> InterfaceID back into VIN, and exposing this personal
    Alexandru> information to

So, I have a question: how much privacy is actually contained in the
VIN or indexed by the VIN?   Given that it's printed on the windshield.
Yes, it contains model, year and manufacturer of the car, but all of
that information is also visible by looking at the vehicle.  

So the concern is that it be if the VIN can be discovered during an
online transaction of some kind that bad things can happen.  Is any
priviledge going to be attached to the *VIN* itself (or to the address
derived from the VIN).  Note that this doesn't meant that the car
doesn't have a private key with a certificate attaching that private key
to the VIN such that the vehicle can do interesting things with the
manufacturer systems, etc.

If there are databases indexed by VIN, I wonder if that in itself isn't
a violation of privacy given that the VIN is rather publically
displayed.
(I imagine the Department of Motor Vehicles/DMV-equivalent) does this.
The DMV database is sometimes protected, sometimes private, and in some
jurisdictions rather porous if 1970 era episodes of Rockford Files and
Riptide are to be believed).

I am way more concerned about privacy concerns where the VIN, given that
it can be easily known, can then be used to derive the prefix that the
vehicle uses and then seek out that vehicle's systems electronically.

So, I'm saying that VIN->prefix via hash may be great protection for the
VIN, but it might be poor protection for the prefix.  

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Apr 2013 23:36:17 +0000

> that information is also visible by looking at the vehicle.  

The fact that the VIN is printed on the windshield is not as practical a problem as it would be if the VIN could be trivially retrieved electronically.   How big a privacy issue that is, I don't know, but it would certainly make tracking the car easy.

> vehicle uses and then seek out that vehicle's systems electronically.

Indeed, if a car thief wanted to hack their way into the car to steal it, being able to read the VIN off the window and then immediately identify which messages were coming from that car would be a minor or major problem, depending on how bad the security on the car was.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Apr 2013 21:00:11 -0400

>>>>> "Scott" == Scott Brim <[email-masked]> writes:
    >> So, I have a question: how much privacy is actually contained in
    >> the VIN or indexed by the VIN?   Given that it's printed on the
    >> windshield. Yes, it contains model, year and manufacturer of the
    >> car, but all of that information is also visible by looking at the
    >> vehicle.

    Scott> I figured you knew this already - it's about correlation.  IP
    Scott> addresses, for a familiar example, are not a problem in and of
    Scott> themselves.  However, they are considered personal
    Scott> information, not to

a) This is true of all IP addresses, regardless of how they are derived.

b) In general, we aren't talking about IP addresses that will be used to
   communicate out to the Internet, but rather within a vehicle, and 
   possibly with adjacent vehicles.
   (PLEASE recall, the internet protocol suite	is used for more than
   just the Internet) 

   So, while you can get correlation easily from addresses, you can also
   get them from license plates, and probably a dozen other wireless
   technologies already present	in vehicles (like the tire pressure
   systems we keep hearing about)...

What *additional* privacy violation does knowledge of the VIN do?

Or alternatively, what network attacks become possible if you have
knowledge of the VIN, which means that you know what the internal
addresses are?

    Scott> goes to the FBI office in the next town, for example.  Same
    Scott> with a VIN 
    Scott> -- the problem is not exposing the VIN, it's having the VIN be
    Scott> associated with many other personal attributes on open networks.

I'm not convinced that there are any advantages to deriving a
vehicle-specific prefix from the VIN.  It seems that vendors should get
space from the RIRs, and allocate the numbers 1.2.3.4., etc.  
If they want to do this from the VIN, they should do this with a keyed
hash and keep the key private.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Apr 2013 21:13:20 -0400

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:

    Ted> The fact that the VIN is printed on the windshield is not as
    Ted> practical a problem as it would be if the VIN could be
    Ted> trivially retrieved electronically.   How big a privacy issue
    Ted> that is, I don't know, but it would certainly make tracking the
    Ted> car easy. 

So, we have assumed that a 802.11p sniffer sitting in Times Square can
sniff the prefix used by passing vehicles.  If I put another sniffer
outside Wrigley Field, I can do correlation... how does knowing the VIN
help me?  I already know it is the same car.

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. 

    >> vehicle uses and then seek out that vehicle's systems electronically.

    Ted> Indeed, if a car thief wanted to hack their way into the car to
    Ted> steal it, being able to read the VIN off the window and then
    Ted> immediately identify which messages were coming from that car
    Ted> would be a minor or major problem, depending on how bad the
    Ted> security on the car was. 

If there are security problems with the car security system, I don't
think the problem of identifying the vehicle by VIN is a hurdle.  

Use ICMP echo ("ping") RTT as sonar (see, it was named probably), and when you
are nearby, tell the vehicle to turn itself on, honk the horn, and pop
the trunk.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Apr 2013 02:14:23 +0000

> help me?  I already know it is the same car.

Yes, indeed, this seems to argue for vehicles renumbering on a regular basis, at least on the prefix that they are using to communicate with the outside world.

---

From: Scott Brim <[email-masked]>
Date: Wed, 3 Apr 2013 13:51:53 -0400

On 04/03/13 12:00, Michael Richardson allegedly wrote:
>>>>> IMO, you should follow what appears to be the consensus on
>>>>> the subject: set the IID in whatever way you want,
>>>> 
>>>> About this there is a tendency to agreement.  The privacy
>>>> aspect should be considered, balanced by a
>>>> privacy-to-mobility tradeoff.
>>> 
>>> Which privacy aspect?
> 
> Alexandru> Offer privacy by default: avoid a reversible mapping
> VIN-to- Alexandru> InterfaceID.  Because, if a reversible mapping 
> Alexandru> VIN-to-InterfaceID Alexandru> existed, then it could be
> exploited by attackers by Alexandru> reversing the Alexandru>
> InterfaceID back into VIN, and exposing this personal Alexandru>
> information to
> 
> So the concern is that it be if the VIN can be discovered during
> an online transaction of some kind that bad things can happen.  Is
> any priviledge going to be attached to the *VIN* itself (or to the
> address derived from the VIN).  Note that this doesn't meant that
> the car doesn't have a private key with a certificate attaching
> that private key to the VIN such that the vehicle can do
> interesting things with the manufacturer systems, etc.

I figured you knew this already - it's about correlation.  IP
addresses, for a familiar example, are not a problem in and of
themselves.  However, they are considered personal information, not to
be revealed without justification, because they are relatively
constant across multiple interactions, in all of which one or more of
a person's identifying tokens will be present (e.g. cookies or an
email address or just a session layer ID).  Not only that but as you
move and your IP address changes, the new IP address's traffic can be
correlated with the old one, because some other details persist across
the change.  Because of that, because different pieces of communicated
information have overlapping lifetimes, correlations can be drawn
between many of them and all sorts of stuff can be gleaned.  I can
find out that the guy I've hired as a contract killer occasionally
goes to the FBI office in the next town, for example.  Same with a VIN
- -- the problem is not exposing the VIN, it's having the VIN be
associated with many other personal attributes on open networks.

Scott

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 4 Apr 2013 01:18:52 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Richardson

>     think that there are *new*

I would agree with that comment, but then again, I don't see any compelling reason (nor any advantage) to use the VIN in the IPv6 address anyway. So privacy concerns or no, I would reiterate my suggestion that if the VIN is used, it be used as part of a DNS name, rather than an integral part of the address.

Bert

---

From: Scott Brim <[email-masked]>
Date: Thu, 4 Apr 2013 10:02:33 -0400

On 04/03/13 21:13, Michael Richardson allegedly wrote:
> 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.

The car is less of an issue than the people.  If you start with the
VIN in packets over radio, you can the owner, and then do correlations
to derive personal information.  Yes you can figure out if the owner
is the one communicating, to start with, based on previous info.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Apr 2013 11:02:19 -0400

>> help me?  I already know it is the same car.

    Ted> Yes, indeed, this seems to argue for vehicles renumbering on a
    Ted> regular basis, at least on the prefix that they are using to
    Ted> communicate with the outside world. 

Yes.
I used two locations, but I assumed that whomever owns the road-side
lighting system has thousands of such sniffers.  

I think that imadali-its-vinipv6 is the wrong idea.  If it is useful for
a manufacturer to derive a subnet-ID from a VIN, that's fine, but I
think it's a private matter.  Let's write a BCP on how a manufacturer
might do this in a way such that the the VIN <-> subnet prefix mapping
is neither reversable, nor is it reproduceable.
(I.e. I can't get the VIN from the subnet-ID, and I also can't get the
subnet-ID from the VIN)

Only the manufacturer *might* know the mapping, and maybe we can write
the BCP such that the manufacturer can forget it too.  The manufacturer
likely goes to get RIR space just like any other Enterprise.

---

From: Roland Bless <[email-masked]>
Date: Thu, 04 Apr 2013 17:59:08 +0200

Hi,

On 04.04.2013 17:02, Michael Richardson wrote:
> I think that imadali-its-vinipv6 is the wrong idea.  If it is
> useful for a manufacturer to derive a subnet-ID from a VIN, that's
> fine, but I think it's a private matter.  Let's write a BCP on how
> a manufacturer might do this in a way such that the the VIN <->
> subnet prefix mapping is neither reversable, nor is it
> reproduceable. (I.e. I can't get the VIN from the subnet-ID, and I
> also can't get the subnet-ID from the VIN)
> 
> Only the manufacturer *might* know the mapping, and maybe we can
> write the BCP such that the manufacturer can forget it too.  The
> manufacturer likely goes to get RIR space just like any other
> Enterprise.

Our initial proposal [1] was to use
rightbits(SHA-2(VIN | OEM-specific-256bit Key), 40)
to algorithmically generate the Global-ID of a ULA-Prefix. As long
as the key is kept secret, it would not be reversable or
derivable from the VIN.
Using a global prefix from an RIR is certainly another viable
alternative.

[1]
http://www.lara.prd.fr/_media/ipv6-its/2012-03-26-seis-kit-ietf83-its.pdf

Regards,
 Roland

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Apr 2013 19:19:02 +0200

Le 04/04/2013 03:18, Manfredi, Albert E a écrit :
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Michael Richardson
>
>
>> What I'm saying is that I don't think that there are *new* privacy
>> problems here.
>
> I would agree with that comment, but then again, I don't see any
> compelling reason (nor any advantage) to use the VIN in the IPv6
> address anyway. So privacy concerns or no, I would reiterate my
> suggestion that if the VIN is used, it be used as part of a DNS
> name, rather than an integral part of the address.

Some applications involving the use of VIN may have been discussed.

One requirement may come from V2V communications when infrastructure is
not available: how to know the IP address of the seen vehicle when DNS
is unavailable.

Other requirement of using parts of the VIN would be remote software
update: extract the field of the VIN which represents Manufacturer ID,
make an IPv6 multicast group of it, and send the update accordingly.

These are just ideas having been floated in various contexts.

VIN-to-IPv6-InterfaceIdentifier is just one little thing which could or
not could not work.

Alex

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Apr 2013 18:01:33 +0000

On Apr 4, 2013, at 1:51 PM, Richard Roy <[email-masked]> wrote:
> Furthermore, anonymity concerns and the simultaneous morphing of all content
> in these safety messages that could be used to infer behavior and violate
> privacy are being addressed within the IEEE 1609.2 and ETSI TC ITS security
> working groups (as well as in the SafetyPilot program in the US). 

That's good to hear, although are you addressing the IP layer privacy issues, or just the link layer issues?   It doesn't do us any good to have privacy-supporting link-layer addresses if we screw that up at the IP layer.

In any case, I think it's worth making sure that however this problem gets solved, we talk about it and describe how it is solved, even if how it is solved is "in this IEEE spec."

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 4 Apr 2013 19:56:12 +0000

> From: Alexandru Petrescu [mailto:[email-masked]]

> not available: how to know the IP address of the seen vehicle when DNS

If these comms are tactical, I would go to something more like 802.11 ad-hoc network, and do the comms at layer 2. Alternatively, the vehicle can use its assigned IPv6 /64 prefix (which need not be related to anything specific like a VIN), and then use MANET. Seems built to order for MANET, no?

> make an IPv6 multicast group of it, and send the update accordingly.

For that, I would way prefer using the VIN as part of a DNS name, which is then mapped to the IP address of the vehicle. This makes the problem more amenable to flexible solutions, like allowing the IP address prefix to be changed periodically, or allowing the vehicle ID to be associated in any number of ways, other than just a VIN.

By the way, this vehicle application of IPv6 is another example that makes me kringe about the waste of even IPv6 address space, when we continue to discourage the use of longer than 64-bit prefixes.

Bert

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 5 Apr 2013 00:08:44 +0200

On 4/4/13, Manfredi, Albert E <[email-masked]> wrote:
> If these comms are tactical, I would go to something more like 802.11 ad-hoc
> network, and do the comms at layer 2. Alternatively, the vehicle can use its
> assigned IPv6 /64 prefix (which need not be related to anything specific
> like a VIN),

we need to be specific to make better communication, we don't want
best effort, we want intelligent service, MANET solution is not
specific for ITS but VIN solution may be,

> and then use MANET. Seems built to order for MANET, no?

What is MANET? how can you use it for ITS? MANET is a general not specific,

> For that, I would way prefer using the VIN as part of a DNS name, which is
> then mapped to the IP address of the vehicle. This makes the problem more
> amenable to flexible solutions, like allowing the IP address prefix to be
> changed periodically, or allowing the vehicle ID to be associated in any
> number of ways, other than just a VIN.

ok, we can discuss/amend  VIN to a better approach,

AB

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Apr 2013 02:07:48 +0000

On Apr 4, 2013, at 7:44 PM, Richard Roy <[email-masked]> wrote:
> [RR>] As I am sure you know, privacy is a cross-layer issue.  Any layer that
> compromises privacy, compromises it for the user/ITS station.  That said,
> FNTP/WSMP replace the IP layer with a different albeit null) networking
> protocol (essentially a simple port mapping protocol that has as few as 3
> bytes of protocol "overhead") designed to be small and efficient and
> tailored to the simple single-hop broadcast over capacity constrained RF
> channels.

So that possibly makes sense internally to the car, although possibly not.   It doesn't make a lot of sense to me between cars, except perhaps in the most restricted applications.   When you talk about capacity constrained RF channels, it sounds like you're talking about car-to-car traffic, or car-to-infrastructure traffic.   But this constrained port mapping protocol sounds way too restrictive for either of those contexts.

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 5 Apr 2013 07:41:18 +0200

On Thu, Apr 4, 2013 at 3:13 AM, Michael Richardson
<[email-masked]> wrote:
<snip>

>     think that there are *new*

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.

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.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: sofiane Imadali <[email-masked]>
Date: Fri, 5 Apr 2013 17:45:53 +0200

Hi,

> 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.

> better. Plenty of suggestion on how that can be used have been

*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

---

From: joel jaeggli <[email-masked]>
Date: Sun, 07 Apr 2013 08:07:56 -0700

> So that possibly makes sense internally to the car, although possibly not.   It doesn't make a lot of sense to me between cars, except perhaps in the most restricted applications.   When you talk a…
neither 802.11p or generic wifi are particularly capacity constrained.
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ted Lemon <[email-masked]>
Date: Sun, 7 Apr 2013 15:24:01 +0000

> neither 802.11p or generic wifi are particularly capacity constrained.

Right, I have subsequently learned that in fact there is work being done to use wireless inside the car to save on wiring.   This probably still has privacy implications, since the RF shielding on the car is likely not good enough to completely prevent snooping, but if the identifiers being used are this constrained, it may not be a significant issue.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 08 Apr 2013 11:47:02 +0200

Le 04/04/2013 21:56, Manfredi, Albert E a écrit :
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]]
>
>> One requirement may come from V2V communications when
>> infrastructure is not available: how to know the IP address of the
>> seen vehicle when DNS is unavailable.
>
> If these comms are tactical, I would go to something more like
> 802.11 ad-hoc network, and do the comms at layer 2.

YEs, the link between egress WiFi interfaces of each vehicle (not their
ingress WiFi interfaces - in-car), could form a typical 802.11 ad-hoc
network.

The communications on that link may be layer but could also be IP.

> Alternatively, the vehicle can use its assigned IPv6 /64 prefix
> (which need not be related to anything specific like a VIN),

A /64 inside a vehicle may not be used to be assigned on the link
_between_ vehicles, because there is a Router between the inside and the
outside of the vehicle.  This inside-vehicle prefix could be 'announced'
to the other vehicle, but not assigned on that adhoc network.

About the non-VIN aspect: the inside-vehicle IPv6 /64 prefix may indeed
be tightly related to that vehicle, without using VIN.  For example, it
could be dynamically configured using DHCP: the MR in vehicle runs
Mobile IP and then executes DHCP Prefix Delegation to its Home Agent.
The prefix thus obtained is for that particular vehicle.

When doing so, one may be interested to dynamicall configure always same
prefix for that particular vehicle.  That could be realized by using MAC
address: do DHCP and put the MAC address of the requesting interface.
But many egress interfaces (such as LTE) don't have MAC addresses.  One
may then put a NAI (Network Access Identifier).  But NAI is under the
form "[email-masked]".  But here there is no particular human user -
it's the MR of a car (Mobile Router).

Otherwise, one may do an address plan for all vehicles of one
manufacturer and stamp the IPv6 /64 into one vehicle.  That poses some
questions about revoking addresses after 10year use, or whether they are
Provider-Independent or Provider-Dependent.

> and then use MANET. Seems built to order for MANET, no?

In general yes, it looks much as MANET is well adapted for this
vehicle-to-vehicle communications.

However, there may be some difficulties that could be analyzed (which
MANET protocol? and how does it do address configuration?).

>> Other requirement of using parts of the VIN would be remote
>> software update: extract the field of the VIN which represents
>> Manufacturer ID, make an IPv6 multicast group of it, and send the
>> update accordingly.
>
> For that, I would way prefer using the VIN as part of a DNS name,
> which is then mapped to the IP address of the vehicle. This makes
> the problem more amenable to flexible solutions, like allowing the
> IP address prefix to be changed periodically, or allowing the vehicle
> ID to be associated in any number of ways, other than just a VIN.

I tend to agree.  A solution could be devised where the VIN may be
mapped into a DNS name and make place for more flexible solutions.

There may also be some problems with relying on DNS when the vehicle is
disconnected from the infrastructure.

Or have a DNS server in a vehicle but make sure it's disconnected very
often ('autonomous' mode of operation).  I am not sure how this could be
made to work.

> By the way, this vehicle application of IPv6 is another example that
> makes me kringe about the waste of even IPv6 address space, when we
> continue to discourage the use of longer than 64-bit prefixes.

I agree.  I think address planning should consider avoid potential
waste, and the way in which vehicle industry looks at vehicle lifetime
planning (which is different than the typical computer lifetime planning).

Alex

>> VIN-to-IPv6-InterfaceIdentifier is just one little thing which
>> could or not could not work.
>>
>> Alex
>
>

---

From: SM <[email-masked]>
Date: Tue, 09 Apr 2013 12:56:22 -0700

Hi Michael,

[Note that I have not read draft-imadali-its-vinipv6-viid-00]

>help me?  I already know it is the same car.

This reminded me of the news story at 
http://arstechnica.com/tech-policy/2012/09/your-car-tracked-the-rapid-rise-of-license-plate-readers/ 
The correlation can be between what is going through (a vehicle) and 
who is going through (a person).  I am in two minds about whether 
this stretches privacy or not.

The question to ask is why does one has to know the VIN.

Regards,
-sm

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Apr 2013 09:51:36 +0200

> [Note that I have not read draft-imadali-its-vinipv6-viid-00]

It's ok and thanks for the feedback.

> http://arstechnica.com/tech-policy/2012/09/your-car-tracked-the-rapid-rise-of-license-plate-readers/

Interesting story about privacy and vehicle license plates.

> The correlation can be between what is going through (a vehicle) and who
> is going through (a person).  I am in two minds about whether this
> stretches privacy or not.

Where I live this correlation is common practice at law enforcement - 
speedcams fining at speed limits (radars), 'ticket' fining at forbidden 
parking, etc.  - both take the plate and the driver's face, on a pretty 
wide scale.  Not only cameras fixed on poles along the road but 
increasingly onboard other vehicles (such as openly advertised ecilop 
(police) cars, anonymized police cars and even public transportation 
buses.  To such a point that it's no longer called 'video-surveillance' 
but 'video-protection' (government thinks security as well, not only 
protocol designers).

Other than law enforcement, there is another common practice among the 
IT-minded - 'war driving'.  It's building and maintaining large 
databases of WiFi hotspot areas together with their MAC addresses and 
ESSID.  They assume these are fixed.  This led to many ADSL operators' 
subscribers to freely connect to other house's WiFi if they are provided 
Internet by same ISP.

The databases containing detail kind and position of speedcams, as well 
as the detail of houses' hotspots are public information (provided 
people agree to provide it).  The privacy risks of intelligent 
correlation among them may be considered as important - but maybe only 
_if_ owners agree to let that public.

Similar to that WiFi hotspot situation, one wouldn't be surprised to see 
new Operators of 802.11p networks along the road, and subsequently 
efforts to map these networks into publicly available databases.

> The question to ask is why does one has to know the VIN.

That is a good question, and one may imagine many applications in which 
VIN could be used beyond its simple vehicle identification meaning and 
more related to Internet applications.  Because when deploying services 
on wide scale one needs unique identifiers.

For example, the ESSIDs advertised by a vehicle.  Or other services 
advertised by vehicles: available-for-driving.<VIN>.operator.com (just 
to name one).

Alex

>
> Regards,
> -sm
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
>

---

From: SM <[email-masked]>
Date: Wed, 10 Apr 2013 08:19:14 -0700

Hi Alex,
At 00:51 10-04-2013, Alexandru Petrescu wrote:
>Where I live this correlation is common practice at law enforcement 
>- speedcams fining at speed limits (radars), 'ticket' fining at 
>forbidden parking, etc.  - both take the plate and the driver's 
>face, on a pretty wide scale.  Not only cameras fixed on poles along 
>the road but increasingly onboard other vehicles (such as openly 
>advertised ecilop (police) cars, anonymized police cars and even 
>public transportation buses.  To such a point that it's no longer 
>called 'video-surveillance' but 'video-protection' (government 
>thinks security as well, not only protocol designers).
>
>Other than law enforcement, there is another common practice among 
>the IT-minded - 'war driving'.  It's building and maintaining large 
>databases of WiFi hotspot areas together with their MAC addresses 
>and ESSID.  They assume these are fixed.  This led to many ADSL 
>operators' subscribers to freely connect to other house's WiFi if 
>they are provided Internet by same ISP.
>
>The databases containing detail kind and position of speedcams, as 
>well as the detail of houses' hotspots are public information 
>(provided people agree to provide it).  The privacy risks of 
>intelligent correlation among them may be considered as important - 
>but maybe only _if_ owners agree to let that public.
>
>Similar to that WiFi hotspot situation, one wouldn't be surprised to 
>see new Operators of 802.11p networks along the road, and 
>subsequently efforts to map these networks into publicly available databases.

There was this comment [1] from Ted Lemon:

   "The fact that the VIN is printed on the windshield is not as practical
    a problem as it would be if the VIN could be trivially retrieved
    electronically."

There is the practical problem of capturing information (see above 
for various cases) due to physical constraints.  I could look at the 
Vehicle Identification Number (VIN) by looking at the printout on the 
vehicle.  The (unconfirmed) accuracy of a camera capturing the VIN is 
between 6% up to 82%.  I don't know whether existing cameras actually do that.

>That is a good question, and one may imagine many applications in 
>which VIN could be used beyond its simple vehicle identification 
>meaning and more related to Internet applications.  Because when 
>deploying services on wide scale one needs unique identifiers.
>
>advertised by vehicles: available-for-driving.<VIN>.operator.com 
>(just to name one).

It's difficult to assess the implications of the above. In my 
individual opinion there is a tendency to create identifiers for 
uniqueness.  It's not bad until they get used as part of a 
communication protocol for the Internet instead of within the 
communication.  If I take the Internet applications example (see 
above) I could send that information with the consent of the user 
instead making it an inherent part of the system where it has to be 
sent no matter what.  In the other example I am putting information 
in DNS as a matter of convenience.  In both cases people will reuse 
and misuse the information in ways I did not foresee.

If I have to dumb down the discussion I would say that the technology 
developed within this group is to help stop people from 
speeding.  There is a significant number of people who will hate 
that.  :-)  Seriously, there will be a sense of discomfort as more 
people are aware of the silent listeners [2] [3].

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ipv6/current/msg17552.html
2. http://repository.cmu.edu/cgi/viewcontent.cgi?article=1098&context=jpc
3. http://www.nature.com/srep/2013/130325/srep01376/full/srep01376.html