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

Dear Jerome, Alex,

Thanks for the clarification.

Given these points, and considering that probably in the future CAM could be transmitted over IPv6, one option would be not to say anything about CAM in the draft. At the moment, I think CAM are only cited when talking about the traffic that cannot be packetized with IPv6. According to your points, it appears that it is not explicitly prohibited to use CAM over IPv6 in the ETSI standards, so this could be more appropriate than the initial text.

Regards,

Jose.

> El 13 feb 2017, a las 10:25, Jérôme Härri <jerome.haerri@eurecom.fr> escribió:
> 
> 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
> 
> 
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its