Subject: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs

From: sofiane Imadali <[email-masked]>
Date: Mon, 18 Feb 2013 19:49:15 +0100

Hello 6MAN folks,

I would like to announce, on behalf of the co-authors, the submission
of 2 drafts relating to VIN-based IPv6 addressing.
VIN stands for Vehicle Identification Number, and it is specifically
used in a context of IPv6 vehicular communications. These proposals
aim at providing discussion about a new mapping/conversion method from
VIN to ULA prefixes (guaranteed unique) and Interface Identifiers.

Please find the above mentioned documents at:
1) Vehicle Identification Number-Based IPv6 Interface Identifier
(VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00
2) Vehicle Identification Number-Based Unique Local IPv6 Unicast
Addresses (VULA), at:
http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00

Your comments are welcome,

Cheers,
Sofiane.

---

From: Scott Brim <[email-masked]>
Date: Mon, 18 Feb 2013 15:36:55 -0500

I have the usual concerns about privacy.  I have no problem with someone
knowing the endpoint that is communicating is associated with a vehicle
(or that I, a human, am communicating from a vehicle).  However, if
someone can map easily from an IP address to a VIN (thus knowing the
specific vehicle from which the communication is happening), and I have
no choice but to reveal that information in order to communicate at all,
I am not comfortable.  In general, as an architectural principle, I want
the option to control how much personal information I reveal.  That's
called privacy.

... Scott

On 02/18/13 13:49, sofiane Imadali allegedly wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 18 Feb 2013 22:07:51 +0100

> the option to control how much personal information I reveal.  That's

Actual the problem is much simpler, it's not that easy to get the
unique ID of a vehicle today, however with the proposed solution it
become extremely easy.
Sort of the same idea that caused IPv6 to create all IPs based on the
mac address... we know how that ended, we created the privacy option.

Do we want todo it all over again?

-- 

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

---

From: Scott Brim <[email-masked]>
Date: Mon, 18 Feb 2013 16:16:06 -0500

> Do we want todo it all over again?

... and that argument isn't really over.  And the legalities have not
been tested yet, particularly in Europe.  I'm not comfortable.

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 19 Feb 2013 00:06:36 +0100

I also think a VIN-based IPv6 addressing is a bad idea.

People involved in ITS (Intelligent Transportation System) in other SDOs 
(ISO, ETSI, CEN) are using pseudonyms at L2 (see the SeVeCom project, or 
the PRESERVE project) and NEMO at L3 (see GeoNet, CVIS and the ITSSv6 
projects) so that location privacy is maintained when the vehicle is moving.

Regards,
Thierry Ernst.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 18 Feb 2013 23:13:55 -0800

> unique ID of a vehicle today, however with the proposed solution it
In my experience the VIN is readily visible on most stationary vehicles 
(by virtue of  of of the locations being behind the windshield). using 
it as a host address certainly implies that it's being broadcast more 
widely.

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 19 Feb 2013 18:46:25 +1100

>Do we want todo it all over again?

=> Someone, somewhere (perhaps the IAB) needs to write an architectural
document to tell various industries to _stop_ doing that.
The IID is a set of bits that have no meaning, please stop trying to
create it in an industry/link layer technology-specific manner. It does do
anything and it's meaningless. If you want the correspondent to know that
you're a car with a particular VIN then put that in your application!

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Feb 2013 15:17:34 +0100

Le 19/02/2013 08:46, Hesham Soliman a écrit :
>>> I have the usual concerns about privacy.  I have no problem with
>>> someone knowing the endpoint that is communicating is associated
>>> with a vehicle (or that I, a human, am communicating from a
>>> vehicle).  However, if someone can map easily from an IP address
>>> to a VIN (thus knowing the specific vehicle from which the
>>> communication is happening), and I have no choice but to reveal
>>> that information in order to communicate at all, I am not
>>> comfortable.  In general, as an architectural principle, I want
>>> the option to control how much personal information I reveal.
>>> That's called privacy.
>>
>> unique ID of a vehicle today, however with the proposed solution
>> it become extremely easy. Sort of the same idea that caused IPv6 to
>> create all IPs based on the mac address... we know how that ended,
>> we created the privacy option.
>>
> => Someone, somewhere (perhaps the IAB) needs to write an
> architectural document to tell various industries to _stop_ doing
> that. The IID is a set of bits that have no meaning, please stop
> trying to create it in an industry/link layer technology-specific
> manner. It does do anything and it's meaningless.

I think you're too strong with statements.  Many IPv-over-foo documents
exist and they do just that - create IID in a industry-specific manner.

> If you want the correspondent to know that you're a car with a
> particular VIN then put that in your application!

That is a good point - if one wants a Server to determine that some
end-node is actually a vehicle (with details about vehicle type -
electrical) then better use a UDP payload, not necessarily an IP address
for it.

But I think you make an assumption which may be true or false.  It is
not necessarily true that we do that only for the application.

The need comes from further, and it may look simpler: we need to form
IPv6 addresses within a vehicle.

There are a number of solutions to realize it, but each has its
advantages and inconvenients.  Forming it from VIN has some advantages.

We can discuss this.

Alex

>
> Hesham
>
>
>>
>>
>> --
>>
>> Roger Jorgensen           | ROJO9-RIPE [email-masked]          |
>> - IPv6 is The Key! http://www.jorgensen.no   | [email-masked]
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Feb 2013 15:23:09 +0100

Le 18/02/2013 22:07, Roger Jørgensen a écrit :
> become extremely easy. Sort of the same idea that caused IPv6 to

Well I agree with you in a sense.  Connecting a vehicle to the Internet
in that way makes it easier than before to find its VIN.

However, may I add that the VIN of a vehicle is very easy to get.  It is
displayed under the shield and by legislation it must be visible, for
cases like e.g. recover at accident scenes.  Despite its little font,
it's as visible as the license plate (I can send a photo if you wish, or
you could check a car's windshield bordering the frame).  Nobody 
complains about the visibility of the license plate.

> Do we want todo it all over again?

No.

Privacy is a strong concern and we should take it into account, yes.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Feb 2013 15:31:52 +0100

Le 18/02/2013 22:07, Roger Jørgensen a écrit :
>> vehicle).  However, if someone can map easily from an IP address to
>> a VIN (thus knowing the specific vehicle from which the
>> comfortable.  In general, as an architectural principle, I want the
>> option to control how much personal information I reveal.  That's
>> called privacy.

Scott,

I agree privacy is important.

An alternative method from R. Bless proposes to use a SHA output in the
prefix field of an address.  This has an advantage with respect to
privacy - it's hardly feasible to reversely derive the VIN of the
vehicle from the IPv6 address, slide 6 of
http://www.lara.prd.fr/_media/ipv6-its/2012-03-26-seis-kit-ietf83-its.pdf

That method alone has certain advantages, but also drawbacks.

If we consider the problem to be as simple as "how to form IPv6
addresses in a vehicle?" then one realizes that just forming a ULA
prefix for _within_ the vehicle may not be enough.  Communication
outside the vehicle (e.g. between two vehicles) may involve links which
may not be just plain Ethernet, and hence impossible to just use RFC2464
LL addresses on the outside of the vehicle.

In some cases it _is_ possible to get along with just LL/Ethernet
addresses between vehicles, but if/when
geonetworking/other-vehicular-link-layers are used, then that may not be
enough.

All in all, depending on the problem, the VIN-based addresses may be
necessary, provided that privacy concerns are addressed.

Alex

> create all IPs based on the mac address... we know how that ended, we
> created the privacy option.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Feb 2013 15:36:38 +0100

Le 19/02/2013 00:06, Thierry Ernst a écrit :
> People involved in ITS (Intelligent Transportation System) in other
> SDOs (ISO, ETSI, CEN) are using pseudonyms at L2 (see the SeVeCom
> project, or the PRESERVE project) and NEMO at L3 (see GeoNet, CVIS
> and the ITSSv6 projects) so that location privacy is maintained when
> the vehicle is moving.

It's good location privacy is maintained, with these techniques.

The other privacy aspect mentioned seems to relate to protecting an
individual from attacker reversely deriving his/her VIN from the IP address.

One doesn't want a java-hacked Facebook in the Internet to allow all my
friends know my request came from a vehicle of type Fiat (I pretend
Ferrari :-)

I agree to the privacy concerns.

Alex

> Regards, Thierry Ernst.
>>> I would like to announce, on behalf of the co-authors, the
>>> submission of 2 drafts relating to VIN-based IPv6 addressing. VIN
>>> stands for Vehicle Identification Number, and it is specifically
>>> used in a context of IPv6 vehicular communications. These
>>> proposals aim at providing discussion about a new
>>> mapping/conversion method from VIN to ULA prefixes (guaranteed
>>> unique) and Interface Identifiers.
>>>
>>> Please find the above mentioned documents at: 1) Vehicle
>>> Identification Number-Based IPv6 Interface Identifier (VIID), at:
>>> http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00 2)
>>> Vehicle Identification Number-Based Unique Local IPv6 Unicast
>>> Addresses (VULA), at:
>>> Cheers, Sofiane.

---

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

> complains about the visibility of the license plate.

How someone might walk along the street and see a VIN has nothing to do
with Internet privacy.  If this mapping mechanism is adopted, one MUST
reveal the specific vehicle communicating in order to communicate at
all.  That is not "taking privacy into account".  Most people have no
idea what can be derived from correlated data.

---

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

> I agree to the privacy concerns.

Great.  Thanks.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 19 Feb 2013 07:37:47 -0800

> geonetworking/other-vehicular-link-layers are used, then that may not be
I'm pretty sure one of my cars has an IMEI, a bluetooth mac address and 
one on the wifi.

I would imagine that link layer technology would drive what sort of L2 
identifer is used for a given technology e.g. wifi bluetooth

      802.15.4 and so on. and that if that's a mac address it's
      available for use as an upper layer identifier in a fashion we
      understand.

> necessary, provided that privacy concerns are addressed.
A vin uniquely identifies a vehicle not a link layer interface. If you 
application requires that (toll transponder does that effectively) then 
need to expose that in some way to the application. address selection or 
mac addresses for that matter is far too weak a mechanism to serve as an 
identity token.

---

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

Le 19/02/2013 15:49, Scott Brim a écrit :
>> Well I agree with you in a sense.  Connecting a vehicle to the
>> Internet in that way makes it easier than before to find its VIN.
>>
>> However, may I add that the VIN of a vehicle is very easy to get.
>> It is displayed under the shield and by legislation it must be
>> visible, for cases like e.g. recover at accident scenes.  Despite
>> its little font, it's as visible as the license plate (I can send a
>> photo if you wish, or you could check a car's windshield bordering
>> the frame).  Nobody complains about the visibility of the license
>> plate.
>
> How someone might walk along the street and see a VIN has nothing to
>  do with Internet privacy.  If this mapping mechanism is adopted, one
>  MUST reveal the specific vehicle communicating in order to
> communicate at all.  That is not "taking privacy into account".

The picture is finer.  It may be that the address formed from VIN is
actually an ULA, which reaches some Servers in a domain, but not the
Internet at large. (maybe reach another vehicle in the same highway).

It may also be that the protocol Mobile IP/NEMO is used, or not.  When
it is used, it may be that the tunnel between MR and HA is protected by
ESP, hence the address inside the tunnel (the ULA derived from VIN) is
not visible.

The HA - Home Agent - in the infrastructure is controlled by the same
entity who gave birth to that vehicle, so it may rightfully need to know
its identity. (garage recall a vehicle because of particular fault).

> Most people have no idea what can be derived from correlated data.

Yes, I am part of that most people.  I have no idea and I am personally
afraid of what may be correlated about what I send on Internet.

Any method of predictive mapping should take care of privacy.

Alex

---

From: Warren Kumari <[email-masked]>
Date: Tue, 19 Feb 2013 15:14:35 -0500

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

Actually, I suspect that if the "OEM-specific-256bit Key" gets exposed then determining the VIN will be fairly trivial -- I guess the answer is simply "well, don't leak the key then"?

It is unclear to me who exactly generates the address -- if the manufacturer calculates it before it leaves the factory then this isn't as likely as if the vehicle does (because it would then need the key somewhere)…

W

--
It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 20 Feb 2013 11:01:06 +1100

>exist and they do just that - create IID in a industry-specific manner.

=> My opinion covers those cases too. It's a broken concept. I think an
RNG is find as a generic method. We don't need to do some magic to create
an IID for each case.

>IPv6 addresses within a vehicle.

=> Use an RNG to create the 64 bits then run DAD, it's pretty straight
forward.

Hesham

---

From: Roland Bless <[email-masked]>
Date: Wed, 20 Feb 2013 10:56:43 +0100

Hi Alex,

> prefix for _within_ the vehicle may not be enough.  Communication

This is sufficient for the onboard communication network, which was
the problem we addressed. ULAs are a good match, since these addresses
should not leak.

> LL addresses on the outside of the vehicle.

Our model was to have a security gateway for external connectivity
and we assume that we may have various different access technologies
such as LTE, WLAN, Bluetooth, and so on, i.e., multi-homing and
changing addresses.

I don't see any requirement to use algorithmically
defined VIN-based addresses _between_ two vehicles:
usually cars don't know which other cars are currently around them
and especially they cannot know their VINs a priori.
So usually you would need some kind of discovery protocol using
well-known group addresses in order to figure out the unicast IPv6
addresses.

> necessary, provided that privacy concerns are addressed.

I don't see the need yet if external communication is concerned.

Regards,
 Roland

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Feb 2013 20:09:48 +0900

> the problem we addressed. ULAs are a good match, since these addresses

and rfc1918 should not leak

randy

---

From: Roland Bless <[email-masked]>
Date: Wed, 20 Feb 2013 12:37:16 +0100

Hi Randy,

> and rfc1918 should not leak

Yes, I know in practice they do leak, that's why I wrote "should".
My statement was a little bit imprecise - I apologize.
No leakage wasn't actually my point rather than internal use only.
So no matter which kind of addresses you employ for "internal
use" only, they may accidentally leak due to misconfiguration,
failures etc. The advantage of ULAs is though: if they leak, they
are still unique with a high probability, hopefully causing less
harm than rfc1918 addresses.

Regards,
 Roland

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Feb 2013 20:40:44 +0900

> Yes, I know in practice they do leak, that's why I wrote "should".  My
> statement was a little bit imprecise - I apologize.  No leakage wasn't
> actually my point rather than internal use only.  So no matter which
> kind of addresses you employ for "internal use" only, they may
> accidentally leak due to misconfiguration, failures etc. The advantage
> of ULAs is though: if they leak, they are still unique with a high
> probability, hopefully causing less harm than rfc1918 addresses.

for more assurance of such wonderful properties, and no probabilities,
you may want to check out ipv6 global address space

randy

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 20 Feb 2013 13:49:38 +0100

Hi Randy,

> you may want to check out ipv6 global address space

Agreed, this is probably even a better choice, however,
some manufacturers do not want to pay for non-routable
IPv6 global address space and depending on the number
of manufactured automotives, they need a larger prefix.

Regards,
 Roland

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Feb 2013 21:51:44 +0900

>> for more assurance of such wonderful properties, and no
>> probabilities, you may want to check out ipv6 global address space

ahh.  so this is really just another end-run around the registry
system.  instead, fix the registries.

randy

---

From: Warren Kumari <[email-masked]>
Date: Wed, 20 Feb 2013 08:57:47 -0500

> of manufactured automotives, they need a larger prefix.

What?! A large manufacturer, selling enough vehciles that they exhaust a large prefix *doesn't want to pay*? 

I'm shocked… shocked I tell you…

W

--
"Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life." -- Terry Pratchett

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 20 Feb 2013 20:09:18 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randy Bush

[ULAs]

> system.  instead, fix the registries.

Of course, but what's wrong with that? I too would be in favor of using ULAs for this in-vehicle purpose.

Bert

---

From: Randy Bush <[email-masked]>
Date: Thu, 21 Feb 2013 06:20:34 +0900

> I too would be in favor of using ULAs for this in-vehicle purpose.

it would be very appropriate, as in vehicles, there is always a
probability of collision.

randy