Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 ETSI CAM and IP

Jérôme Härri <jerome.haerri@eurecom.fr> Mon, 13 February 2017 09:25 UTC

Return-Path: <jerome.haerri@eurecom.fr>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2865129466 for <its@ietfa.amsl.com>; Mon, 13 Feb 2017 01:25:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVmb2aRPD8zS for <its@ietfa.amsl.com>; Mon, 13 Feb 2017 01:25:50 -0800 (PST)
Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 6B05E12944C for <its@ietf.org>; Mon, 13 Feb 2017 01:25:50 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.35,156,1484002800"; d="scan'208";a="5766986"
Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 13 Feb 2017 10:25:49 +0100
Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 7D2BC1116; Mon, 13 Feb 2017 10:25:49 +0100 (CET)
From: Jérôme Härri <jerome.haerri@eurecom.fr>
To: 'Alexandre Petrescu' <alexandre.petrescu@gmail.com>, its@ietf.org
References: <148052970170.9607.12043916621198119260.idtracker@ietfa.amsl.com> <c8c079ab-1417-be34-a2bc-cd2c3b781b85@cea.fr>
In-Reply-To: <c8c079ab-1417-be34-a2bc-cd2c3b781b85@cea.fr>
Date: Mon, 13 Feb 2017 10:25:49 +0100
Organization: EURECOM
Message-ID: <006901d285db$29f4d950$7dde8bf0$@eurecom.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJOjypQjcVLCnmBW2ydKpCtKDvNtwIR6MyyoF3xSAA=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/hH14TBVHw4heg8QM3swJaov5FLM>
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 ETSI CAM and IP
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2017 09:25:53 -0000

Dear Alex, 

I agree with John on the confusing 'MAY NOT', and more generally to the
general confusion in the ETSI about what is allowed or not allowed for what
message...I am OK with suggested change, although in general I think we
could also remove the complete 'non-IP' section..as it does not bring much..

Now, on why/how CAM can be IPv6 compliant, at this state of the standard,
CAM cannot be transmitted on IPv6 (maybe in the future...). There is indeed
no strong 'restriction' (and I think that was the objective of the ETSI to
leave the door open), but one have to read more than these two standard to
see that it is not possible at this stage (I know, ETSI is cumbersome...). 

Here are the justifications of my statements:

Indeed:
* ETSI CAM standard ETSI EN 302 637-2 in section " 5.3.4.2 Interface to the
IPv6 stack and the combined IPv6/GeoNetworking stack " leaves the door open
for CAM being transmitted on IPv6 (and I insist here on IPv6, not v4)

BUT:
* in ETSI EN 302 571, in section "6.1.3 CAM generation frequency" it
mentions a require DCC interface in its triggering conditions. 
* In ETSI EN 302 637-2, the priority level is indicated in "6.2.3 General
priority constraints"  to be according to the ETSI EN 302 636-4-1
(Geonetworking media-independent). 
* The EN 302 637-2 in its section "6.2.2 Security constraints" binds the
transmission of CAMs to certificate that are currently only specified for
the ETSI ITS stack. 
But most critical:
* In ETSI EN 302 571 mentions that accessing CCH requires a DCC
implementation, which CAM over pure IPv6 does not do so far....
* if you send CAM without GeoNET, you create a major security breach, as
there are no 'standard' mentioning how certificate/authentication is
performed, considering OCB does not do any. 

So, it is a quite strict restriction at this stage of the standard that CAM
MUST be sent (so far) only using GeoNet and not IPv6 (and even stricter not
IPv4).  I like to keep an open mind, as I also believe that CAM could also
be allowed to be transmitted in different technologies (LTE-V2X) or stack
(IPv6), but in EU at this state of the standard, CAM must be transmitted on
geonet and not IPv6. 

To change this, we would need at least four key aspects:
1) have a DCC for IPv6 access on ITS-G5 spectrum
2) specify what T_cam_gen_dcc would mean in this case
3) propose a change to the ETSI EN 302 637-2 to allow a CAM traffic class
not bound to GeoNet 
4) specify how security mechanisms would be integrated into the CAM
headers/trailers and transmitted over IPv6.

I think this could be a direction this group could go, but a lot of work is
on the table....

BR,

Jérôme

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Sunday 12 February 2017 19:50
To: its@ietf.org
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 ETSI CAM and IP

draft-ietf-ipwave-ipv6-over-80211ocb-00
ETSI CAM and IP

It has been commented, that to the best of one's reading, the ETSI ITS
documents do not specify what is the protocol that should be used to
encapsulate CAMs.  This leads to wonder whether or not IP can be used to
transport CAMs, and, if not - why not?

The ETSI documents having been reviewed are the following:
ETSI TS 102 637-2
ETSI EN 302 665

In this draft, the old text is the following:
> D.2. Non IP Communications
>
> In IEEE 1609 and ETSI ITS, safety-related communications CANNOT be 
> used with IP datagrams. For example, Basic Safety Message (BSM, an 
> IEEE 1609 datagram) and Cooperative Awareness Message (CAM, an ETSI
> ITS-G5 datagram), are each transmitted as a payload that is preceded 
> by link-layer headers, without an IP header.

I propose the following new text:
> D.2. Non IP Communications
>
> In IEEE 1609 and ETSI ITS, safety-related communications MAY NOT be 
> used with IP datagrams. For example, Basic Safety Message (BSM, an 
> IEEE 1609 datagram), are each transmitted as a payload that is 
> preceded by link-layer headers, without an IP header.

(remark "MAY NOT" instead of CANNOT, and CAM absence).

Alex