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

From: Scott Brim <[email-masked]>
Date: Mon, 1 Apr 2013 09:23:09 -0400

The scope of the draft was more or less restricted to in-vehicle
communications because of the privacy concerns ("The focus of this work
is to enable in-vehicle networks to exchange packets with VIN-based IPv6
addresses." -- although inter-vehicle communications is still a big deal
under use cases), so I don't think use of DNS, etc., apply.  If the
draft isn't really restricted to in-vehicle communications I have a
number of architectural arguments about why it's a bad idea.  VINs are
neither topological locators nor IP endpoint identifiers, and trying to
map them onto either causes confusion.  They're fine as higher layer tokens.

Scott

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 1 Apr 2013 19:35:37 +0000

Scott,

If the only goal is in-vehicle, then clearly ULAs are the answer, and there's nothing more to be discussed. And for that matter, RFC 1918 addresses and IPv4 would be more than adequate. Limiting comms to in-vehicle does not require any global uniqueness of addresses.

I think the model to follow here is more like E.164 uniform resource identifiers (ENUM, RFC 3761). In enum, the telephone numbers are not hard-coded in the IP address. Rather, they become a DNS entry. Seems to me that any plan on using the uniqueness of the VIN number for cars should follow this same approach.

Not saying that this DNS approach would answer all vehicle comms issues to be resolved, though. For example, for self-driving vehicles, there would be a need for more real-time (perhaps at layer 2) comms between adjacent cars and between cars and the roadway. E.g. some way of a car with an impending problem to be shuttled off to the emergency lanes, to get out of the way of the moving traffic.

Bert

> -----Original Message-----
> From: Scott Brim [mailto:[email-masked]]
> Sent: Monday, April 01, 2013 9:23 AM
> To: Manfredi, Albert E
> Cc: Alexandru Petrescu; [email-masked]; 6man
> Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 01 Apr 2013 17:11:13 -0300

On 03/31/2013 07:39 PM, Manfredi, Albert E wrote:

> Alexandru Petrescu wrote:
> 
>> I meant to say that this VIN mapping to an IPv6 address may be
>> useful not only to newly manufactured vehicles, but also to old
>> vehicles.
[....]
> 
> A VIN is a fine unique identifier to use in the DNS, though. And
> potentially other similar unique identifiers for different components
> of each car. E.g., the DNS could have vitalreadings.<vin#>.car
> entries, or electicalsystem.<vin#>.car, or
> enginediagnostics.<vin#>.car, or numerous entries to identify an ever
> growing number interfaces that a car should be expected to sprout, in
> the coming decades.
> 
> How you find the moving car from the DNS entry would be same as for
> any other mobile client. Using the same set of solutions.

This is my view as well.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Apr 2013 17:55:38 +0200

Le 31/03/2013 07:25, Fernando Gont a écrit :
> On 03/30/2013 03:49 PM, Alexandru Petrescu wrote:
>>
>>> That said, IPv6 addresses identify network attachment points. If
>>>  you need semantics other than that ("e.g., distinguish between
>>> past, current, and future vehicles"). my take is that you're
>>> looking at the wrong place, possibly at the expense of nodes that
>>> do the right thing.
>>
>> I did't mean to say do distinguish between old and new vehicles by
>>  using an IPv6 address.
>>
> Why should a VIN map to an IPv6 address in the first place?
>
> 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.

But this VIN topic is also about how to generate an ULA prefix when no
EUI-64 is available. (if ULAs are good to be used in a vehicle).

> as long as you don't expect others to use the same semantics as
> yourself (or as long as you can gracefully handle the case in which
> others do not employ the same semantics as you).

Ok.

>> Third-party vehicle equipment manufacturers (not those who
>> manufacture the vehicle itself) may manufacture and sell a Router
>> to be deployed in the vehicle, to connect the vehicle to the
>> Internet.  This Router would be put in new vehicles but also in old
>> ones. (just like one may add e.g. rearview camera to a vehicle
>> which didnt have one at manufacture time).
>>
>> This Router sold by the third-party needs to know what IPv6
>> addresses are or should there be in the vehicle.
>
> Isn't this a case of network mobility?

YEs it is.  Network mobility has a means to dynamically acquire a prefix
for the moving network, from the HA.  But it doesnt say whether that
prefix could be used for direct vehicle-to-vehicle communications, or
shouldnt.

>> _If_ ULA space may be used then one wonders how to generate one
>> ULA prefix for one vehicle.  The RFC ULA does suggest an example
>> algorithm, but it says other algorithms may be possible.
>
> The idea is that the prefix is randomized, as to reduce colisions,
> IIRC.

Yes, and it suggests an algorithm for doing so.  That algorithm uses
EUI-64.  Some MRs may have several such, or none.  What to use in these
case?

>> Also, the example given has some uncertainties (whose interface
>> EUI-64 should be chosen?).
>
> Not sure what you mean....
>
>
>
>> This is one reason we came to generating IPv6 prefixes, and
>> Interface IDs, out of VIN.
>>
>> (it's maybe only me who sends too many emails on this topic, but it
>> is not only me and my co-authors of the mentioned drafts, but there
>> are other people at IETF worked on this VIN-IPv6 topic, presented
>> to f2f IETF meetings, and there exist some IPR activity in that
>> space as well).
>
> I'm not arguing that you're the only guy working on this, nor that
> this VIN->IPv6 mapping might be useful to those working on VIN-IPv6
> topic -- I'm rather arguing that IPv6 address should be... IPv6
> addresses

Yes.  Precisely as IPv6 addresses are IPv6 addresses and sometimes
contain EUI-64 identifiers in clear.

> (assuming you want IPv6 address to have any other semantics than
> "point of attachment").
>
>
> If your point is "We are not intending to introduce any additional
> semantics to the IPv6 addresses/IIDs, but rather are not sure how we
> should implement RFC XXXX in our specific case", please do let me
> know, and I'll look further into this.

Provided that the use of ULA  in a vehicle is acceptable, one would try
to find out how to generate a ULA prefix in a vehicle, and maybe on a
Mobile Router which has several EUI-64, or none.

Alex

> Thanks,

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Apr 2013 18:01:40 +0200

Le 01/04/2013 00:39, Manfredi, Albert E a écrit :
> Honestly, I've never much liked any scheme that attempts to hardcode
> anything about the interface into an IP address that way. And the
> more I think about it, the less sense it makes to use such a scheme
> especially in a car. Where you really can't have one interface
> address for the car anyway. I'm much more inclined to wonder why a
> car should be any different from, say, your set of laptop PCs,
> tablets, and smartphones.

In some sense it's the same - it's also a group of computers with
distinct IP stacks on them.  In other sense it's different - in a car
there's often one 'representative' of these computers whereas a
conference room of laptops has no particular representative.

> potentially other similar unique identifiers for different
> components of each car. E.g., the DNS could have
> vitalreadings.<vin#>.car entries, or electicalsystem.<vin#>.car, or
> enginediagnostics.<vin#>.car, or numerous entries to identify an
> ever growing number interfaces that a car should be expected to
> sprout, in the coming decades.
>

Right.  There would be a need for dynamic DNS updates for this to work.
  This would work when little IP mobility is involved.  It would be fine
to consider vehicles constantly connected with eg LTE, and have the
services formed by DNS names, and maybe from VINs.

>> With IPv4 it was all simple: just use always the same NAT space
>> 192.168.0.0.  Example deployments are from a number of vehicles.
>
> Granted, with the IPv4 address space, anything inside the car would
> be assigned a RFC 1918 address, and would have to go through a NAT.
> And then for global connectivity, systems inside the car would be
> required to initiate any session. You can do functionally the same
> thing with IPv6. Use ULAs for anything inside the car, and then use
> RFC 6296 Network Prefix Translation and mobile IP.
>
> Perhaps you have the car acquire a temporary IPv6 address based on
> its location? Each car is assigned a temporary /64 prefix from the
> local wireless ISP? And the DNS dynamically follows the car that
> way?

I wouldnt think this could work - too many DNS updates... precisely as
too many route updates wouldnt work either (I mean in large deployments).

But that's just supposition.  It may be different, I dont know.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Apr 2013 18:04:48 +0200

Le 01/04/2013 15:23, Scott Brim a écrit :
> communications because of the privacy concerns ("The focus of this
> work is to enable in-vehicle networks to exchange packets with
> VIN-based IPv6 addresses." -- although inter-vehicle communications
> is still a big deal under use cases), so I don't think use of DNS,
> etc., apply.  If the draft isn't really restricted to in-vehicle
> communications I have a number of architectural arguments about why
> it's a bad idea.  VINs are neither topological locators nor IP
> endpoint identifiers, and trying to map them onto either causes
> confusion.  They're fine as higher layer tokens.

I tend to agree.

Although I suppose a middle ground could exist where the scope of one
ULA prefix could cover not only one vehicle, but maybe all vehicles able
to hear it, but not the fixed infrastructure.

And yes, VINs are neither topological locators nor IP endppoint
identifiers.  The VINs themselves may exist into their own layer, with
their own message headers, and message passing akin to what SMTP does.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Apr 2013 18:08:31 +0200

Le 01/04/2013 21:35, Manfredi, Albert E a écrit :
> Scott,
>
> If the only goal is in-vehicle, then clearly ULAs are the answer, and
> there's nothing more to be discussed. And for that matter, RFC 1918
> addresses and IPv4 would be more than adequate. Limiting comms to
> in-vehicle does not require any global uniqueness of addresses.

I agree (except the IPv4 part).

> I think the model to follow here is more like E.164 uniform resource
> identifiers (ENUM, RFC 3761). In enum, the telephone numbers are not
> hard-coded in the IP address. Rather, they become a DNS entry. Seems
> to me that any plan on using the uniqueness of the VIN number for
> cars should follow this same approach.
>
> Not saying that this DNS approach would answer all vehicle comms
> issues to be resolved, though. For example, for self-driving
> vehicles, there would be a need for more real-time (perhaps at layer
> 2) comms between adjacent cars and between cars and the roadway. E.g.
> some way of a car with an impending problem to be shuttled off to the
> emergency lanes, to get out of the way of the moving traffic.

Alex

>
> Bert
>
>> -----Original Message----- From: Scott Brim
>> [mailto:[email-masked]] Sent: Monday, April 01, 2013 9:23 AM To:
>> Manfredi, Albert E Cc: Alexandru Petrescu; [email-masked];
>> 6man Subject: Re: I-D Action:
>> draft-imadali-its-vinipv6-viid-00.txt
>>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 03 Apr 2013 02:40:42 -0300

Hi, Alex,

> be considered, balanced by a privacy-to-mobility tradeoff.

Which privacy aspect?

> EUI-64 is available. (if ULAs are good to be used in a vehicle).

The ULA spec relies on that?

Anyway.. the idea is that you randomize the prefix...

> EUI-64.  Some MRs may have several such, or none.  What to use in these

OK. Lt me take a look -- anyway, my rough guess is that you'd be fine by
just randomizing the prefix part. (i.e., the router).

> contain EUI-64 identifiers in clear.

We should eventually move away from that. See
draft-ietf-6man-stable-privacy-addresses.

> Mobile Router which has several EUI-64, or none.

If you expect communication across vehicles, then your upstream router
should be the one generating the prefix. If only in-vehicle
communication is expected, you'd be okay by just randomizing the prefix.
-- But I'll double-check with the UA spec and come back to you -- please
feel free to ping me if I forget.

Cheers,

---

From: Scott Brim <[email-masked]>
Date: Wed, 3 Apr 2013 09:05:30 -0400

>> be considered, balanced by a privacy-to-mobility tradeoff.

Please dig for previous discussion of this draft.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Apr 2013 15:22:07 +0200

Le 03/04/2013 07:40, Fernando Gont a écrit :
>> About this there is a tendency to agreement.  The privacy aspect
>> should be considered, balanced by a privacy-to-mobility tradeoff.
>
> Which privacy aspect?

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

>> But this VIN topic is also about how to generate an ULA prefix
>> when no EUI-64 is available. (if ULAs are good to be used in a
>> vehicle).
>

Yes, the ULA prefix (RFC 4193 section 3.2.2) generates a 48bit prefix
randomly.  That suggested algorithm is seeded by time, EUI-64 into a
key, and then SHA-1.

> Anyway.. the idea is that you randomize the prefix...

Yes.  We may need to say how.

Just saying RNG may not be enough, I dont know.

>> YEs it is.  Network mobility has a means to dynamically acquire a
>> prefix for the moving network, from the HA.  But it doesnt say
>> whether that prefix could be used for direct vehicle-to-vehicle
>> communications, or shouldnt.
>

I mean Network mobility as the RFCs describe them dont say whether the
prefix assigned to a moving network is ULA or GUA, PI or PA.

Also, that Network mobility doesnt prohibit neither suggests that the
prefix of a moving network (MNP: Mobile Network Prefix) be exchanged
between two distinct moving networks such as to establish routes between
them (route exchange).

I am discussing this because you seemed to ask whether this is a case of
Network mobility: yes and no.

>>>> ULA prefix for one vehicle.  The RFC ULA does suggest an
>>>> example algorithm, but it says other algorithms may be
>>>> possible.
>>>
>>> The idea is that the prefix is randomized, as to reduce
>>> colisions, IIRC.
>>
>> Yes, and it suggests an algorithm for doing so.  That algorithm
>> uses EUI-64.  Some MRs may have several such, or none.  What to
>> use in these case?
>
> OK. Lt me take a look -- anyway, my rough guess is that you'd be
> fine by just randomizing the prefix part. (i.e., the router).

Just randomize but how?

Just randomize without saying how may lead to everybody outputting same
number.  One may need to use a detail about generating
uniqueness.  The RFC ULA suggests that detail to be time and EUI-64.

A mobile router in a vehicle may not always have a EUI-64 (yet it has
LTE interface, CAN, USB, etc).  Or it may have several such
EUI-64-interfaces; and a rule may say 'pick any one of the available
EUI-64 on this computer'.

Or it may say to use the EUI-64 of another interface of another computer
in that same vehicle. (there are several distinct such computers, like
the 'TCU', the 'ECU', the OBU, the Switch, the App server, and so on).

Or it may say just use the VIN because that covers the entire vehicle
and whatever computers are inside there's only one VIN.

>>> I'm not arguing that you're the only guy working on this, nor
>>> that this VIN->IPv6 mapping might be useful to those working on
>>> VIN-IPv6 topic -- I'm rather arguing that IPv6 address should
>>> be... IPv6 addresses
>>

Well yes I read it and understand it from a privacy perspective.  It is
very good in that sense because whenever changing the subnet the IID
changes, so attacker can not track the user by its IID.

However, it may be less attractive to a mobility-inclined reader,
because whenever changing the entire address (not only the IID), some of
the ongoing communications may break., I think.

>>> If your point is "We are not intending to introduce any
>>> additional semantics to the IPv6 addresses/IIDs, but rather are
>>> not sure how we should implement RFC XXXX in our specific case",
>>> please do let me know, and I'll look further into this.
>>
>> Provided that the use of ULA  in a vehicle is acceptable, one
>> would try to find out how to generate a ULA prefix in a vehicle,
>> and maybe on a Mobile Router which has several EUI-64, or none.
>
> If you expect communication across vehicles, then your upstream
> router should be the one generating the prefix.

'Upstream router' - the topmost router in the vehicle (there are
several).  Or the first-hop router in the fixed infrastructure?

If the first-hop router in the fixed infrastructure - if it's a cellular
Access Router it may not have EUI-64 either, or have several.

> If only in-vehicle communication is expected, you'd be okay by just
> randomizing the prefix.

Well, I think that for only in-vehicle communication, random ULA may
not be necessary - using the same ULA fd00:1::/64 in every other vehicle
will work.

The random part of the ULA may be needed for inter-vehicle
communications.  I.e. use fd00:fef2:3214::/64 inside one vehicle,
and fd00:fff2:3214::/64 in the other vehicle.  Use no prefix on the
ad-hoc link between the two egress interfaces of the mobile router (use
their link-local addresses there).

If those two prefixes were not random, then collision between prefixes
may occur the moment the routes are exchanged between the vehicles.

> -- But I'll double-check with the UA spec and come back to you --
> please feel free to ping me if I forget.

Ok will do, thanks.

Alex

---

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

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:

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

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: Doug Barton <[email-masked]>
Date: Wed, 03 Apr 2013 12:08:31 -0700

On 04/03/2013 09:00 AM, Michael Richardson wrote:
| 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.

There's orders of magnitude different in having to walk up to the
windshield of every car you're interested in vs. passively sniffing IP
traffic to discover VINs of thousands of cars in a go.

And dare I mention the big brother aspect of setting up roadside
monitors? And what about son-of-google-street-view? The privacy aspects
of being able to reverse-map IP traffic to VINs are staggering.

I remain unconvinced that there should be any special case in the
protocol for this, as I've yet to see an argument as to why ULAs are not
sufficient. I remain violently opposed to any protocol definition that
supports VIN <> IP address mapping.

Doug

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 3 Apr 2013 19:36:10 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu

> Just saying RNG may not be enough, I dont know.

I really don't put much weight on this. It's just one suggestion. I dare say, pick a decent PRNG, pick a seed out of the air, and for all intents and purposes, you have your ULA prefix. After all, this use of ULA is only for in-vehicle comms, and should not transit through any car-Internet router. Randomness is only a safety net, in case a ULA sneaks out of the local router.

I don't think we should tie the VIN or any EUI-64 strictly to this idea of using ULAs.

> between two distinct moving networks such as to establish routes

Well, I have a question about this. I've seen mobility done in a number of ways. Move individual interfaces, using the home agent approach; move entire address blocks, where the routing protocol keeps track of subnet location; or use a link layer that always ties the moving subnet(s) to the same geographic location "back home," making the job easier for the IP layer.

Added to this, for a vehicle scenario, we may (probably will) also need something along the lines of 802.11 ad-hoc networks, for those tactical car-car and car-road comms.

In principle, can't a combination of all of these schemes be used in vehicles? For instance, if your IP service is the type that replaces the OnStar scheme (used by GM in the US), a lot of that information is not overly time constrained. And since OnStar is a 3G system, it "knows" what each client's home network is.

> may occur the moment the routes are exchanged between the vehicles.

No, I would not contaminate the Internet deliberately this way. It seems to me that each car should be assigned a /64 prefix which is globally unique, for this sort of use. Just like every household. I really don't see why this type of inter-car communications should be thought of as any different from home nets. And again, the mobility aspect can be resolved in at least two different ways that I believe to be in common use already.

Bert

---

From: joel jaeggli <[email-masked]>
Date: Wed, 03 Apr 2013 12:49:47 -0700

On 4/3/13 12:08 PM, Doug Barton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
It is relatively costly today to set a distributed monitoring 
infrastructure that tracks the comings and goings of automobiles (and by 
proxy their owners) (think city of london or stockholm) and the use of 
and access to such datasets is generally restricted and subject to 
strong privacy protections). it should not be the case that we trivially 
enable such data-gathering.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
>
> iQEcBAEBCAAGBQJRXH4vAAoJEFzGhvEaGryEkvAIAL72fEzKUqpLEcvdyh177Vla
> dZov3A88iIMJuq6dE4xG7RzMSRG5ueFkelIB07jxo0TyXQmvvliS029RKeWlZed9
> BhIMZwWw2AY2jQVnQTvT9pwZ+8KrY94s4q0YpVzdKsJKKhErvISKnzwn1qCtKFlv
> 7tsfSXcCq7E4WgcuQSxtUIyaTN/Psw27QVTrJ8PJTHlGTIzrkJrRIczjLJy0pHvv
> Ekq9Bi/n/w65CQYn1zNume/goW0eUDk9rVHf/XopD5ugnRHW1gn6fkDxjDKc9Jc9
> I1QU4nHhP82NiRiqS9xzgXUpMjm/+RCSHYPvAKCcTGdACBDtXUhd5QU9w4gJ3YA=
> =EAHc
> -----END PGP SIGNATURE-----
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

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:

    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: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 4 Apr 2013 01:18:52 +0000

> 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: Doug Barton <[email-masked]>
Date: Wed, 03 Apr 2013 18:39:16 -0700

On 04/03/2013 06:13 PM, Michael Richardson wrote:

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

You're extrapolating from a condition that fits your view (tracking 1
vehicle). The point that I and others are making is that being able to
cross-reference VIN and IP address will lead to the ability for
various actors to be able to track massive numbers of vehicles. Some
of those folks will also have access to the VIN database (whether they
are state-sponsored, crackers, or "other") which leads to a whole new
level of privacy violation.

| If I can derive the VIN from the prefix, I agree that it helps
| identify the vehicle, but not really.

So if I know the VIN number of the vehicle I'm interested in, all I
have to do is get on the network and figure out where it's originating
its traffic from, and now I can dramatically narrow down its location,
if not pinpoint it with a high degree of accuracy.

I've run out of adjectives to describe how bad of an idea this is. I
find it hard to believe that you're not seeing the problems here.

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

I have no idea what this is supposed to mean.

Doug

---

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: 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 10:56:04 -0400

>>>>> "Doug" == Doug Barton <[email-masked]> writes:
    Doug> | If I can derive the VIN from the prefix, I agree that it helps
    Doug> | identify the vehicle, but not really.

    Doug> So if I know the VIN number of the vehicle I'm interested in, all I
    Doug> have to do is get on the network and figure out where it's originating
    Doug> its traffic from, and now I can dramatically narrow down its location,
    Doug> if not pinpoint it with a high degree of accuracy.

You just assumed that the VIN-derived prefix traffic is on the
"network", but repeatedly, I say that most of it is inside of the
vehicle.

And I'm saying that knowing the VIN doesn't significantly *help* you
find the vehicle, you can find it *without the VIN*.  

If you are a party that has access to the VIN database, you likely are a
state actor, and you also have access to the VIN to OmniStar mapping and
a court, and you could just serve a warrant on OmniStar or the
manufacturer or whomever you like.

    Doug> I've run out of adjectives to describe how bad of an idea this is. I
    Doug> find it hard to believe that you're not seeing the problems
    Doug> here.

    Doug> | If any of this stuff is going to be useful, there will already be a
    Doug> | collision avoidance protocol that will tell each car (even when
    Doug> | they are parked) where the other vehicles are, so that they can be
    Doug> | avoided.

    Doug> I have no idea what this is supposed to mean.

That's the problem.  You have no idea what I'm talking about, but you
keep repeating the same thing about how you can do all this magic.  I
keep saying, "it's not magic, it's much worse than you are saying, and
we can do all of this without knowing the VIN mapping"

If you want location privacy, you have to avoid disclosing your location
to the Internet.  Thinking that hiding the VIN will give that to you is
just security through obscurity.

---

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: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Apr 2013 17:16:37 +0200

Le 03/04/2013 21:08, Doug Barton a écrit :
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>
> On 04/03/2013 09:00 AM, Michael Richardson wrote: | 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. |
> windshield of every car you're interested in vs. passively sniffing
> IP traffic to discover VINs of thousands of cars in a go.

Automatic shooting (taking picture of) license plate is a common
practice in certain automatic law enforcement, and parking security.

The VIN being smaller than the plate may be just a matter of when higher
sensor resolutions become available.  I would not be surprised to see
automated shooting of VIN in the future for various applications.

The VIN must remain visible.  One of the privacy problems may lie in
that requirement per se.  And, on the contrary, it could also be used to
securely produce a request of an IP service from the vehicle in line of
sight, when infrastructure is not available.

> monitors?

That possibility may already be there.  It may be that 802.11p/DSRC/WAVE
sends periodic beacons unsecured out of the car, which may contain MAC
addresses.  (I just suppose).

> And what about son-of-google-street-view?

I suppose even the father-google-street-view may already have some
privacy concerns.  Although it is obvious that the engineers went to
large efforts to anonymize faces and license plates, its application
still misses some points.  I have seen a easily dateable picture of
StreetView with easily recognizable faces of law enforcement officer
and a person being fined.  And pictures of intimate clothes out in the
air drying, invisible otherwise.  I guess they collect these fun things
somewhere.

> The privacy aspects of being able to reverse-map IP traffic to VINs
> are staggering.
>
> protocol for this, as I've yet to see an argument as to why ULAs are
> not sufficient. I remain violently opposed to any protocol
> definition that supports VIN <> IP address mapping.

Ok.

Alex

>
> Doug
>
> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux)
>
> =EAHc -----END PGP SIGNATURE-----
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Apr 2013 17:20:27 +0200

> level of privacy violation.

Understood here.

Remark, there may still exist possibilities in which mapping VIN-IP 
(direct or indirect, parts of total) may be done in a privacy-conserving 
manner, if that brings some advantage to some application.

> if not pinpoint it with a high degree of accuracy.

Ok, it is easier for one to locate a vehicle in that way.

> find it hard to believe that you're not seeing the problems here.

I think there may be some problems.

Alex

> iQEcBAEBCAAGBQJRXNnEAAoJEFzGhvEaGryEMegH/jc+1R63D3TdhFiCZyzNW9Ei
> uHwv5PGR8BrFKY8698okO24mDPZLTfdIV48XadMi0bJHlLpiYPwAJOyF75SRoyBo
> hPv5+ougB0vwfp+7skJcLsYabnWejILyEDAw3ee3GXDlXJmM786k7/uqSHRh6FP3
> kaBb0IL7Bwkc/kbjlQ+bBQr/KPTyAqzK2LIBiJY3m4loD8W/cQSJLYMd8VesKnBG
> UThrniH70ZPbq1GtSCAuLhufbWzTLbuMwfo9tQBT5vtpP07RCkCimTDcZfrRa6uI
> yEVaeA/XEKeaYLyhZjfWDL71tIEhAUBGOcgv8XQdsWLZfrXVNCi43hhn27R6C6s=
> =mSqQ

---

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: joel jaeggli <[email-masked]>
Date: Thu, 04 Apr 2013 09:01:04 -0700

> practice in certain automatic law enforcement, and parking security.
yes, and as noted by me, that takes kind of a lot of resources to do at 
scale (like central london), and it typically has strong privacy 
protections on the resulting dataset. the second you build a social 
networking app that passively collects locally broadcast unique 
identifiers using mobile phone handsets, well you have a lot of data, 
really useful for all sorts of things.
> automated shooting of VIN in the future for various applications.
sure
> sight, when infrastructure is not available.
vins like fingerprints are not secrets, if you want to use them as an 
authentication tool you need to be mindful of that limitation.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 04 Apr 2013 10:17:25 -0700

for people who are interested, and in the bay area...

On 4/3/13 4:12 PM, Christie Dudley wrote:
> I posted a while back about hacking privacy in the upcoming 
> DSRC/802.11p safety protocol they're talking about possibly mandating 
> for every car. A lot of people expressed interest, but I discouraged 
> people because we were in the old dojo and really cramped for space.
>
> Well, Alison Chaiken with Silicon Valley Automotive Open Source has 
> gone ahead and arranged a talk for next week where there's plenty of 
> space for everyone who's interested in discovering more about this. 
> Admission is free and there's also free food. So come join us.
>
> Tuesday, April 9, 2013
> 7:00 PM
>
> Mentor Graphics Building B
> 46885 Bayside Parkway, Fremont, CA
http://www.meetup.com/Silicon-Valley-Automotive-Open-Source/events/101945752/

On 4/4/13 9:01 AM, joel jaeggli wrote:
> yes, and as noted by me, that takes kind of a lot of resources to do 
> at scale (like central london), and it typically has strong privacy

---

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

---

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

Le 03/04/2013 21:36, Manfredi, Albert E a écrit :
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Alexandru Petrescu
>
>> Yes, the ULA prefix (RFC 4193 section 3.2.2) generates a 48bit
>> prefix randomly.  That suggested algorithm is seeded by time,
>> EUI-64 into a key, and then SHA-1.
>>
> I really don't put much weight on this. It's just one suggestion. I
> dare say, pick a decent PRNG, pick a seed out of the air, and for all
> intents and purposes, you have your ULA prefix.

I agree, this is feasible.

> After all, this use of ULA is only for in-vehicle comms, and should
> not transit through any car-Internet router.

YEs and no.

Within a vehicle, it's not sufficient to just use link-local addresses,
because it is highly likely that at least two different subnets are
present inside (roughly 'safety' and 'entertainment', but just roughly).
  So one needs addresses inside a vehicle with a scope larger than link.
  These may be ULAs, or not  ULAs, yet they must be larger than link scope.

Between vehicles - it may be that one vehicle needs to inform the nearby
vehicle about the prefix(es) it holds inside, and vice-versa.  If these
prefixes are ULA, then this prefix exchange should work.  This direct
vehicle-to-vehicle communication may not need any car-to-Internet
connection - it's a sort of 'peer-to-peer' communication. (WiFi adhoc
mode of egress ifaces, or 802.11p - both may establish connections
between vehicles without using infrastructure).

About the straightedness of connectivity, this V2V acronym is generally
understood by IP people by a number of degrees of variation: there is
(1) direct vehicle-to-vehicle communication without infrastructure
whatsoever, (2) vehicle-to-AP-to-vehicle communication (AP is a fixed
router along the roadside, but disconnected from Internet), (3)
vehicle-to-AP-to-Internet-to-AP-to-vehicle, (4) V-to-HA-to-HA-to-V and
so on (HA is the Home Agent hosted by the vehicle manufacturer, not by
the cellular operator).

> Randomness is only a safety net, in case a ULA sneaks out of the
> local router.

YEs.

> I don't think we should tie the VIN or any EUI-64 strictly to this

I agree as well.  VIN could be used in a Internet setting in a variety
of ways.

>> Also, that Network mobility doesnt prohibit neither suggests that
>> the prefix of a moving network (MNP: Mobile Network Prefix) be
>> exchanged between two distinct moving networks such as to establish
>> routes between them (route exchange).
>
> Well, I have a question about this. I've seen mobility done in a
> number of ways. Move individual interfaces, using the home agent
> approach; move entire address blocks, where the routing protocol
> keeps track of subnet location; or use a link layer that always ties
>  the moving subnet(s) to the same geographic location "back home,"
> making the job easier for the IP layer.
>
> Added to this, for a vehicle scenario, we may (probably will) also
> need something along the lines of 802.11 ad-hoc networks, for those
> tactical car-car and car-road comms.

YEs 802.11 ad-hoc but between the egress interfaces of vehicles, not 
between the inside1 of vehicle1 and inside2 of vehicle2.

With that distinction, it appears to me that IP routing should be 
performed between inside1 and outside of the car.  This is ok, because a 
car Router interface may be Ethernet (ingress) and another may be WiFi 
(egress).

> In principle, can't a combination of all of these schemes be used in
>  vehicles? For instance, if your IP service is the type that replaces
>  the OnStar scheme (used by GM in the US), a lot of that information
>  is not overly time constrained. And since OnStar is a 3G system, it
>  "knows" what each client's home network is.

The OnStar system as I understand it is a good deployment success
showing IP is possible in vehicles at a large scale.  It is mostly the
success of deployment of the cellular network and certain PHY encoding
schemes.  I compare it to eCall in Europe (which is regulated
differently in different countries).

But we look here at a much deeper penetration of IP than just one IP
address per vehicle and a single interface.

It is considered further that several IPv4 and IPv6 addresses _and_
subnets are inter connected inside a vehicle.  Many of the typical
actions (open window) move from pressing an electrical switch to tapping
a circle drawned by PC on LCD screen.  There is not one but several
Ethernet cables inside.  The vehicle has a large number of egress
interfaces to the outside world.  Just like with mobile phones, recent
antenna designs of vehicle are increasingly complex: cellular on
frequencies of different countries, GPS of different continents, WiFi at
various freq ranges, 802.11p and more.

One approach to manage IP mobility of these complex systems is the use
of protocol Mobile IP which has extensions to consider all IP addresses
inside a vehicle to move as a whole.  Conceptually the Mobile IP
approach is a 'tunnelling' approach (there's a tunnel between the MR and
an anchor - the Home Agent), as opposed to route updates as may be seen
with BGP updates.  It is an IP-layer mobility protocol (as opposed to
link-layer mobility used by e.g. cellular systems).  It is a
map-and-encap as opposed to rewrite.  Other protocols which may be used
to do mobility of groups of IP devices may be considered to be LISP and
SHIM6.

Mobile IP has advantages and inconvenients for vehicular communications.

One of the inconvenients is that its perspective is not much that of V2V
communications: can't just consider the other vehicle to be one
vehicle's HA.

On another hand, MIP could very well be used in a V2I setting.

>> and fd00:fff2:3214::/64 in the other vehicle.  Use no prefix on
>> the ad-hoc link between the two egress interfaces of the mobile
>> router (use their link-local addresses there).
>>
>> If those two prefixes were not random, then collision between
>> prefixes may occur the moment the routes are exchanged between the
>>  vehicles.
>
> No, I would not contaminate the Internet deliberately this way. It
> seems to me that each car should be assigned a /64 prefix which is
> globally unique, for this sort of use.

There is need of more than just one /64 in a vehicle, or otherwise DHCP
must be used.  There are several subnets in a vehicle and many devices
are Ethernet-like.  SLAAC can not work with a /65 and Ethernet devices.

> Just like every household.

There is a well sensed tendency to move towards deployment giving more
than one /64 to a household - in France there this OVH and Nerim
operators I believe giving shorter len than /64 to households.

> I really don't see why this type of inter-car communications should
> be thought of as any different from home nets.

For one, homenets don't move or at least not as fast as cars.  A homenet 
may change its attachment every year or so, whereas a car may change it 
every 10 minutes or so.

Depends what kind of inter-car communications.

Direct car-to-car without any assistance may not be a good candidate
for Mobile IP protocol, nor for BGP route updates, nor for link layer
communications.

For Mobile IP perspective: it's hard for a vehcile's MR to consider
every other vehicles' MR to be its HA.  Typically a MR has a single HA.

For BGP updates perspective: this could be discussed and should be
analyzed at length.  BGP is one and then there's OSPF RIP and MANET and
RPL.  Each has peculiarities (e.g. RPL may be designed low power links
whereas V2V would be designed for high power links like .11p).

For each of these one needs to give properconsideration of the IPv6
addressing architecture to be deployed in vehicles, and the subnet
structure.

> And again, the mobility aspect can be resolved in at least two
> different ways that I believe to be in common use already.

Yes, the mobility aspect of vehicles could be resolved in at least two 
different ways: link-layer mobility and route updates.

Link layer mobility works with just one kind of link.  But could be used 
to enhanced the overall mobility support of vehicle.

Route updates: could work for small networks of vehicles, as long as one 
avoids to insert routes in the Internet.

Alex

---

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: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 4 Apr 2013 20:22:43 +0000

> may change its attachment every year or so, whereas a car may change it

Just as a side FYI, my homenet attachment IP changes every time I reboot the ADSL modem. So even this would not matter greatly, *if* the unique ID of a car were a DNS entry, rather than hardcoded in the IP address in any way.

Your point about having multiple IPv6 subnets (prefixes) inside the car is a good one. But it can be solved like it is for home nets, as long as we don't run out of the shortened prefixes we're creating.

Side note:

Seems to me, with new applications like these IoT concepts (which are nothing new, but promise way more addressable hosts than we might have expected in the 1990s when IPv6 was invented), or vehicles, that allowing for something like 112-bit prefixes would be a good thing. You still get 16-bit IIDs, way more than you are likely to need in a single in-car subnet, and you can assign the individual car a 96-bit prefix. Giving each car the possibility of 64K subnets, while wasting far less address space.

I kringe at wanton waste.

Bert

---

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: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Apr 2013 17:55:30 +0200

Le 04/04/2013 22:22, Manfredi, Albert E a écrit :
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]]
>
>> For one, homenets don't move or at least not as fast as cars.  A
>> homenet may change its attachment every year or so, whereas a car
>> may change it every 10 minutes or so.
>
> Just as a side FYI, my homenet attachment IP changes every time I
> reboot the ADSL modem. So even this would not matter greatly, *if*
> the unique ID of a car were a DNS entry, rather than hardcoded in the
> IP address in any way.

When a homenet boots up in may need to use a Network Access Identifier
(NAI) or a MAC address maybe to request the same IP address from the
provider.

With vehicles, this would mean to make the VIN (Vehicle Identification
Number) to be that NAI - a conversion from VIN to NAI like
<VIN>@example.com.

Whereas in a homenet it may be appropriate that a DNS Server be present,
it may be less likely that a DNS Server is present in a vehicle.  I
haven't seen one, but one may put one DNS Server in a vehicle.

Whereas the friendly applications are sensitive to the advice to _not_
hardcode the IP address of the Server, the preliminary yet futuristic
in-vehicle applications often hardcode the IP address of the Server.
And that for a good reason: it may be that the DNS is not reachable.

When migrating the large number of applications in a vehicle from IPv4
to IPv6 one already faces first very simple problems like what addresses
to put there, or is the IPv6 stack available for that small CPU.  The
advice to _always_ use DNS is just an additional requirement on top of
others.

A DNS in a vehicle may also put significant unknowns with respect to the
DNS64 deployed by the cellular operator.

> Your point about having multiple IPv6 subnets (prefixes) inside the
> car is a good one. But it can be solved like it is for home nets, as
>  long as we don't run out of the shortened prefixes we're creating.

I agree.  Some argument says that there may be little if at all risk of
running out of these shortened prefixes.

But other arguments suggest we'd better lengthen the prefix length
instead of shortening it.

> Side note:
>
> Seems to me, with new applications like these IoT concepts (which are
> nothing new, but promise way more addressable hosts than we might
> have expected in the 1990s when IPv6 was invented), or vehicles, that
> allowing for something like 112-bit prefixes would be a good thing.

I think so too.  Prefix of length 112bit could be made to to work with
SLAAC and Ethernet.

2^64 hosts on a single IPv6 subnet will probably never be supported by
any single link layer.

Also, the IoT and its keen M2M concepts often consider that they're very
small and less powerful machines in terms of CPU, yet often with more
than one IP interfaces (i.e. they're dumb Routers).  These devices need
small software implementations of protocol.  Yet for the simplest tasks
- get an IP address, a delegated prefix, a default route - the IPv6
landscape requires such a device to use both ND and DHCP.

This is a disconnect.  The results look strange if looked at from IETF
perspective.  For example, a small 'mobile IPv6 hotspot' deployed on
cellular does some things which IETF documents dont ack.

I wonder whether homenet people consider that the prefix to be delivered
to a homenet could be longer than /64 (i.e. /65 or /66).

> You still get 16-bit IIDs, way more than you are likely to need in a
>  single in-car subnet, and you can assign the individual car a 96-bit
>  prefix. Giving each car the possibility of 64K subnets, while
> wasting far less address space.

Makes sense to me.

> I kringe at wanton waste.

Yes, seems as intentional waste.

Alex

---

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.

---

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 :
>> 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: Alexandru Petrescu <[email-masked]>
Date: Mon, 08 Apr 2013 13:51:56 +0200

Le 05/04/2013 07:41, Roger Jørgensen a écrit :
> <[email-masked]> wrote: <snip>
>
> was on the way of doing what has been done before and considered a
> not so good idea.

Ok.

There are now the Privacy Extensions to SLAAC.  But does that mean that
the non-privacy addresses (i.e. a typical MAC-derived IID) are
forbidden?  I wouldnt think so, no?

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

Ok.  Sounds reasonable.  Especially with IPv4: it's just a number.
Although practice sees the .1 be the default router, or
.254 for that matter, or other extreme of a subnet range.

And, as with IPv4, in IPv6 there exist particular meanings to some
addresses: the prefix fe80, the prefix ff, the ug bits, the fffe inner
16bits of an EUI-64, the anycast Interface ID, to name a few.

Is there a privacy risk of knowing that that src addresses watches the
movie on that particular IPv6 multicast group?

With the VIN-IID proposal (not the VIN-ULA prefix proposal), we dont
quite propose 1:1 mapping, but a selection of VIN fields to map into an
IID.  A full 1:1 mapping VIN-IID is not possible because one is 78bits
the other is 64bits.  (and yes, the proposed mapping may have issues
with a particular privacy risk, and it may help with some applications.)

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

Right.  To avoid the particular privacy risk of reverse mapping IID-VIN,
one may use the output of a hash of the VIN.  That would be ok to
respect privacy, yet it would disallow the applications which may need
this reverse mapping.

Alex

---

From: Scott Brim <[email-masked]>
Date: Mon, 8 Apr 2013 10:54:29 -0400

> respect privacy, yet it would disallow the applications which may need

Nothing should try to go from IP address (topological locator) to any
sort of identifier.  If you need that, use a higher layer protocol.

---

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

Le 08/04/2013 16:54, Scott Brim a écrit :
>> Right.  To avoid the particular privacy risk of reverse mapping
>> IID-VIN, one may use the output of a hash of the VIN.  That would
>> be ok to respect privacy, yet it would disallow the applications
>> which may need this reverse mapping.
>
> Nothing should try to go from IP address (topological locator) to
> any sort of identifier.  If you need that, use a higher layer
> protocol.

Scott - yes, in principle I largely agree.

Except that there may exist some minor exceptions: e.g. the identifier
of a multicast group.

For example: the group of all vehicles of one particular manufacturer.

The group of all vehicles in a particular area.

Maybe this is also about being a higher layer protocol.

Alex