From nobody Mon Jun 1 03:45:05 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842E91AC3E9 for ; Mon, 1 Jun 2015 03:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 Sx12s_gjFRYN for ; Mon, 1 Jun 2015 03:45:02 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0194C1AC3E7 for ; Mon, 1 Jun 2015 03:45:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t51Aik8V018705; Mon, 1 Jun 2015 12:44:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5037220777F; Mon, 1 Jun 2015 12:47:09 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3EE0C207719; Mon, 1 Jun 2015 12:47:09 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.182]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t51AigRs031301; Mon, 1 Jun 2015 12:44:46 +0200 Message-ID: <556C379A.40405@gmail.com> Date: Mon, 01 Jun 2015 12:44:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: William Whyte , Jong-Hyouk Lee References: <554B534C.4030008@gmail.com> <2AE9D409-2CC8-4ABB-90C4-92D6D2BDCF6A@gmail.com> <5566DE61.7040907@gmail.com> <4941dbc0340c3da6765df68a4b0df698@mail.gmail.com> In-Reply-To: <4941dbc0340c3da6765df68a4b0df698@mail.gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Hosnieh Rafiee , its@ietf.org Subject: Re: [geonet/its] Standards about PKI models for vehicular networks X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 10:45:04 -0000 Thanks for the pointer, it seems very relevant to me, I went through it. Hosnieh - is this reference ok for what you're looking for? We may meet in Prague as bar bof. Alex Le 28/05/2015 13:47, William Whyte a écrit : > I'm editor of IEEE 1609.2, which specifies some security mechanisms for > use in V2X and which will be used in the US. > > Note that there's no particular "PKI model for vehicular networks", at > least not in the US. In the US there are ITS applications which have > security requirements and those requirements are in general met by > application-specific mechanisms, as in the case of V2V safety or tolling, > or by security mechanisms that work over IPv6 such as TLS or IPSec. In the > US we've done a lot of work on making the system somewhat > privacy-preserving, even against insider attacks at the CA, while at the > same time allowing revocation; there's a description of those mechanisms > in William Whyte, André Weimerskirch, Virendra Kumar, and Thorsten Hehn, > “A Security Credential Management System for V2V Communications”, 2013 > IEEE Vehicular Networking Conference (VNC 2013), December 16-18, 2013, > Boston, USA, which you can get a copy of at > http://www.cvt-project.ir/Admin/Files/eventAttachments/A%20Security%20Cree > ntial%20Management%20System%20for%20V2V%20Communications%20-%20VNC%20Confe > rence%202013_514.pdf. Those mechanisms are being incorporated in the > current working draft of 1609.2, not yet complete. > > The US approach doesn't have multi-hop at the network level, and there are > no security mechanisms below Layer 7 other than IPSec. We've been > considering link-layer encryption for single-hop services but are waiting > for 802 to come up with a fast-setup encryption mechanism. > > I may be in Prague and would be happy to discuss in person. > > Cheers, > > William > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Thursday, May 28, 2015 5:23 AM > To: Jong-Hyouk Lee > Cc: its@ietf.org > Subject: Re: [geonet/its] Standards about PKI models for vehicular > networks > > As for ETSI ITS there is this document publicly available which > describes architecture and includes PKI (although not a "PKI model"). > > ETSI TS 102 940 V1.1.1 (2012-06) > "ITS communications security architecture and > security management" > > Recent ETSI ITS security discussions talk about certificate formats and > how to sign messages. > > ETSI organizes a Security workshop on June 24 and 25 on "Security > Assurance in ITS" thematic stream: > http://www.etsi.org/news-events/events/870-security-week > > Alex > > > Le 28/05/2015 10:45, Jong-Hyouk Lee a écrit : >> I am not sure other standard models, but ETSI ITS security groups >> published related documents and the European CAR 2 CAR Communication >> Consortium (C2C-CC) also had internal documents. As I am no longer >> active in them, I do not know the latest status. >> >> Cheers. -- Jong-Hyouk Lee, living somewhere between /dev/null and >> /dev/random Protocol Engineering Lab., Sangmyung University >> >> #email: jonghyouk@gmail.com #webpage: >> https://sites.google.com/site/hurryon >> >>> On May 7, 2015, at 8:58 PM, Alexandru Petrescu >>> wrote: >>> >>> Hi, >>> >>> What are the standards that treat of PKI models in the particular >>> case of vehicular networks? >>> >>> Alex >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Mon Jun 1 04:25:45 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C511A00F0 for ; Mon, 1 Jun 2015 04:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XuBWrzI1_MgF for ; Mon, 1 Jun 2015 04:25:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5991A00DB for ; Mon, 1 Jun 2015 04:25:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWU35607; Mon, 01 Jun 2015 11:25:39 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Mon, 1 Jun 2015 12:25:38 +0100 From: Hosnieh Rafiee To: Alexandru Petrescu , William Whyte , Jong-Hyouk Lee Thread-Topic: [geonet/its] Standards about PKI models for vehicular networks Thread-Index: AQHQiL0bUsRmbWgWJUKh37PqfT/FK52XnuXbgAAKPsA= Date: Mon, 1 Jun 2015 11:25:37 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A70154C67F@lhreml504-mbs> References: <554B534C.4030008@gmail.com> <2AE9D409-2CC8-4ABB-90C4-92D6D2BDCF6A@gmail.com> <5566DE61.7040907@gmail.com> <4941dbc0340c3da6765df68a4b0df698@mail.gmail.com> <556C379A.40405@gmail.com> In-Reply-To: <556C379A.40405@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.118] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "its@ietf.org" Subject: Re: [geonet/its] Standards about PKI models for vehicular networks X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 11:25:44 -0000 SGkgQWxleCwNCg0KWWVzIHRoYW5rcyBmb3IgdGhlIGluZm9ybWF0aW9uLiBUaGF0IGlzIHN1ZmZp Y2llbnQuDQoNClRoYW5rcyBhIGxvdA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IEFsZXhhbmRydSBQZXRyZXNjdSBbbWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFp bC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAwMSwgMjAxNSAxMjo0NSBQTQ0KPiBUbzogV2ls bGlhbSBXaHl0ZTsgSm9uZy1IeW91ayBMZWUNCj4gQ2M6IGl0c0BpZXRmLm9yZzsgSG9zbmllaCBS YWZpZWUNCj4gU3ViamVjdDogUmU6IFtnZW9uZXQvaXRzXSBTdGFuZGFyZHMgYWJvdXQgUEtJIG1v ZGVscyBmb3IgdmVoaWN1bGFyDQo+IG5ldHdvcmtzDQo+IA0KPiBUaGFua3MgZm9yIHRoZSBwb2lu dGVyLCBpdCBzZWVtcyB2ZXJ5IHJlbGV2YW50IHRvIG1lLCBJIHdlbnQgdGhyb3VnaA0KPiBpdC4N Cj4gDQo+IEhvc25pZWggLSBpcyB0aGlzIHJlZmVyZW5jZSBvayBmb3Igd2hhdCB5b3UncmUgbG9v a2luZyBmb3I/DQo+IA0KPiBXZSBtYXkgbWVldCBpbiBQcmFndWUgYXMgYmFyIGJvZi4NCj4gDQo+ IEFsZXgNCj4gDQo+IA0KPiBMZSAyOC8wNS8yMDE1IDEzOjQ3LCBXaWxsaWFtIFdoeXRlIGEgw6lj cml0IDoNCj4gPiBJJ20gZWRpdG9yIG9mIElFRUUgMTYwOS4yLCB3aGljaCBzcGVjaWZpZXMgc29t ZSBzZWN1cml0eSBtZWNoYW5pc21zDQo+ID4gZm9yIHVzZSBpbiBWMlggYW5kIHdoaWNoIHdpbGwg YmUgdXNlZCBpbiB0aGUgVVMuDQo+ID4NCj4gPiBOb3RlIHRoYXQgdGhlcmUncyBubyBwYXJ0aWN1 bGFyICJQS0kgbW9kZWwgZm9yIHZlaGljdWxhciBuZXR3b3JrcyIsDQo+IGF0DQo+ID4gbGVhc3Qg bm90IGluIHRoZSBVUy4gSW4gdGhlIFVTIHRoZXJlIGFyZSBJVFMgYXBwbGljYXRpb25zIHdoaWNo IGhhdmUNCj4gPiBzZWN1cml0eSByZXF1aXJlbWVudHMgYW5kIHRob3NlIHJlcXVpcmVtZW50cyBh cmUgaW4gZ2VuZXJhbCBtZXQgYnkNCj4gPiBhcHBsaWNhdGlvbi1zcGVjaWZpYyBtZWNoYW5pc21z LCBhcyBpbiB0aGUgY2FzZSBvZiBWMlYgc2FmZXR5IG9yDQo+ID4gdG9sbGluZywgb3IgYnkgc2Vj dXJpdHkgbWVjaGFuaXNtcyB0aGF0IHdvcmsgb3ZlciBJUHY2IHN1Y2ggYXMgVExTIG9yDQo+ID4g SVBTZWMuIEluIHRoZSBVUyB3ZSd2ZSBkb25lIGEgbG90IG9mIHdvcmsgb24gbWFraW5nIHRoZSBz eXN0ZW0NCj4gPiBzb21ld2hhdCBwcml2YWN5LXByZXNlcnZpbmcsIGV2ZW4gYWdhaW5zdCBpbnNp ZGVyIGF0dGFja3MgYXQgdGhlIENBLA0KPiA+IHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUgYWxsb3dp bmcgcmV2b2NhdGlvbjsgdGhlcmUncyBhIGRlc2NyaXB0aW9uIG9mDQo+ID4gdGhvc2UgbWVjaGFu aXNtcyBpbiBXaWxsaWFtIFdoeXRlLCBBbmRyw6kgV2VpbWVyc2tpcmNoLCBWaXJlbmRyYQ0KPiBL dW1hciwNCj4gPiBhbmQgVGhvcnN0ZW4gSGVobiwg4oCcQSBTZWN1cml0eSBDcmVkZW50aWFsIE1h bmFnZW1lbnQgU3lzdGVtIGZvciBWMlYNCj4gPiBDb21tdW5pY2F0aW9uc+KAnSwgMjAxMyBJRUVF IFZlaGljdWxhciBOZXR3b3JraW5nIENvbmZlcmVuY2UgKFZOQw0KPiAyMDEzKSwNCj4gPiBEZWNl bWJlciAxNi0xOCwgMjAxMywgQm9zdG9uLCBVU0EsIHdoaWNoIHlvdSBjYW4gZ2V0IGEgY29weSBv ZiBhdA0KPiA+IGh0dHA6Ly93d3cuY3Z0LQ0KPiBwcm9qZWN0LmlyL0FkbWluL0ZpbGVzL2V2ZW50 QXR0YWNobWVudHMvQSUyMFNlY3VyaXR5JTIwDQo+ID4gQ3JlZQ0KPiA+IG50aWFsJTIwTWFuYWdl bWVudCUyMFN5c3RlbSUyMGZvciUyMFYyViUyMENvbW11bmljYXRpb25zJTIwLQ0KPiAlMjBWTkMl MjBDDQo+ID4gb25mZSByZW5jZSUyMDIwMTNfNTE0LnBkZi4gVGhvc2UgbWVjaGFuaXNtcyBhcmUg YmVpbmcgaW5jb3Jwb3JhdGVkIGluDQo+ID4gdGhlIGN1cnJlbnQgd29ya2luZyBkcmFmdCBvZiAx NjA5LjIsIG5vdCB5ZXQgY29tcGxldGUuDQo+ID4NCj4gPiBUaGUgVVMgYXBwcm9hY2ggZG9lc24n dCBoYXZlIG11bHRpLWhvcCBhdCB0aGUgbmV0d29yayBsZXZlbCwgYW5kDQo+IHRoZXJlDQo+ID4g YXJlIG5vIHNlY3VyaXR5IG1lY2hhbmlzbXMgYmVsb3cgTGF5ZXIgNyBvdGhlciB0aGFuIElQU2Vj LiBXZSd2ZSBiZWVuDQo+ID4gY29uc2lkZXJpbmcgbGluay1sYXllciBlbmNyeXB0aW9uIGZvciBz aW5nbGUtaG9wIHNlcnZpY2VzIGJ1dCBhcmUNCj4gPiB3YWl0aW5nIGZvciA4MDIgdG8gY29tZSB1 cCB3aXRoIGEgZmFzdC1zZXR1cCBlbmNyeXB0aW9uIG1lY2hhbmlzbS4NCj4gPg0KPiA+IEkgbWF5 IGJlIGluIFByYWd1ZSBhbmQgd291bGQgYmUgaGFwcHkgdG8gZGlzY3VzcyBpbiBwZXJzb24uDQo+ ID4NCj4gPiBDaGVlcnMsDQo+ID4NCj4gPiBXaWxsaWFtDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGl0cyBbbWFpbHRvOml0cy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQWxleGFuZHJ1DQo+ID4gUGV0cmVzY3UNCj4gPiBTZW50OiBUaHVyc2Rh eSwgTWF5IDI4LCAyMDE1IDU6MjMgQU0NCj4gPiBUbzogSm9uZy1IeW91ayBMZWUNCj4gPiBDYzog aXRzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtnZW9uZXQvaXRzXSBTdGFuZGFyZHMgYWJv dXQgUEtJIG1vZGVscyBmb3IgdmVoaWN1bGFyDQo+ID4gbmV0d29ya3MNCj4gPg0KPiA+IEFzIGZv ciBFVFNJIElUUyB0aGVyZSBpcyB0aGlzIGRvY3VtZW50IHB1YmxpY2x5IGF2YWlsYWJsZSB3aGlj aA0KPiA+IGRlc2NyaWJlcyBhcmNoaXRlY3R1cmUgYW5kIGluY2x1ZGVzIFBLSSAoYWx0aG91Z2gg bm90IGEgIlBLSSBtb2RlbCIpLg0KPiA+DQo+ID4gRVRTSSBUUyAxMDIgOTQwIFYxLjEuMSAoMjAx Mi0wNikNCj4gPiAiSVRTIGNvbW11bmljYXRpb25zIHNlY3VyaXR5IGFyY2hpdGVjdHVyZSBhbmQN Cj4gPiAgICBzZWN1cml0eSBtYW5hZ2VtZW50Ig0KPiA+DQo+ID4gUmVjZW50IEVUU0kgSVRTIHNl Y3VyaXR5IGRpc2N1c3Npb25zIHRhbGsgYWJvdXQgY2VydGlmaWNhdGUgZm9ybWF0cw0KPiA+IGFu ZCBob3cgdG8gc2lnbiBtZXNzYWdlcy4NCj4gPg0KPiA+IEVUU0kgb3JnYW5pemVzIGEgU2VjdXJp dHkgd29ya3Nob3Agb24gSnVuZSAyNCBhbmQgMjUgb24gIlNlY3VyaXR5DQo+ID4gQXNzdXJhbmNl IGluIElUUyIgdGhlbWF0aWMgc3RyZWFtOg0KPiA+IGh0dHA6Ly93d3cuZXRzaS5vcmcvbmV3cy1l dmVudHMvZXZlbnRzLzg3MC1zZWN1cml0eS13ZWVrDQo+ID4NCj4gPiBBbGV4DQo+ID4NCj4gPg0K PiA+IExlIDI4LzA1LzIwMTUgMTA6NDUsIEpvbmctSHlvdWsgTGVlIGEgw6ljcml0IDoNCj4gPj4g SSBhbSBub3Qgc3VyZSBvdGhlciBzdGFuZGFyZCBtb2RlbHMsIGJ1dCBFVFNJIElUUyBzZWN1cml0 eSBncm91cHMNCj4gPj4gcHVibGlzaGVkIHJlbGF0ZWQgZG9jdW1lbnRzIGFuZCB0aGUgRXVyb3Bl YW4gQ0FSIDIgQ0FSIENvbW11bmljYXRpb24NCj4gPj4gQ29uc29ydGl1bSAoQzJDLUNDKSBhbHNv IGhhZCBpbnRlcm5hbCBkb2N1bWVudHMuIEFzIEkgYW0gbm8gbG9uZ2VyDQo+ID4+IGFjdGl2ZSBp biB0aGVtLCBJIGRvIG5vdCBrbm93IHRoZSBsYXRlc3Qgc3RhdHVzLg0KPiA+Pg0KPiA+PiBDaGVl cnMuIC0tIEpvbmctSHlvdWsgTGVlLCBsaXZpbmcgc29tZXdoZXJlIGJldHdlZW4gL2Rldi9udWxs IGFuZA0KPiA+PiAvZGV2L3JhbmRvbSBQcm90b2NvbCBFbmdpbmVlcmluZyBMYWIuLCBTYW5nbXl1 bmcgVW5pdmVyc2l0eQ0KPiA+Pg0KPiA+PiAjZW1haWw6IGpvbmdoeW91a0BnbWFpbC5jb20gI3dl YnBhZ2U6DQo+ID4+IGh0dHBzOi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRlL2h1cnJ5b24NCj4gPj4N Cj4gPj4+IE9uIE1heSA3LCAyMDE1LCBhdCA4OjU4IFBNLCBBbGV4YW5kcnUgUGV0cmVzY3UNCj4g Pj4+IDxhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPiB3cm90ZToNCj4gPj4+DQo+ID4+PiBI aSwNCj4gPj4+DQo+ID4+PiBXaGF0IGFyZSB0aGUgc3RhbmRhcmRzIHRoYXQgdHJlYXQgb2YgUEtJ IG1vZGVscyBpbiB0aGUgcGFydGljdWxhcg0KPiA+Pj4gY2FzZSBvZiB2ZWhpY3VsYXIgbmV0d29y a3M/DQo+ID4+Pg0KPiA+Pj4gQWxleA0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIGl0cyBtYWlsaW5nIGxpc3QNCj4gPj4+IGl0c0Bp ZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPiA+Pg0K PiA+Pg0KPiA+Pg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IGl0cyBtYWlsaW5nIGxpc3QNCj4gPiBpdHNAaWV0Zi5vcmcN Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPiA+DQo+ID4N Cj4gDQoNCg== From nobody Fri Jun 12 08:04:31 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E941A002C for ; Fri, 12 Jun 2015 08:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MANGLED_TRNFER=2.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 hFKjSMr4JhKq for ; Fri, 12 Jun 2015 08:04:28 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724D61A0045 for ; Fri, 12 Jun 2015 08:04:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5CF45Gp030100 for ; Fri, 12 Jun 2015 17:04:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DCEEF206135 for ; Fri, 12 Jun 2015 17:06:43 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D3C1B200B4D for ; Fri, 12 Jun 2015 17:06:43 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5CF40XV024585 for ; Fri, 12 Jun 2015 17:04:05 +0200 Message-ID: <557AF4E0.8090502@gmail.com> Date: Fri, 12 Jun 2015 17:04:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "its@ietf.org" References: <8e8523d44a41460685712c486157a9d2@xMail.etsihq.org> In-Reply-To: <8e8523d44a41460685712c486157a9d2@xMail.etsihq.org> X-Forwarded-Message-Id: <8e8523d44a41460685712c486157a9d2@xMail.etsihq.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [geonet/its] Fwd: [ITS-NEWS] ITS Security: standard on Security header and certificate formats published X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 15:04:30 -0000 Hello members of ITS at IETF, ETSI ITS just announced a new publicly available document for "ITS Security Header and certificate formats": *ETSI TS 103 097 V1.2.1 * In it the "IPv6" word appears once: > NOTE 2: Payloads of type signed_external are needed to add a > signature in a non-intrusive way to an existing protocol stack, e.g. > for extending an IPv6 stack. My comments are the following: 1. An IPv6 stack does not need extensions in order to support security. Typically IPsec protocols are built-in into IPv6 stacks. Are the payloads of type signed_external using IPsec? 2. Are the signatures of ETSI ITS messages carried on IPv6 packets? This would be very advantageous for networking together automobiles. Alex -------- Message transfr -------- Sujet : [ITS-NEWS] ITS Security: standard on Security header and certificate formats published Date : Fri, 12 Jun 2015 13:45:10 +0000 De : Martin Arndt Rpondre : Martin Arndt Pour : ITS-NEWS@LIST.ETSI.ORG Dear all, Please note that the following standard has been published recently. You can download it for free via the link given below. *ETSI TS 103 097 V1.2.1 * Intelligent Transport Systems (ITS); Security; Security header and certificate formats Kind regards, Martin ############################## Martin ARNDT Technical Officer ETSI Operations (OPS) Committee Support Centre (CSC) Telephone: +33 4 92 94 42 49 Skype: Mr Wavelength Email: martin.arndt@etsi.org Web: http://www.etsi.org ############################## From nobody Thu Jun 18 03:02:16 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E79B1B3104 for ; Thu, 18 Jun 2015 03:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_TRNFER=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 BUv7jfGqPdbD for ; Thu, 18 Jun 2015 03:02:10 -0700 (PDT) Received: from mx-relay35-dus.antispameurope.com (mx-relay35-dus.antispameurope.com [94.100.134.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23011A885E for ; Thu, 18 Jun 2015 03:02:08 -0700 (PDT) Received: from smtpsrv1.fokus.fraunhofer.de ([195.37.77.166]) by mx-gate35-dus.antispameurope.com; Thu, 18 Jun 2015 12:02:40 +0200 Received: from DIRAC.fokus.fraunhofer.de ([IPv6:2001:638:806:9::201]) by smtpsrv1.fokus.fraunhofer.de (8.14.4/8.14.4) with ESMTP id t5IA25EG006036 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 18 Jun 2015 12:02:05 +0200 Received: from [10.147.68.73] (10.147.68.73) by DIRAC.fokus.fraunhofer.de (10.147.9.201) with Microsoft SMTP Server id 14.3.224.2; Thu, 18 Jun 2015 12:02:06 +0200 Message-ID: <5582971C.4010407@fokus.fraunhofer.de> Date: Thu, 18 Jun 2015 12:02:04 +0200 From: Florian Friederici User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <8e8523d44a41460685712c486157a9d2@xMail.etsihq.org> <557AF4E0.8090502@gmail.com> In-Reply-To: <557AF4E0.8090502@gmail.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.147.68.73] X-KSE-Antivirus-Interceptor-Info: protection disabled X-cloud-security-sender: florian.friederici@fokus.fraunhofer.de X-cloud-security-recipient: its@ietf.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate35-dus with BF473211800B X-cloud-security-connect: smtpsrv1.fokus.fraunhofer.de[195.37.77.166], TLS=, IP=195.37.77.166 X-cloud-security: scantime:.1926 Archived-At: Subject: Re: [geonet/its] Fwd: [ITS-NEWS] ITS Security: standard on Security header and certificate formats published X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 10:02:14 -0000 Dear Alex, concerning your questions: (personal opinion and experience) 1) 103097 uses an envelope format (SecuredMessage) for its payload. signed_external is a way to create an non-envelope style security header and signature, i.e. the payload is not inside the envelope, but at any other place outside. This was used historical during the development of GeoNetworking at a time back when the networking layer had a different structure. Today, there is no need for signed_external any more, and I doubt that it will be used for extending an IPv6 stack soon. 2) For the v2v case, the network layer is GeoNetworking instead of IP. Best regards Florian Florian Friederici, M.Eng. Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31, 10589 Berlin, GERMANY Tel: +49 30 3463 7342 Mail: florian.friederici@fokus.fraunhofer.de Am 12.06.2015 um 17:04 schrieb Alexandru Petrescu: > Hello members of ITS at IETF, > > ETSI ITS just announced a new publicly available document for "ITS > Security Header and certificate formats": > *ETSI TS 103 097 V1.2.1 > * > > > In it the "IPv6" word appears once: >> NOTE 2: Payloads of type signed_external are needed to add a >> signature in a non-intrusive way to an existing protocol stack, e.g. >> for extending an IPv6 stack. > > My comments are the following: > > 1. An IPv6 stack does not need extensions in order to support > security. Typically IPsec protocols are built-in into IPv6 stacks. > Are the payloads of type signed_external using IPsec? > > 2. Are the signatures of ETSI ITS messages carried on IPv6 packets? > This would be very advantageous for networking together automobiles. > > Alex > > > > > -------- Message transfr -------- > Sujet : [ITS-NEWS] ITS Security: standard on Security header and > certificate formats published > Date : Fri, 12 Jun 2015 13:45:10 +0000 > De : Martin Arndt > Rpondre : Martin Arndt > Pour : ITS-NEWS@LIST.ETSI.ORG > > > > Dear all, > > Please note that the following standard has been published recently. You > can download it for free via the link given below. > > *ETSI TS 103 097 V1.2.1 > * > > > Intelligent Transport Systems (ITS); > > Security; > > Security header and certificate formats > > Kind regards, > > Martin > > ############################## > > Martin ARNDT > > Technical Officer > > ETSI Operations (OPS) > > Committee Support Centre (CSC) > > Telephone: +33 4 92 94 42 49 > > Skype: Mr Wavelength > > Email: martin.arndt@etsi.org > > Web: http://www.etsi.org > > ############################## > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Jun 19 04:38:23 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345891A89B3 for ; Fri, 19 Jun 2015 04:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MANGLED_TRNFER=2.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 ATUfq-PH_gqx for ; Fri, 19 Jun 2015 04:38:18 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E23F1A89A9 for ; Fri, 19 Jun 2015 04:38:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5JBcGlg017644 for ; Fri, 19 Jun 2015 13:38:16 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3CBE3201F93 for ; Fri, 19 Jun 2015 13:41:04 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 32A98201F1B for ; Fri, 19 Jun 2015 13:41:04 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5JBcCgX016144 for ; Fri, 19 Jun 2015 13:38:15 +0200 Message-ID: <5583FF24.6010404@gmail.com> Date: Fri, 19 Jun 2015 13:38:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: its@ietf.org References: <8e8523d44a41460685712c486157a9d2@xMail.etsihq.org> <557AF4E0.8090502@gmail.com> <5582971C.4010407@fokus.fraunhofer.de> In-Reply-To: <5582971C.4010407@fokus.fraunhofer.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [geonet/its] Fwd: [ITS-NEWS] ITS Security: standard on Security header and certificate formats published X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 11:38:22 -0000 Hi Florian, Thanks for the reply. Le 18/06/2015 12:02, Florian Friederici a crit : > Dear Alex, > > concerning your questions: > > (personal opinion and experience) > > 1) 103097 uses an envelope format (SecuredMessage) for its payload. > signed_external is a way to create an non-envelope style security > header and signature, i.e. the payload is not inside the envelope, > but at any other place outside. Interesting. The IPsec protocols of IPv6 also consider that distinction: there is transport mode and tunnel mode. The tunnel mode is a little bit like the 'envelope' concept of 103097, and the transport mode is an ESP or AH header and signature (like the non-envelope). > This was used historical during the development of GeoNetworking at > a time back when the networking layer had a different structure. Ok. Maybe there is ongoing development now at ETSI ITS that may consider IPsec transport and tunnel modes. The advantage of doing so is that IPv6 applications can be reused extensively in vehicular communications. > Today, there is no need for signed_external any more, and I doubt > that it will be used for extending an IPv6 stack soon. Well. If I understand correctly, the 'signed_external' is like the transport mode of IPsec. The transport mode of IPsec has some advantages over the tunnel mode: the IPv6 packets are smaller (some headers are absent) - they may be faster to process and transmit. This may be important when the dynamics of vehicles are higher, if I can say so. > 2) For the v2v case, the network layer is GeoNetworking instead of > IP. Well. I think for the v2v case it would be good to consider IP at the same time at GeoNetworking. There are some advantages of doing so: widely available cheap and reliable software, reuse of existing desktop TCP/IP applications, instant end-to-end connectivity to the global Internet, and, not least - programmer skillset. Alex > > Best regards Florian > > > Florian Friederici, M.Eng. Fraunhofer Institute for Open > Communication Systems Kaiserin-Augusta-Allee 31, 10589 Berlin, > GERMANY Tel: +49 30 3463 7342 Mail: > florian.friederici@fokus.fraunhofer.de > > Am 12.06.2015 um 17:04 schrieb Alexandru Petrescu: >> Hello members of ITS at IETF, >> >> ETSI ITS just announced a new publicly available document for "ITS >> Security Header and certificate formats": *ETSI TS 103 097 V1.2.1 >> * >> >> >> >> In it the "IPv6" word appears once: >>> NOTE 2: Payloads of type signed_external are needed to add a >>> signature in a non-intrusive way to an existing protocol stack, >>> e.g. for extending an IPv6 stack. >> >> My comments are the following: >> >> 1. An IPv6 stack does not need extensions in order to support >> security. Typically IPsec protocols are built-in into IPv6 >> stacks. Are the payloads of type signed_external using IPsec? >> >> 2. Are the signatures of ETSI ITS messages carried on IPv6 >> packets? This would be very advantageous for networking together >> automobiles. >> >> Alex >> >> >> >> >> -------- Message transfr -------- Sujet : [ITS-NEWS] ITS >> Security: standard on Security header and certificate formats >> published Date : Fri, 12 Jun 2015 13:45:10 +0000 De : >> Martin Arndt Rpondre : Martin Arndt >> Pour : ITS-NEWS@LIST.ETSI.ORG >> >> >> >> Dear all, >> >> Please note that the following standard has been published >> recently. You can download it for free via the link given below. >> >> *ETSI TS 103 097 V1.2.1 >> * >> >> >> >> Intelligent Transport Systems (ITS); >> >> Security; >> >> Security header and certificate formats >> >> Kind regards, >> >> Martin >> >> ############################## >> >> Martin ARNDT >> >> Technical Officer >> >> ETSI Operations (OPS) >> >> Committee Support Centre (CSC) >> >> Telephone: +33 4 92 94 42 49 >> >> Skype: Mr Wavelength >> >> Email: martin.arndt@etsi.org >> >> Web: http://www.etsi.org >> >> ############################## >> >> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Wed Jun 24 04:33:49 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01691A887B for ; Wed, 24 Jun 2015 04:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 A2uS0SM0zFvY for ; Wed, 24 Jun 2015 04:33:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC96D1A887A for ; Wed, 24 Jun 2015 04:33:45 -0700 (PDT) Received: from SN1PR11MB0992.namprd11.prod.outlook.com (10.164.25.158) by SN1PR11MB0991.namprd11.prod.outlook.com (10.164.25.157) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 24 Jun 2015 11:33:25 +0000 Received: from SN1PR11MB0992.namprd11.prod.outlook.com ([10.164.25.158]) by SN1PR11MB0992.namprd11.prod.outlook.com ([10.164.25.158]) with mapi id 15.01.0195.005; Wed, 24 Jun 2015 11:33:25 +0000 From: Devendra Naga C To: "its@ietf.org" Thread-Topic: Usage of LS packet Thread-Index: AQHQrnEPUnqHOAhIl063zflcgPHU1g== Date: Wed, 24 Jun 2015 11:33:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [202.83.18.210] x-microsoft-exchange-diagnostics: 1; SN1PR11MB0991; 5:/H/udB6ZVQWhq/nPxfhgZfZiEzVYEv3h4SAdCpk1Zq+LYAFlfKqTlHfVZ8jXKfn/weVa5BfK2mDtCF+3IttIboEJlazBxNgDK4PQ6NpIcV3W6rZBeSbkFgl/dv8rqA+kXfyKn1Vg1p41PXsnSWjPgA==; 24:eFFQc5BmGJRdkwD06kIZNFeIeXZAWF1q1tFqWE0C0qorRP9v9vfzAG+n1zgnMcBcFenyWW12OnlVcHQVCOo54WuiXBwgk1LkOy6AkTwwJ80=; 20:m1DfCe8Qn3Zk3YtU1p+tMEKDOL+rRDAJ4S1hFgudFgwPmdad0+3BlL6JWxwfTZYaWIX9hCmpztb31hG1LsCZ0Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR11MB0991; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR11MB0991; BCL:0; PCL:0; RULEID:; SRVR:SN1PR11MB0991; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(77096005)(99286002)(54356999)(50986999)(2351001)(2900100001)(16236675004)(102836002)(229853001)(2501003)(76576001)(5002640100001)(107886002)(5001960100002)(92566002)(110136002)(19625215002)(87936001)(62966003)(19627405001)(106116001)(86362001)(189998001)(66066001)(74316001)(40100003)(33656002)(2656002)(5003600100002)(450100001)(77156002)(46102003)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR11MB0991; H:SN1PR11MB0992.namprd11.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR11MB0992D38D0BE12B49309B9F78D1AF0SN1PR11MB0992namp_" MIME-Version: 1.0 X-OriginatorOrg: savarinetworks.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2015 11:33:25.3430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9dc1da0b-b435-4de8-904d-9d72bfe54e9f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR11MB0991 Archived-At: Subject: [geonet/its] Usage of LS packet X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 11:33:48 -0000 --_000_SN1PR11MB0992D38D0BE12B49309B9F78D1AF0SN1PR11MB0992namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, This question is to understand the usage of the LS packet (Req and Reply) i= n the geo-networking protocol. As per my understanding these packets are us= eful in locating a geo-adhoc router that is not reachable by the geo-networ= king beacon. 1. How a geo-adhoc router finds the destination MID in the first place befo= re sending an LS-Req ? 2. What makes a geo-adhoc router to find about the destination ? 3. What is the real world example of the LS-Req and LS-Rep packets? (Might = be this relates to the second question) Thank you. Dev --_000_SN1PR11MB0992D38D0BE12B49309B9F78D1AF0SN1PR11MB0992namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,


This question is to understand the usage of the LS packet (Req and Reply= ) in the geo-networking protocol. As per my understanding these packets are= useful in locating a geo-adhoc router that is not reachable by the ge= o-networking beacon.


1. How a geo-adhoc router finds the destination MID in the first place b= efore sending an LS-Req ?

2. What makes a geo-adhoc router to find about the destination ?

3. What is the real world example of the LS-Req and LS-Rep packets? (Mig= ht be this relates to the second question)


Thank you.

Dev

--_000_SN1PR11MB0992D38D0BE12B49309B9F78D1AF0SN1PR11MB0992namp_-- From nobody Wed Jun 24 07:39:07 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2BE1ACD16 for ; Wed, 24 Jun 2015 07:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 HqAZDlRbS2B9 for ; Wed, 24 Jun 2015 07:38:52 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7031ACD2B for ; Wed, 24 Jun 2015 07:38:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5OEcn87004006 for ; Wed, 24 Jun 2015 16:38:49 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E702D207197 for ; Wed, 24 Jun 2015 16:41:44 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D39B72026CD for ; Wed, 24 Jun 2015 16:41:44 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5OEcjVQ022987 for ; Wed, 24 Jun 2015 16:38:49 +0200 Message-ID: <558AC0F5.9020606@gmail.com> Date: Wed, 24 Jun 2015 16:38:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: its@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [geonet/its] Usage of LS packet X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 14:39:04 -0000 Le 24/06/2015 13:33, Devendra Naga C a crit : > Hello, > > > This question is to understand the usage of the LS packet (Req and > Reply) in the geo-networking protocol. As per my understanding these > packets are useful in locating a geo-adhoc router that is not reachable > by the geo-networking beacon. > > > 1. How a geo-adhoc router finds the destination MID in the first place > before sending an LS-Req ? I dont know, but here is my suggestion on how to do it. Fit a webcam on the car, read the nearby car's license plate. Find the correlation plate-VIN number on some database on the Internet. Convert the VIN into a MID. That is if you absolutely need a MID, and geo-networking protocol. You can achieve the same effect differently: have everyone declare her presence with an IPv6 MLD Report message. At that point every car knows each other's address. > 2. What makes a geo-adhoc router to find about the destination ? Sorry, repeat the question? > 3. What is the real world example of the LS-Req and LS-Rep packets? > (Might be this relates to the second question) I think LS-Req/Rep stand for Link-State Request and Response? If so, I suppose they are relics of OSPF inspiration of geo-aware manet protocols? What does LS stand for? What is the application you think about? The use-case? Alex > > > Thank you. > > Dev > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Wed Jun 24 07:57:06 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000851A1A90 for ; Wed, 24 Jun 2015 07:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Bh85d4LO3j2C for ; Wed, 24 Jun 2015 07:57:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0120.outbound.protection.outlook.com [65.55.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD091A1A83 for ; Wed, 24 Jun 2015 07:57:02 -0700 (PDT) Received: from SN1PR11MB0992.namprd11.prod.outlook.com (10.164.25.158) by SN1PR11MB0990.namprd11.prod.outlook.com (10.164.25.156) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 24 Jun 2015 14:56:59 +0000 Received: from SN1PR11MB0992.namprd11.prod.outlook.com ([10.164.25.158]) by SN1PR11MB0992.namprd11.prod.outlook.com ([10.164.25.158]) with mapi id 15.01.0195.005; Wed, 24 Jun 2015 14:56:59 +0000 From: Devendra Naga C To: Alexandru Petrescu , "its@ietf.org" Thread-Topic: [geonet/its] Usage of LS packet Thread-Index: AQHQrnEPUnqHOAhIl063zflcgPHU1p27uhCAgAAA4I8= Date: Wed, 24 Jun 2015 14:56:59 +0000 Message-ID: References: , <558AC0F5.9020606@gmail.com> In-Reply-To: <558AC0F5.9020606@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [106.216.211.135] x-microsoft-exchange-diagnostics: 1; SN1PR11MB0990; 5:FNZMmC+Gfz0aWN4f9fM4DqrXyW0mpUm6lBaik+fwsSLBv/bK7jEhQYUdmmNJUS/SkeBXTJ1SZAeNqyQM3dnqtnVKNVGAj+1ss6mA2Gmk4hL+kF1AjJdDqeJBXvXV1IdFx7ajbqcwONUyTrX71s/J3w==; 24:Y/vwE9tV4TYySpullK7WQjDe71loX8bsEjlRIJSK5DObyRxliJZfSGnReDFw9rWSBclJN30ugCYRdtXMGVwZsiuXJGDLykH5EsJ8qfi3O4s=; 20:RQ52gA7exTY6lZ9w0LPIT+ziBhL/QgGYKt1ossIypDoHViqt9TFNAZwn7nXlVHjdbjvJcVjW96SDkBgSBfryLA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR11MB0990; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR11MB0990; BCL:0; PCL:0; RULEID:; SRVR:SN1PR11MB0990; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(479174004)(77096005)(15975445007)(102836002)(189998001)(107886002)(2501003)(2900100001)(92566002)(19580405001)(19580395003)(5002640100001)(5003600100002)(5001960100002)(33656002)(2950100001)(74316001)(106116001)(122556002)(46102003)(66066001)(76176999)(62966003)(54356999)(2656002)(77156002)(40100003)(99286002)(50986999)(87936001)(76576001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR11MB0990; H:SN1PR11MB0992.namprd11.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: savarinetworks.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2015 14:56:59.1221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9dc1da0b-b435-4de8-904d-9d72bfe54e9f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR11MB0990 Archived-At: Subject: Re: [geonet/its] Usage of LS packet X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 14:57:05 -0000 [Sorry about my email client- it doesn't support inline replies, i had to = add the '>' s] Hello, Le 24/06/2015 13:33, Devendra Naga C a =E9crit : >> Hello, >> >> >> This question is to understand the usage of the LS packet (Req and >> Reply) in the geo-networking protocol. As per my understanding these >> packets are useful in locating a geo-adhoc router that is not reachable >> by the geo-networking beacon. >> >> >> 1. How a geo-adhoc router finds the destination MID in the first place >> before sending an LS-Req ? > I dont know, but here is my suggestion on how to do it. > Fit a webcam on the car, read the nearby car's license plate. Find the > correlation plate-VIN number on some database on the Internet. Convert > the VIN into a MID. > That is if you absolutely need a MID, and geo-networking protocol. > You can achieve the same effect differently: have everyone declare her > presence with an IPv6 MLD Report message. At that point every car knows > each other's address. I am referring to the Location Service packet (aka the LS packet) of the Ge= o networking protocol defined in ETSI EN 302-636-4-1 (v1.2.0). Sorry about not stating it clearly. >From the document, The LS-Request packet is sent out from a host that does = not have the destination information (such as its LPV) in the location serv= ice table (LocT). But if the vehicle is only equipped with a DSRC based dev= ice, how does it figures about what MID it has to send an LS-Request to ? o= r in an easier way to ask the question, does LS-Request is used to expand t= he coverage range of a DSRC device when in case of an alert or an advisory = ? > 2. What makes a geo-adhoc router to find about the destination ? > Sorry, repeat the question? My apologies here again. The question is related to the similar concept of = why a packet in the geo-networking needs to be forwarded to a destination that is unknown to the geo-networking layer itse= lf (because the destination is out of the range of the host vehicle). > 3. What is the real world example of the LS-Req and LS-Rep packets? > (Might be this relates to the second question) > I think LS-Req/Rep stand for Link-State Request and Response? If so, I > suppose they are relics of OSPF inspiration of geo-aware manet protocols? I was referring about the Geo-networking standard ETSI EN 302-636-4-1. > What does LS stand for? Location Service > What is the application you think about? The use-case? Its a stack that i am currently developing on the geo-networking using the = above mentioned standard. That is the Geo-networking using the DSRC as a me= dium of communication in the Layer 2. > Alex Thank you. Dev > > > Thank you. > > Dev > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Wed Jun 24 08:46:54 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEBF1ACD97 for ; Wed, 24 Jun 2015 08:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 ICkGiXjPPXhA for ; Wed, 24 Jun 2015 08:46:52 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D007F1AC82C for ; Wed, 24 Jun 2015 08:46:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5OFkoku004543; Wed, 24 Jun 2015 17:46:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 97A74205C73; Wed, 24 Jun 2015 17:49:45 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8AB61207226; Wed, 24 Jun 2015 17:49:45 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5OFkku0026144; Wed, 24 Jun 2015 17:46:49 +0200 Message-ID: <558AD0E6.3050503@gmail.com> Date: Wed, 24 Jun 2015 17:46:46 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Devendra Naga C , "its@ietf.org" References: , <558AC0F5.9020606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [geonet/its] Usage of LS packet X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 15:46:54 -0000 Dont worry emailers - cite as you can. Le 24/06/2015 16:56, Devendra Naga C a crit : > > [Sorry about my email client- it doesn't support inline replies, i > had to add the '>' s] > > Hello, > > Le 24/06/2015 13:33, Devendra Naga C a crit : >>> Hello, >>> >>> >>> This question is to understand the usage of the LS packet (Req >>> and Reply) in the geo-networking protocol. As per my >>> understanding these packets are useful in locating a geo-adhoc >>> router that is not reachable by the geo-networking beacon. >>> >>> >>> 1. How a geo-adhoc router finds the destination MID in the first >>> place before sending an LS-Req ? > >> I dont know, but here is my suggestion on how to do it. > >> Fit a webcam on the car, read the nearby car's license plate. Find >> the correlation plate-VIN number on some database on the Internet. >> Convert the VIN into a MID. > >> That is if you absolutely need a MID, and geo-networking protocol. > >> You can achieve the same effect differently: have everyone declare >> her presence with an IPv6 MLD Report message. At that point every >> car knows each other's address. > > I am referring to the Location Service packet (aka the LS packet) of > the Geo networking protocol defined in ETSI EN 302-636-4-1 (v1.2.0). > Sorry about not stating it clearly. Ok, for that to progress here you will need to make that document into an Internet Draft. Because we can't debug ETSI ITS documents here. Can you write an Internet Draft which describes ETSI EN 302-636-4-1 (v1.2.0)? In that draft you can formulate that MID question more clearly. >> From the document, The LS-Request packet is sent out from a host >> that does not have the destination information (such as its LPV) in >> the location service table (LocT). But if the vehicle is only >> equipped with a DSRC based device, how does it figures about what >> MID it has to send an LS-Request to ? or in an easier way to ask >> the question, does LS-Request is used to expand the coverage range >> of a DSRC device when in case of an alert or an advisory ? > >> 2. What makes a geo-adhoc router to find about the destination ? > >> Sorry, repeat the question? > > My apologies here again. The question is related to the similar > concept of why a packet in the geo-networking needs to be forwarded > to a destination that is unknown to the geo-networking layer itself > (because the destination is out of the range of the host vehicle). Ok, so I understand you know how to implement that forwarding but you dont have the MID. I dont know how others find the MID? I suppose it is often pre-encoded, known in advance. This is acceptable in a laboratory or demo setting, but it is of course unacceptable in more mature deployments. For that you will need to come up with a scheme to 'resolve' that initial MID. Feel free to propose. > >> 3. What is the real world example of the LS-Req and LS-Rep >> packets? (Might be this relates to the second question) > >> I think LS-Req/Rep stand for Link-State Request and Response? If >> so, I suppose they are relics of OSPF inspiration of geo-aware >> manet protocols? > > I was referring about the Geo-networking standard ETSI EN > 302-636-4-1. > >> What does LS stand for? > > Location Service Ok, we need to be careful with this term. Because Service Location Protocol (SLP) has a very well defined meaning at IETF, it's an RFC. >> What is the application you think about? The use-case? > > Its a stack that i am currently developing on the geo-networking > using the above mentioned standard. That is the Geo-networking using > the DSRC as a medium of communication in the Layer 2. What headers are used between the Geo-Networking headers and the DSRC headers? (just use wireshark to find out, it's easy). Alex > > >> Alex > > Thank you. Dev > >> >> >> Thank you. >> >> Dev >> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Fri Jun 26 04:36:15 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438201AD0A4 for ; Fri, 26 Jun 2015 04:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 pr1GLmxwsrme for ; Fri, 26 Jun 2015 04:36:12 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 794581AD071 for ; Fri, 26 Jun 2015 04:36:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5QBaAZO025109 for ; Fri, 26 Jun 2015 13:36:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AAB0520370C for ; Fri, 26 Jun 2015 13:39:08 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 98628201185 for ; Fri, 26 Jun 2015 13:39:08 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5QBaAd9024302 for ; Fri, 26 Jun 2015 13:36:10 +0200 Message-ID: <558D392A.2060809@gmail.com> Date: Fri, 26 Jun 2015 13:36:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "its@ietf.org" References: <75485AE0FF66EA4EA0473A6E912810F52681BD3DDD@MBX061.renault.mail.noxiane.net> In-Reply-To: <75485AE0FF66EA4EA0473A6E912810F52681BD3DDD@MBX061.renault.mail.noxiane.net> X-Forwarded-Message-Id: <75485AE0FF66EA4EA0473A6E912810F52681BD3DDD@MBX061.renault.mail.noxiane.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [geonet/its] Fwd: TR: New Version Notification for draft-lonc-tls-certieee1609-01.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 11:36:14 -0000 Hello, For information, there is a new draft about TLS security. It has been announced on the IETF announcements and ETSI ITS WG5 (Security) email lists. Please comment: https://www.ietf.org/internet-drafts/draft-lonc-tls-certieee1609-01.txt Yours, Alex Petrescu