Re: Centrally assigned "ULAs" for automotives and other environments

Roland Bless <roland.bless@kit.edu> Tue, 27 September 2011 21:15 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0109521F8FB7 for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2011 14:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.113
X-Spam-Level:
X-Spam-Status: No, score=-6.113 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dFpuItnEPxJ for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2011 14:15:54 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0870221F8F60 for <ipv6@ietf.org>; Tue, 27 Sep 2011 14:15:53 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1R8f2s-0005lf-0P; Tue, 27 Sep 2011 23:18:38 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 961DAA809F9; Tue, 27 Sep 2011 23:18:29 +0200 (CEST)
Message-ID: <4E823DA5.3050202@kit.edu>
Date: Tue, 27 Sep 2011 23:18:29 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: "George, Wes" <wesley.george@twcable.com>
Subject: Re: Centrally assigned "ULAs" for automotives and other environments
References: <4E81D15F.6090906@kit.edu> <CAL9jLaZLznsQo5doEa0upgwMQ06FqPLmYizGfb4i8ck7gu2QAw@mail.gmail.com> <4E81DB65.6010503@kit.edu> <34E4F50CAFA10349A41E0756550084FB0FA69D42@PRVPEXVS04.corp.twcable.com> <4E81F4FC.8000104@kit.edu> <34E4F50CAFA10349A41E0756550084FB0FC21052@PRVPEXVS04.corp.twcable.com>
In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0FC21052@PRVPEXVS04.corp.twcable.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1317158318.798685000
Cc: 6man <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2011 21:15:55 -0000

Hi Wes,

see inline.

On 27.09.2011 19:43, George, Wes wrote:
> From: Roland Bless [mailto:roland.bless@kit.edu]
> 
> all that I'm proposing is to use a stable internal addressing for the
> onboard network (no matter how the car is currently connected to the
> Internet) and to use a security gateway/proxy when communication to
> the Internet is somehow required.
> 
> WEG] ok this is a good bit clearer, apologies for not picking up more
> specifics of the application the first time. However, I think that
> this basically ends up being two separate networks, independent of
> any address separation that may be implemented. If anything on the
> local network needs to talk to the outside world, even for peer to
> peer (vehicle to vehicle) interactions, it talks to the
> Bluetooth/cellular/wifi/RFC6214 compliant module, which has both
> internal and external interfaces. Rather than forward the traffic
> directly, it then proxies the request out to the outside world as
> necessary. Even if you use that module as a security device instead

Yep, exactly.

> of a proxy, where the end nodes can communicate through it to get
> outside, you could use the fact that IPv6 supports multiple IP
> addresses per interface to (temporarily?) add an address for only
> those modules expected to talk to the outside world out of whatever
> external GUA prefix is delegated to the comms module, and the rest
> keep only the ULA to talk on the car network.

This is a potential model, but probably at a higher security risk.

> What's unclear to me is why the in-car networks can't use the exact
> same prefix for every single copy of the network, regardless of
> manufacturer, model, etc? If there's an external mediation device to

Sure, you can, but uniqueness makes things easier in some cases.
Maybe not in the car scenario so much, but in others.

> handle occasional external network communication, and the rest of the
> network is expected to be closed (save maybe access from the Ethernet
> port that replaces the OBD-II port used by the technician to talk to
> the computer), why are we worried about conflicting addresses between
> manufacturers, etc? Are you also looking to derive some information

That's correct. Usually, there is no need to ever connect the devices of
those two isolated car networks. Only if they access the same L2
medium without any further demultiplexing possibility there may be
conflicts. One potential scenario could be wireless access via a single
WLAN to several cars simultaneously in a garage for diagnostic purposes.
For wired scenarios you may use the VLAN or switch port for selecting
the right network etc.
But there may be other application scenarios (not cars)
where formerly independent networks may get used together after
some kind of merger. Maybe I can provide a more elaborated example
later.

> about manufacturer, serial number, etc from the address and don't
> have enough bits to represent it uniquely? Couldn't that be solved
> independently of the address?

Yep, could be.

> Alternatively, there is nothing stopping you from writing a BCP or
> informational draft that identifies a recommended ULA numbering
> hierarchy for $industry (like for example the auto industry) to use
> in numbering in-vehicle private networks such that the appropriate
> information is maintained and there is reasonable assurance of
> uniqueness by dint of mutual adherence to the standard - all of them
> start with FC00:: but what you do with the rest of that /7 is mainly
> up to the implementer, and only locally significant. Rather than a
> registry, simply define a way to determine reasonable uniqueness
> algorithmically so that newcomers can derive their address. You can

Yes, all fine we already came up with such a scheme. While
you can ensure a conflict free mapping within a single manufacturer,
you can't ensure it across manufacturers.
However, some manufacturers still feel uncomfortable with the risk
of getting conflicts (however, the implementation should deal with
that case...).

> even use parts of the address to identify major and minor categories,
> sensors, actuators, etc. Maybe it's something as simple as
> numerically representing the ascii value of the brand name. And this
> is likely a value that would never need to change for the life of the
> car, regardless of what happens to the entity that originally
> produced it.
> 
> Hope that my comments are helpful...

Yes. Thanks, they basically confirm our thoughts so far...
 Roland