Subject: Centrally assigned "ULAs" for automotives and other, environments

From: Ray Hunter <[email-masked]>
Date: Tue, 27 Sep 2011 17:23:53 +0200

Who are we trying to kid about there being no need for a connection to 
the Internet?

FYI A consortium in the Netherlands have just announced a scheme that is 
planning to link in-car navigation systems with traffic control and 
information systems, and also public transport systems, so that if 
there's a traffic jam and it is going to be faster to take the train 
than drive, the car driver will be redirected to the nearest train 
station. The system should even being able to reserve a car parking spot 
on the fly in advance. They expect a prototype in October. The idea 
being that coordinated transport reduces the need for infrastructure 
spending. And I know of at least one group who have been experimenting 
with car-car and car-infra communication.

regards,
RayH

> Message: 3
> Date: Tue, 27 Sep 2011 15:36:31 +0200
> From: Roland Bless<[email-masked]>
> To: 6man<[email-masked]>
> Subject: Centrally assigned "ULAs" for automotives and other
> 	environments
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-15
>
> Hi,
>
> it seems that there is currently not much interest in ULA-Cs (centrally
> assigned ULAs). I came across several use cases, where manufacturers
> (e.g, those of cars, airplanes, or smart metering environments)
> would need internal/closed IPv6-based networks (maybe only for internal
> control and management), that have no connection to the Internet.
>
>   Roland
>

---

From: "Rob V" <[email-masked]>
Date: Tue, 27 Sep 2011 11:36:01 -0400

That doesn't mean all the systems within the car need to speak to the
outside world.  The engine thermometer doesn't care about traffic or the
location of the nearest train station.  It just needs to tell the dashboard
its current read-out.  I presume those are the kinds of systems the OP was
referring to.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray
Hunter
Sent: September-27-11 11:24 AM
To: Roland Bless
Cc: 6man
Subject: Centrally assigned "ULAs" for automotives and other, environments

regards,
RayH

> control and management), that have no connection to the Internet.

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Sep 2011 11:54:11 -0400

On Sep 27, 2011, at 11:36 AM, Rob V wrote:

> location of the nearest train station.

True, but increasingly automotive telematics are being used / folk want to be able to allow your vehicle to poke the dealership and report that something is wrong / marginal, and then parameters can be adjusted on the fly[0].
Wouldn't it be cool[1] if the thermometer could report to the nearest dealership that the engine is overheating and the dealership could use this information when you come in to diagnose the issue (or, more likely, invalidate your warrantee :-0))

>  It just needs to tell the dashboard

Yes, and I think that many of the responses come from folk who have seen the same thing claimed about all sorts of things -- and then very soon after that seen those same thing connected to the 'net. For example, my home thermostat and garage door opener both speak IP. When I initial installed them I never figured I'd want them accessible from anywhere other than locally... but it turns out that I do...

W

[0]: Now, whether this is a *good* idea is completely orthogonal...
[1]: IMO, no, but... see: "Comprehensive Experimental Analyses of Automotive Attack Surfaces", S.Checkoway [link: www.autosec.org/pubs/cars-usenixsec2011.pdf ]

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 27 Sep 2011 17:55:58 +0200

> its current read-out.  I presume those are the kinds of systems the OP was

And thus those systems likely will communicate inside a closed network
only and will not ever have to talk to another such system

As such, what is simply wrong with hardcoding a single ULA /48 prefix in
all those systems?

The moment that something is going to talk to them, there will be a
interface/system/proxy involved which will sit on both networks anyway.

Unless the mechanic at the garage can figure out which prefix is being
used inside the car and has a system that can set up proper routing in
and out of that block. Or the other way that his host is going to get an
interface connected to that network and takes an address out of that prefix.

I guess as we are all guessing here what the system is, the better
question is: where is the proposed design of how this system is going to
look like and what it's requirements truly are.

Saying "I need ULA" is coming up with a solution without looking at the
actual problem at hand.

That said though, every single case of ULA-C will end up the same as the
address space that RIRs are already distributing: globally unique.
Thus from that perspective there is already perfect ULA-C.

Greets,
 Jeroen

---

From: Roland Bless <[email-masked]>
Date: Tue, 27 Sep 2011 18:45:25 +0200

Hi Ray,

> with car-car and car-infra communication.

All fine and sure, there will be and there are already many applications
inside the car that communicate to or via the Internet. However,
my scenario is that the internal onboard network is not directly
communicating with the Internet. Those dedicated applications
and devices that need to communicate to the outside world may
use a special security gateway. Except the latter, no device
will be directly exposed to the Internet.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Tue, 27 Sep 2011 18:45:53 +0200

Hi,

> its current read-out.  I presume those are the kinds of systems the OP was

Exactly.

 Roland

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 27 Sep 2011 14:15:52 -0500

I also second that motion.

We, I, need something in IPv6 that can perform the same function as RFC 1918. Allow me to configure the internal network of each platform (of a given model, let's say) the same way exactly. Preferably without having to request anything from any registry.  And let me decide what parameters have to be assembled and perhaps transmitted globally, by a separate function, through an appropriate gateway/firewall, to the Internet (or to the telephone network).

Doesn't seem logical to conclude that a NAT would be involved in any of this. But even if it is, what's wrong with a "basic NAT," i.e. one that provides a simple one to one mapping for a subset of the internal addresses?

The truth is, IP is used ubiquitously now, in situations where once upon a time people used either small scale serial networks, like RS-485, or other type of industrial control bus, or even non-networked digital interface like MIL-STD-1397. Now IP is taking over those roles too. So we need a straightforward way to doing this, with minimal administrative overhead.

Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roland Bless
Sent: Tuesday, September 27, 2011 12:46 PM
To: Rob V
Cc: 'Ray Hunter'; '6man'
Subject: Re: Centrally assigned "ULAs" for automotives and other, environments

Hi,

Exactly.

 Roland

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Sep 2011 16:22:47 -0400

On Sep 27, 2011, at 3:15 PM, Manfredi, Albert E wrote:

> We, I, need something in IPv6 that can perform the same function as RFC 1918.

My earlier comments may have been unclear -- i second (third) the above, but still believe it is foolish / naive to think, when building or deploying a network / system that it will never need to talk to the Internet and that its addresses will never leak.

> Allow me to configure the internal network of each platform (of a given model, let's say) the same way exactly. Preferably without having to request anything from any registry.  And let me decide what parameters have to be assembled and perhaps transmitted globally, by a separate function, through an appropriate gateway/firewall, to the Internet (or to the telephone network).

Sure.

> Doesn't seem logical to conclude that a NAT would be involved in any of this. But even if it is, what's wrong with a "basic NAT," i.e. one that provides a simple one to one mapping for a subset of…

IMO, nothing.

> The truth is, IP is used ubiquitously now, in situations where once upon a time people used either small scale serial networks, like RS-485, or other type of industrial control bus, or even non-net…

Yes. But if folk claim that X network will never leak onto the 'net because no-one will ever connect it I'm going to go off again on one of my fun little rants...

W

---

From: Roland Bless <[email-masked]>
Date: Tue, 27 Sep 2011 22:32:32 +0200

Hi,

On 27.09.2011 17:54, Warren Kumari wrote:
>> That doesn't mean all the systems within the car need to speak to
>> the outside world.  The engine thermometer doesn't care about
>> traffic or the location of the nearest train station.
> 
> True, but increasingly automotive telematics are being used / folk
> want to be able to allow your vehicle to poke the dealership and
> report that something is wrong / marginal, and then parameters can be
> adjusted on the fly[0]. Wouldn't it be cool[1] if the thermometer
> could report to the nearest dealership that the engine is overheating
> and the dealership could use this information when you come in to
> diagnose the issue (or, more likely, invalidate your warrantee :-0))

Remote diagnosis is only one potential application, but
you have to distinguish between the internal network and
external communications. Remote diagnosis is usually only
allowed by certain authenticated and authorized trustworthy
parties, e.g., the manufacturer. As already pointed out,
we will get a lot of services that depend on the Internet.
However, these should not endanger the safety of the car.

>> It just needs to tell the dashboard its current read-out.  I
>> presume those are the kinds of systems the OP was referring to.
> 
> Yes, and I think that many of the responses come from folk who have
> seen the same thing claimed about all sorts of things -- and then
> very soon after that seen those same thing connected to the 'net. For
> example, my home thermostat and garage door opener both speak IP.
> When I initial installed them I never figured I'd want them
> accessible from anywhere other than locally... but it turns out that
> I do...

IMHO unexpected connectivity of internal devices with the Internet
is a safety and security nightmare. You definitely don't want that.
However, some manufacturers already consider open programming platforms
and an app-based model for some parts of the car, e.g., installing
additional apps on the head unit. Even if they have only restricted
access and are treated as untrusted, I think that it will not take long
until we will see the first exploits on such a platform...

Regards,
 Roland

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 27 Sep 2011 15:50:12 -0400

> Doesn't seem logical to conclude that a NAT would be involved in any of this. But even if it is, what's wrong with a "basic NAT," i.e. one that provides a simple one to one mapping for a subset of…

If you do need to do address translation for this purpose, I'd suggest using NPTv6 (described in RFC 6296).  It provides a one-to-one, algorithmic, checksum neutral mapping which avoids some problems caused by NATs.

Margaret

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Sep 2011 17:25:43 -0400

> until we will see the first exploits on such a platform...

Did you follow the link in my earlier email[0]? : Comprehensive Experimental Analyses of Automotive Attack Surfaces   -- http://www.autosec.org/pubs/cars-usenixsec2011.pdf
And a vide of same (well worth watching) from USENIX Security: http://www.youtube.com/watch?v=bHfOziIwXic

It's already happened...

W

[0]: Snarky tone not intended...

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 28 Sep 2011 11:05:57 +0200

I'm following this thread with interest.

Car will have multiple prefixes, for different usages. The car makers 
will probably allocate them an ULA (no decision made on this) for 
diagnostic purposes and remote software updates. In addition, another 
prefix will be alocated to the vehicle for a number of comfort/mobility 
services and traffic efficiency applications requiring Internet access, 
and that, following what is current written in ITS (Intelligent 
Transport Systems) standards for the vehicles (private automobiles but 
also trucks, buses, etc) would be handled by a permanent and global IPv6 
prefix (allocated by car makers themselves, but more likely third 
parties) and mobility support standards (NEMO [RFC3963], MCoA [RFC5648]: 
see e.g. ISO TC204. At this stage, this is not yet widely supported by 
the automobile industry, though, also the Car-to-Car Communication 
Consortium and the Wave architecture do have IPv6 building blocks (not 
completely defined). At the time being, the automobile industry is more 
concerned about vehicle-vehicle (V2V) and vehicle-roadside (V2R) 
communications for time-critical road safety applications based on 
802.11p and not using IP. But other stakeholders like road operators and 
road authorities concerned with traffic efficiency and non time-critical 
information for road safety have IPv6 in their roadmap. In addition, 
there is the second current which is in-vehicle telematics using 
cellular networks and LTE in particular, but these are not the same 
people within the automobile industry. Once they will all have to 
converge, and this convergence is initiated through the Cooperative ITS 
set of standards defined currently at ISO (TC204), CEN (TC278), ETSI (TC 
ITS). So, IPV6 is in a number of Cooperative ITS standards (see 
Cooperative ITS and more importantly the CALM standards ISO 21217 and 
ISO 21210 which defines the communication architecture and how IPv6 
would fit in for Cooperative ITS). If you are up to buy IISO 21210, I 
would advice you to wait for a couple of months as a new version is 
going to be published (ISO standards are not for free). You may want to 
check:
- these slides: 
https://www-roc.inria.fr/imara/dw/_media/ipv6-its/20101109-cvis-ipv6-m5-itst.pdf
- or this paper: 
https://www-roc.inria.fr/imara/dw/_media/ipv6-its/20101109-cvis-ipv6-m5-itst-paper.pdf

So, the "next edition of the car" is on track. Any recommandation from 
the IETF would be welcome but should be based on the grounds of the ITS 
needs, scenarios, and their standards.

In addition, let me point out about aeronautics for which there exist 
IPv6 addressing scheme (the SANDRA project has delivered such a scheme 
but I don't know if it is public (yet or ever going to).

Regards,
Thierry.

On 27/09/11 17:23, Ray Hunter wrote:
> FYI A consortium in the Netherlands have just announced a scheme that 
> is planning to link in-car navigation systems with traffic control and 
> station. The system should even being able to reserve a car parking 
> spot on the fly in advance. They expect a prototype in October. The 
> idea being that coordinated transport reduces the need for 
> infrastructure spending. And I know of at least one group who have 
> been experimenting with car-car and car-infra communication.
>
> regards,
> RayH
>
>> Message: 3

---

From: Roland Bless <[email-masked]>
Date: Wed, 28 Sep 2011 11:41:07 +0200

Hi Jeroen,

> only and will not ever have to talk to another such system

Yes, at least not with the internal addresses.
For other scenarios than car onboard networks, different
networks may be visible at the same time in the future, e.g.,
formerly independent sensor networks get used together in
a bigger scenario.

> As such, what is simply wrong with hardcoding a single ULA /48 prefix in

Maybe this works in a car scenario, but addresses may leak or formerly
isolated and independent networks get coupled in other scenarios and
then it's good to have unique address prefixes.

> interface/system/proxy involved which will sit on both networks anyway.

In this particular scenario, yes.

> interface connected to that network and takes an address out of that prefix.

Yep.

> look like and what it's requirements truly are.

I have to check with the consortium first, whether I can provide more
details on this.

> Saying "I need ULA" is coming up with a solution without looking at the

I'm not saying that ULAs are the only solution, but ULAs seemed to be
be a good fit for the problem. If global addresses can be easily used
unconnected, one may use these, see below.

> Thus from that perspective there is already perfect ULA-C.

I wasn't sure that the RIR policies allow that use.
Aside from the well-known prefix of ULAs, the difference isn't that large.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Wed, 28 Sep 2011 11:48:28 +0200

Hi,

> [0]: Snarky tone not intended... 

Thanks, but I was well aware of these results already, but it's a
different setting and technology. I'm talking about an IP-based on-board
network and also an App model running on the head unit. This technology
isn't deployed out there yet AFAIK. This will broaden the attack surface
a lot...

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Wed, 28 Sep 2011 14:18:51 +0200

Hi Thierry,

> Car will have multiple prefixes, for different usages. The car makers

Our scenario is roughly like this:
- the car has an IP-based on board network between its
  ECUs for internal control. This directly impacts the safety of
  the car in many cases. It's operation should be completely independent
  of any outside connectivity and addressing schemes.
- outside connectivity to the Internet may be provided by several
  ways (built-in GSM/UMTS/LTE interfaces, smartphone thethering,
  WLAN hotspots etc.). The car will probably use changing addresses,
  may be multi-homed and may have intermittent connectivity.
  It may be connected to other cars, the Internet or other entities.
  All these external connections should be terminated at a security
  gateway for security reasons.

> diagnostic purposes and remote software updates. In addition, another

Since ULAs are disconnected, we intend to use a tunnel for remote
diagnostic access to ECUs.

> see e.g. ISO TC204. At this stage, this is not yet widely supported by

Permanent addresses may be problematic with respect to privacy issues.
Is there a need that connections are initiated from the outside to the
car? Maybe it's better to let the car initiate connections. MobileIP
may be of use for providing seamless connectivity while the car is
changing network access points.

> 802.11p and not using IP. But other stakeholders like road operators and

Yep. Thanks for the pointer to the slides.

> needs, scenarios, and their standards.

Our particular focus in the SEIS project is to securely
replace the existing network heterogeneity in the on-board network
(CAN, MOST, Flexray, etc.) by using IP as common base. It's clear that
the car will be connected to the outside in various ways, using a
variety of different services.

Regards,
 Roland