Subject: [ipwave] Trial involving RIO on OCB for V2V platooning

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 18 Jan 2019 12:15:42 +0100

Trial of a platooning (convoy) use-case for automobiles.

The driver in Lead vehicle follows an arbitrary path that he decides 
randomly.

The person in follower vehicle keeps hands off the wheel.

The cars exchange RTMAPS data on TCP on IPv6 on an OCB link formed 
between the front bumper (of follower) and rear bumper (of lead).  The 
network establishment is with Routing Information Options in Router 
Advertisements, implemented with radvd and odhcp6c on linux. The IPv6 
addressing is mostly link-locals and ULAs.  The latency on OCB is on the 
order of 1.5ms.  Packet dumps were performed.

The cars have cameras, radars and lidars but are not used here (there is 
no 'tracking').

There is no string attaching the cars.

Alex, echoing colleagues work with permission.

https://youtu.be/bW9sEk2rQ1w

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Fri, 18 Jan 2019 14:33:21 +0100

Interesting. Maybe you could consider giving a presentation on this in the
next meeting.

Thanks!

Carlos

On Fri, 18 Jan 2019 at 12:19, Alexandre Petrescu <
[email-masked]> wrote:

> The cars exchange RTMAPS data on TCP on IPv6 on an OCB link formed between
> the front bumper (of follower) and rear bumper (of lead).  The network
> establishment is with Routing Information Options in Router Advertisements,
> implemented with radvd and odhcp6c on linux.  The IPv6 addressing is mostly
> link-locals and ULAs.  The latency on OCB is on the order of 1.5ms.  Packet
> dumps were performed.
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
-- 
Sent from a mobile device, please excuse any brevity or typing errors.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jan 2019 09:37:54 -0500

Very cool. Thanks for sharing.

    > implemented with radvd and odhcp6c on linux. The IPv6 addressing is

So IPv6-Prefix discovery?  Or?  Why is DHCPv6 is required at all?

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 18 Jan 2019 16:14:52 +0100

> So IPv6-Prefix discovery?  Or?  Why is DHCPv6 is required at all?

Thanks for asking.

Each car pre-determined ULA prefixes inside. Their routers exchange 
these prefixes on outdoors OCB interfaces in RIO (Router Informtion 
Option of RA), in a peer-to-peer fashion.

I do not know what you mean by IPV6-Prefix discovery.

For this platooning convoy to work we dont use DHCPv6 because we dont 
know who among cars to establish as "the server".  It's the same problem 
we have when securing this V2V with VPN: we dont know who should be 
_the_ VPN Server even though we know each car should be a VPN Client.

Alex

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jan 2019 15:25:26 -0500

> Each car pre-determined ULA prefixes inside. Their routers exchange these
    > prefixes on outdoors OCB interfaces in RIO (Router Informtion Option of RA),
    > in a peer-to-peer fashion.

So, each car has a ULA prefix....
At the interface between vehicles, you could use straight link-local IPv6
(and ND), and some kind of discovery protocol (mDNS, etc.), but that doesn't
get you routing between the vehicles. Maybe that's a feature.

    > I do not know what you mean by IPV6-Prefix discovery.

Well, you are running odhcp6c, so I wonder why.  One reason would be
do to prefix delegation between vehicles.

    > For this platooning convoy to work we dont use DHCPv6 because we dont know
    > who among cars to establish as "the server".  It's the same problem we have
    > when securing this V2V with VPN: we dont know who should be _the_ VPN Server
    > even though we know each car should be a VPN Client.

You are suffering from IPv4-NAT think, in that there has to be a client and
a server in the "cloud".... IPv6 is just peers, and IPsec doesn't require a
client/server approach at all.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 18 Jan 2019 22:32:51 +0000

We are using DHCPv6 PD in our aeronautical and enterprise mobile device testbeds.
DHCPv6 PD is not only about serving up a Mobile Network Prefix (MNP) to a mobile
device but also for registering the MNP in the routing system. In fact, we also use
DHCPv6 PD even when the mobile device knows its MNP a priori and use the service
simply to inject the MNP into the routing system. We have been using kea for about
3yrs now with  great results.

Thanks - Fred

> -----Original Message-----
> From: its [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: Friday, January 18, 2019 12:25 PM
> To: Alexandre Petrescu <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [ipwave] Trial involving RIO on OCB for V2V platooning
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 19 Jan 2019 12:52:46 +0100

Le 18/01/2019 à 21:25, Michael Richardson a écrit :
> (and ND), and some kind of discovery protocol (mDNS, etc.),

yes and yes.

> but that doesn't
> get you routing between the vehicles. 

yes it does.  I dont know why you think it does not get me routing 
between vehicles?

In each IP-OBU (a router) in the car, just set forwarding flag to 1, and 
insert the prefix from the RIO in the routing table.  This gets routing 
between each PC in one car to each other PC in the other car.  Like in a 
normal Internet.

> Maybe that's a feature.

If there was no routing then it would have been a bug, not a feature. 
We want all PCs in each car in convoy to be able to ping each other PC 
in each other car.

> Well, you are running odhcp6c, so I wonder why.

Sorry, I forgot to clarify: it's called 'odhcp6c' but it also does SLAAC 
in addition to DHCPv6.  We do not use the odhcp6c options that run DHCP, 
but the options that run SLAAC.  'o' in odhcp6c stands for OpenWRT, a 
linux-based OS distribution originally for home routers.

radvd does send RAs, but does not read RAs; the kernel reads RAs but 
does not know to interpret RIOs.  odhcp6c does read and interpret RIO in 
RA, but it needs to first SLAAC a GUA prior to interpreting RIO.  That's 
a bug that comes from specification (the RIO RFC makes RIO to only work 
for Hosts).  In cars, the IP-OBU is a router, not a host.  The IP-OBU 
does not form a GUA on its interface between cars.

So what must be done is: modify the RFC RIO to also work for routers, 
and modify the odhcp6c to interpret RIO even though it does not form a 
GUA with SLAAC.

>  One reason would be

YEs, DHCPv6-PD could be used between cars, but then again who is the 
DHCPv6 Server, and how does it work in a long convoy of more than 10 cars.

> a server in the "cloud"....

Yes, may be.  The thing is that it is not me who is suffering from that, 
but the implementers of VPN software.  The two implementations OpenVPN 
and SoftEther work according to this suffering perspective: when one 
sets it up one must specify a server.

A more 'peer-to-peer' VPN would be something like in the IKE key 
exchange: both parties are equipotential.  But even there, the IKE 
exchange is initiated by one party and the other is listening.

In ND: the advertisement of RAs is performed by each IP-OBU in the car; 
there is no one particular car that advertises, all do.

This characteristic is very important in car networks: they are all the 
same (well, except special cars, of course).

> IPv6 is just peers, and IPsec doesn't require a

That's the protocols, not the implementations.

Do you know a VPN implementation that does not use the word 'server' 
when setting it up?

Alex

---

From: Paul Wouters <[email-masked]>
Date: Sat, 19 Jan 2019 09:54:39 -0500

> On Jan 19, 2019, at 06:52, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> 
> A more 'peer-to-peer' VPN would be something like in the IKE key exchange: both parties are equipotential.  But even there, the IKE exchange is initiated by one party and the other is listening.

> Do you know a VPN implementation that does not use the word 'server' when setting it up?

Freeswan and its successors are careful to avoid server or client terms in configurations and documentation. It even avoids “source” and “destination” because its peer to peer.

Paul

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 19 Jan 2019 16:56:59 +0100

Le 19/01/2019 à 15:54, Paul Wouters a écrit :
>>> IPv6 is just peers, and IPsec doesn't require a client/server
>>> approach at all.
>> 
> Freeswan and its successors are careful to avoid server or client
> terms in configurations and documentation. It even avoids “source”
> and “destination” because its peer to peer.

Thanks for the reply.

Is Freeswan still alive?  I thought it disappeared before 2008.

I would like to learn who are the successors.

Alex

---

From: Paul Wouters <[email-masked]>
Date: Sat, 19 Jan 2019 11:50:13 -0500 (EST)

> I would like to learn who are the successors.

See
http://events17.linuxfoundation.org/sites/events/files/slides/LinuxSecuritySummit-2016-OE-16x9.pdf

History slides start at page 6.

Paul

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 19 Jan 2019 21:31:54 +0100

> History slides start at page 6.

Thank you.

It says 'libreswan' is ongoing.

I hope libreswan supports IPv6, because the examples in the slides are IPv4.

I hope it can be installed on embedded platforms, like a linux openwrt 
kernel 4.

Alex

---

From: Paul Wouters <[email-masked]>
Date: Sat, 19 Jan 2019 16:59:02 -0500 (EST)

> It says 'libreswan' is ongoing.

It is. Libreswan is part of RHEL/CentOS, Fedora, Debian/Ubuntu and
others. We are about to release libreswan 3.28. For the combined commit
statistics of libreswan, see https://nohats.ca/swan.gif

Libreswan is regularly tested and certified for FIPS and Common Criteria.

> I hope libreswan supports IPv6, because the examples in the slides are IPv4.

Yes it supports IPv6. And 6in4 and 4in6.

> I hope it can be installed on embedded platforms, like a linux openwrt kernel 4.

Yes it can. In fact, it runs on the Lantronics Xport pro, which has a
32 bit cpu, 8Mb SDRAM, 16MB flash and no MMU. We have used openwrt for
cross compiles to some architectures, but not all. It works, but the
harder cross-compile is for the NSS crypto library it uses.

https://www.lantronix.com/wp-content/uploads/pdf/XPort-Pro_PB.pdf

Paul

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 21 Jan 2019 14:32:34 +0100

Securing an already working V2V system with libreswan must be easy.

It should be easier to secure things, than attacking them.  Right now it 
is easy to attack on OCB at 5.9GHz.

> https://www.lantronix.com/wp-content/uploads/pdf/XPort-Pro_PB.pdf

Hopefully one day we will reach DNS heights at applications, but we are 
not there yet.

We follow the guidelines in the libreswan readme from github.

The cloning of GPLed source files works fine.

The 'make programs' advances and promisses.

But it fails on something:
from /home/[programmer]/libreswan/programs/pluto/kernel_netlink.c:56:
/usr/include/netinet/in.h:101:5: error: expected identifier before 
numeric constant IPPROTO_HOPOPTS = 0,   /* IPv6 Hop-by-Hop options.  */

Kernel version 4.15, ubuntu 16.

Please make the process of installing easier, because we are not 
security experts, thank you.

Alex

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Jan 2019 08:55:10 -0500 (EST)

On Mon, 21 Jan 2019, Alexandre Petrescu wrote:

[a bit off topic]

> /usr/include/netinet/in.h:101:5: error: expected identifier before numeric 
> constant IPPROTO_HOPOPTS = 0,   /* IPv6 Hop-by-Hop options.  */
>
> Please make the process of installing easier, because we are not security 
> experts, thank you.

It is a problem between kernel and glibc. The workaround is to enable
USE_GLIBC_KERN_FLIP_HEADERS=true in libreswan/mk/config.mk

Paul

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 21 Jan 2019 15:06:19 +0100

> On Mon, 21 Jan 2019, Alexandre Petrescu wrote:

Whether it is off topic is up to someone to make mind.

It is a general requirement: securing things should be easier than 
attacking them.

In vehicular communications security is very important.

Reqs on vehicular communications security seem distinct
than    vehicular communications.

Examples: (1) people secure V2V communications by relying on a 4G link 
even though they know it wont work underground.  Or people develop 
bluetooth car keys which dont work when in an area w/o 4G; so one cant 
open one's car because there's no 4G.  (2) people claim RSUs are secure 
because they are disconnected from the Internet but there are some RSUs 
that dont use any form of VPN, SeND or IPsec security, nor 1609.4 
security.  That makes easy to 'spoof' (pretend to come from legitimate) 
DENM messages which are the warnings of accident - make drivers slow 
down warning about an accident which does not exist is also a situation 
we dont want to be in.

We should avoid these situations.

It can be avoided by giving the communications engineer the security 
tools that are easy to use.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 21 Jan 2019 16:35:26 +0100

I wanted to say publicly that we consider libreswan seriously and will 
look further into it, be it here or elsewhere.

Alex

---

From: Tony Li <[email-masked]>
Date: Mon, 21 Jan 2019 08:29:27 -0800

> Whether it is off topic is up to someone to make mind.

Once again, the current charter of the WG is IPv6 over OCB.  IMHO, unless the security mechanism has some interaction at that layer, the discussion, while valid, probably belongs elsewhere.

Tony

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 21 Jan 2019 23:39:22 +0000

Hi Alex,
 
> linux-based OS distribution originally for home routers.

On our Unmanned Air Systems (UAS) programs, we are doing something similar
using AERO Client/Server (integrated with OpenVPN) and the kea DHCPv6 server
(kea.isc.org/). The AERO code handles both IPv6 ND and DHCPv6 messaging. The
AERO Server passes DHCPv6 messages to and from kea using RFC6221 LDRA so
that kea can run completely unmodified. The use of IPv6ND in conjunction with
DHCPv6 over tunnel virtual links is discussed in 'draft-templin-intarea-6706bis'.

Thanks - Fred

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Tue, 22 Jan 2019 08:27:27 +0100

Hi,

On Mon, Jan 21, 2019 at 5:29 PM Tony Li <[email-masked]> wrote:

> Once again, the current charter of the WG is IPv6 over OCB.  IMHO, unless
> the security mechanism has some interaction at that layer, the discussion,
> while valid, probably belongs elsewhere.
>

Working on security mechanisms is currently out of the scope, but it is not
to document the security issues that IPv6 over OCB involve (the charter
says: " The group will also work on informational document
that describes the problem statement and the associated security and
privacy considerations."). Therefore, those security considerations (for
IPv6 over OCB layer, not any potential security issue) have to be present
in the PS document.

Thanks,

Carlos

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jan 2019 18:42:41 +0200

> Whether it is off topic is up to someone to make mind.

but it may should be not off-topic per any internet-work.

> It is a general requirement: securing things should be easier than

agree

> than    vehicular communications.

Agree. the problem with some IETF WG designs, that they start design
simple but it makes attacks simple also, there were also approach of
separate protocols for security but complicated/more-overhead. However,
design approach is always in IETF related to the WG voice/interest, IMHO,
the power should be with WG, not with ietf managers.

> We should avoid these situations.
yes these situations need to be considered in our drafts.

> tools that are easy to use.

yes we will need internet security tools

AB