From nobody Sun Nov 1 23:05:56 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 7C0D11B31B2 for ; Sun, 1 Nov 2015 23:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 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, HTML_MESSAGE=0.001, 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 2EMxqeN2GOfI for ; Sun, 1 Nov 2015 23:05:50 -0800 (PST) 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 D39D61B30D3 for ; Sun, 1 Nov 2015 23:05:47 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id tA275jUg014853; Mon, 2 Nov 2015 08:05:45 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0B18B20A41F; Mon, 2 Nov 2015 08:11:12 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F004920A3D3; Mon, 2 Nov 2015 08:11:11 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.42]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id tA27580O021051; Mon, 2 Nov 2015 08:05:14 +0100 References: To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: Message-ID: <56370B24.1050000@gmail.com> Date: Mon, 2 Nov 2015 16:05:08 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060708080404070303040307" Archived-At: Cc: "George, Wes" Subject: [its] Fwd: comments on vehicular communication drafts X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 07:05:53 -0000 This is a multi-part message in MIME format. --------------060708080404070303040307 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello ITSers, We have received comments on the its-cacc-sdo and its-problem Internet Drafts. They are mixed with comments on drafts of the [ecrit] WG, since these deal with vehicular communications as well. What do you think? Alex -------- Message transféré -------- Sujet : comments on vehicular communication drafts Date : Sun, 1 Nov 2015 13:08:47 +0000 De : George, Wes Pour : draft-ietf-ecrit-ecall@ietf.org , draft-ietf-ecrit-car-crash@ietf.org , draft-petrescu-its-problem@ietf.org , draft-petrescu-its-cacc-sdo@ietf.org Hi – I read these drafts mainly out of curiosity, as it is an interesting overlap between a thing I love (cars) and a thing I'm interested in/do for my day job (networking/IETF), but after reading them, I have a few comments that I think apply to several of these drafts equally, hence the multiple drafts on the distro. Worth noting that I am writing this on a plane without internet access and thus cannot follow some of the RFCs referenced, so it's entirely possible that some of my comments are covered by the existing referenced RFCs. My apologies if this is the case. Either way (text quoted from the eCall draft) this gave me pause: O The ability to handle text o The ability for the PSAP to access vehicle components (e.g., an onboard camera (such as rear facing or blind-spot cameras) for a visual assessment of the crash site situation) o The ability for the PSAP to request the vehicle to take actions (e.g., sound the horn, disable the ignition, lock/unlock doors) The security considerations sections need bolstering in light of recent revelations around the vulnerability of many CANBUS vehicles for attacks via their existing cellular/data connections. The ability to handle text brings with it the ability to trigger buffer overruns and other exploits, and so there should be specific discussion about input validation and protection against this attack vector. Accessing and manipulating vehicle components especially critical systems is enough of a privacy and safety concern that there should be more specific text about how to prevent unauthorized access. I think this starts with removing this (IMO) faulty assertion: "emergency call placed over a cellular network, there is a higher degree of trust that the source is indeed a PSAP" and replacing it with something that reinforces the "trust but verify" model, since the cellular network, while marginally more secure, is subject to call interception and manipulation from a suitably motivated and equipped actor, just like any other network. (google Stingray, for example) This section should also discuss, in detail, what is an acceptable level of security for the certificate to validate that the PSAP is authorized to send these sorts of commands, whether in call-back or in initial call, whether the payload data MUST/SHOULD be encrypted on the path to prevent interception/manipulation, and usual certificate based best practices such as mandatory to implement (or mandatory to avoid due to proven insecurity) algorithms, best practices for keyrolls, cert revocation, etc. as well as probably some text about general security best practices (remote software updates, third-party pentesting, airgaps, signed software, etc). There's no reason to reinvent this, but you need to reference existing IETF standards defining this for e.g. TLS, PKI, etc. and adapt where appropriate. Automakers have demonstrated on multiple occasions that they either don't understand these aspects of security in the connected car or don't understand why it's important, (e.g BMW not using HTTPS) so erring on the side of too much info is IMO the right model, because we have no reason to believe that the other SDOs involved in this effort will possess the standards and expertise, nor motivation to document it properly. In the case of the Petrescu drafts, explicit language identifying the system as read-only would probably limit the exposure to some of the concerns I raised above specific to manipulating important systems as described in the eCall drafts, but ultimately due to the interconnectedness of these systems within the vehicle and these drafts, it might make more sense to assume that this opens a new attack vector to pivot through systems via V2V communications, and discuss ways to harden the overall system accordingly. I am by no means a security expert, so I'm sure that there's more I'm missing. It may be useful to ask for an early security directorate review for this set of drafts, or even to ask the Security ADs to suggest one or more security folks that you can ask to assist in fleshing out the security considerations. You're also missing an opportunity to suggest that if this uses IP networking, that it MUST support IPv6, given the number of devices expected to be present, the timeline for deployment, etc. While that is not necessarily critical to the function of the protocol itself, it definitely bears mentioning as acknowledging the reality of applications that want to add hundreds of thousands of IP nodes to the mobile data network in the era of exhausted IPv4. Thanks, Wes George Anything below this line has been added by my company’s mail server, I have no control over it. ----------- ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. --------------060708080404070303040307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello ITSers,

We have received comments on the its-cacc-sdo and its-problem Internet Drafts.  They are mixed with comments on drafts of the [ecrit] WG, since these deal with vehicular communications as well.

What do you think?

Alex

-------- Message transféré --------
Sujet : comments on vehicular communication drafts
Date : Sun, 1 Nov 2015 13:08:47 +0000
De : George, Wes <wesley.george@twcable.com>
Pour : draft-ietf-ecrit-ecall@ietf.org <draft-ietf-ecrit-ecall@ietf.org>, draft-ietf-ecrit-car-crash@ietf.org <draft-ietf-ecrit-car-crash@ietf.org>, draft-petrescu-its-problem@ietf.org <draft-petrescu-its-problem@ietf.org>, draft-petrescu-its-cacc-sdo@ietf.org <draft-petrescu-its-cacc-sdo@ietf.org> 


Hi – I read these drafts mainly out of curiosity, as it is an interesting
overlap between a thing I love (cars) and a thing I'm interested in/do for
my day job (networking/IETF), but after reading them, I have a few
comments that I think apply to several of these drafts equally, hence the
multiple drafts on the distro. Worth noting that I am writing this on a
plane without internet access and thus cannot follow some of the RFCs
referenced, so it's entirely possible that some of my comments are covered
by the existing referenced RFCs. My apologies if this is the case.

Either way (text quoted from the eCall draft) this gave me pause:
   O  The ability to handle text
   o  The ability for the PSAP to access vehicle components (e.g., an
      onboard camera (such as rear facing or blind-spot cameras) for a
      visual assessment of the crash site situation)
   o  The ability for the PSAP to request the vehicle to take actions
      (e.g., sound the horn, disable the ignition, lock/unlock doors)

The security considerations sections need bolstering in light of recent
revelations around the vulnerability of many CANBUS vehicles for attacks
via their existing cellular/data connections. The ability to handle text
brings with it the ability to trigger buffer overruns and other exploits,
and so there should be specific discussion about input validation and
protection against this attack vector. Accessing and manipulating vehicle
components especially critical systems is enough of a privacy and safety
concern that there should be more specific text about how to prevent
unauthorized access. I think this starts with removing this (IMO) faulty
assertion:
"emergency call placed over a cellular network, there is a higher degree
of trust that the source is indeed a PSAP" and replacing it with something
that reinforces the "trust but verify" model, since the cellular network,
while marginally more secure, is subject to call interception and
manipulation from a suitably motivated and equipped actor, just like any
other network. (google Stingray, for example)
This section should also discuss, in detail, what is an acceptable level
of security for the certificate to validate that the PSAP is authorized to
send
these sorts of commands, whether in call-back or in initial call, whether
the payload data MUST/SHOULD be encrypted on the path to prevent
interception/manipulation, and usual certificate based best practices such
as mandatory to implement (or mandatory to avoid due to proven insecurity)
algorithms, best practices for keyrolls, cert revocation, etc. as well as
probably some text about general security best practices (remote software
updates, third-party pentesting, airgaps, signed software, etc). There's
no reason to reinvent this, but you need to reference existing IETF
standards defining this for e.g. TLS, PKI, etc. and adapt where
appropriate. Automakers have demonstrated on multiple occasions that they
either don't understand these aspects of security in the connected car or
don't understand why it's important, (e.g BMW not using HTTPS) so erring
on the side of too much
info is IMO the right model, because we have no reason to believe that the
other SDOs involved in this effort will possess the standards and
expertise, nor motivation to document it properly. In the case of the
Petrescu drafts, explicit language identifying the system as read-only
would probably limit the exposure to some of the concerns I raised above
specific to manipulating important systems as described in the eCall
drafts, but ultimately due to the interconnectedness of these systems
within the vehicle and these drafts, it might make more sense to assume
that this opens a new attack vector to pivot through systems via V2V
communications, and discuss ways to harden the overall system accordingly.

I am by no means a security expert, so I'm sure that there's more I'm
missing. It may be useful to ask for an early security directorate review
for this set of drafts, or even to ask the Security ADs to suggest one or
more security folks that you can ask to assist in fleshing out the
security considerations.

You're also missing an opportunity to suggest that if this uses IP
networking, that it MUST support IPv6, given the number of devices
expected to be present, the timeline for deployment, etc. While that is
not necessarily critical to the function of the protocol itself, it
definitely bears mentioning as acknowledging the reality of applications
that want to add hundreds of thousands of IP nodes to the mobile data
network in the era of exhausted IPv4.


Thanks,



Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------




________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


--------------060708080404070303040307-- From nobody Tue Nov 3 17:53: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 E12771A88F0 for ; Tue, 3 Nov 2015 17:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, 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 FJp7ZnwH1K8i for ; Tue, 3 Nov 2015 17:53:11 -0800 (PST) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115021A8967 for ; Tue, 3 Nov 2015 17:53:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.20,240,1444687200"; d="png'150?scan'150,208,217,150";a="51484023" Received: from exc-cashub01.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 04 Nov 2015 02:53:05 +0100 Received: from EXC-MBX02.tsn.tno.nl ([fe80::5836:4645:c512:f964]) by EXC-CASHUB01.tsn.tno.nl ([fe80::b855:be6:1aa8:4d0f%13]) with mapi id 14.03.0248.002; Wed, 4 Nov 2015 02:53:06 +0100 From: "Wissingh, B.F. (Bastiaan)" To: "its@ietf.org" Thread-Topic: How about using ICN? Thread-Index: AQHRFqOMQ1ejoijz7EeQRnz8MAgImg== Date: Wed, 4 Nov 2015 01:53:05 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [134.221.225.191] Content-Type: multipart/related; boundary="_004_D5DFE44F6397474C932F62F3D75F44B3tnonl_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [its] How about using ICN? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 01:53:19 -0000 --_004_D5DFE44F6397474C932F62F3D75F44B3tnonl_ Content-Type: multipart/alternative; boundary="_000_D5DFE44F6397474C932F62F3D75F44B3tnonl_" --_000_D5DFE44F6397474C932F62F3D75F44B3tnonl_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpEdXJpbmcgdGhlIFdlbGNvbWUgUmVjZXB0aW9uIHBhc3QgU3VuZGF5LCBBbGV4 IGFuZCBJIGhhZCBhIGRpc2N1c3Npb24gcmVnYXJkaW5nIHdoYXQgdGhlIGJlbmVmaXRzIHdvdWxk IGJlIGZvciBoYXZpbmcgSVAgYmFzZWQgY29tbXVuaWNhdGlvbiBpbiBWMlYgc2NlbmFyaW9zIGFu ZCB3aGF0IG90aGVyIHBvc3NpYmlsaXRpZXMgd291bGQgYmUgc3VpdGFibGUuIE9uZSBvZiB0aGUg Y29uY2VwdHMgd2UgZGlzY3Vzc2VkIGlzIHRoZSBjb25jZXB0IG9mIEluZm9ybWF0aW9uIENlbnRy aWMgTmV0d29ya2luZyAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9yZy9pY25yZy9jaGFy dGVyLyksIHdoZXJlIElDTiBmb2N1c2VzIG9uIGZpbmRpbmcgYW5kIGRlbGl2ZXJpbmcgbmFtZWQg Y29udGVudHMsIGluc3RlYWQgb2Ygc2V0dGluZy11cCBhbmQgbWFpbnRhaW5pbmcgZW5kLXRvLWVu ZCBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIGhvc3RzIGlkZW50aWZpZWQgYnkgSVAgYWRkcmVzc2Vz LiBXaGljaCBzZWVtcyB2ZXJ5IHByb21pc2luZywgYWxzbyBpbiBuZXR3b3JrcyB3aXRoIGZhc3Qg Y2hhbmdpbmcgdG9wb2xvZ2llcyBsaWtlIFZBTkVU4oCZcy4NCg0KUmVsYXRlZCB0byB0aGlzLCBz b21lIGludGVyZXN0aW5nIHdvcmsgaGFzIGFscmVhZHkgYmVlbiBkb25lIGluIGltcGxlbWVudGlu ZyBhIHByb3RvdHlwZSBvZiBWZWhpY3VsYXItTkROIGFuZCBwcmVmb3JtaW5nIHNvbWUgaW5pdGlh bCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudHMsIHNlZSB0aGUgZm9sbG93aW5nIHBhcGVyOiBodHRw Oi8vbmFtZWQtZGF0YS5uZXQvd3AtY29udGVudC91cGxvYWRzLzIwMTQvMDMvdmFuZXRfdmlhX25k bl9pbmZvY29tX25vbS5wZGYNCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCkJlc3QgcmVnYXJkcywN Cg0KDQoNCkIuRi4gKEJhc3RpYWFuKSBXaXNzaW5naCBNU2MNClNjaWVudGlzdCBJbm5vdmF0b3IN Ck1lZGEgYW5kIE5ldHdvcmsgU2VydmljZXMNCg0KVCAtDQpNIC0NCkUgYmFzdGlhYW4ud2lzc2lu Z2hAdG5vLm5sPG1haWx0bzpiYXN0aWFhbi53aXNzaW5naEB0bm8ubmw+DQoNCkxvY2F0aWU8aHR0 cDovL3d3dy50bm8ubmwvbG9jYXRpZXMvZHRiPg0KRGlzY2xhaW1lcjxodHRwOi8vd3d3LnRuby5u bC9lbWFpbGRpc2NsYWltZXI+DQoNCg0KW2NpZDozMzFDQjBCQS0zNjRFLTQyRTEtQTJFRC1BQzVC RjNCQjVFM0ZdPGh0dHA6Ly93d3cudG5vLm5sLz4NCg0KDQpUaGlzIG1lc3NhZ2UgbWF5IGNvbnRh aW4gaW5mb3JtYXRpb24gdGhhdCBpcyBub3QgaW50ZW5kZWQgZm9yIHlvdS4gSWYgeW91IGFyZSBu b3QgdGhlIGFkZHJlc3NlZSBvciBpZiB0aGlzIG1lc3NhZ2Ugd2FzIHNlbnQgdG8geW91IGJ5IG1p c3Rha2UsIHlvdSBhcmUgcmVxdWVzdGVkIHRvIGluZm9ybSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhlIG1lc3NhZ2UuIFROTyBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgdGhlIGNvbnRlbnQgb2Yg dGhpcyBlLW1haWwsIGZvciB0aGUgbWFubmVyIGluIHdoaWNoIHlvdSB1c2UgaXQgYW5kIGZvciBk YW1hZ2Ugb2YgYW55IGtpbmQgcmVzdWx0aW5nIGZyb20gdGhlIHJpc2tzIGluaGVyZW50IHRvIHRo ZSBlbGVjdHJvbmljIHRyYW5zbWlzc2lvbiBvZiBtZXNzYWdlcy4K --_000_D5DFE44F6397474C932F62F3D75F44B3tnonl_ Content-Type: text/html; charset="utf-8" Content-ID: <26245DC59004594FB557414FC541A17F@tno.nl> MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBhbGwsPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5EdXJpbmcgdGhlIFdlbGNvbWUgUmVjZXB0aW9u IHBhc3QgU3VuZGF5LCBBbGV4IGFuZCBJIGhhZCBhIGRpc2N1c3Npb24gcmVnYXJkaW5nIHdoYXQg dGhlIGJlbmVmaXRzIHdvdWxkIGJlIGZvciBoYXZpbmcgSVAgYmFzZWQgY29tbXVuaWNhdGlvbiBp biBWMlYgc2NlbmFyaW9zIGFuZCB3aGF0IG90aGVyIHBvc3NpYmlsaXRpZXMgd291bGQgYmUgc3Vp dGFibGUuIE9uZSBvZiB0aGUgY29uY2VwdHMgd2UgZGlzY3Vzc2VkIGlzIHRoZSBjb25jZXB0DQog b2YgSW5mb3JtYXRpb24gQ2VudHJpYyBOZXR3b3JraW5nICg8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL3JnL2ljbnJnL2NoYXJ0ZXIvIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL3JnL2ljbnJnL2NoYXJ0ZXIvPC9hPiksIHdoZXJlIElDTiBmb2N1c2VzIG9uIGZpbmRp bmcgYW5kIGRlbGl2ZXJpbmcgbmFtZWQgY29udGVudHMsIGluc3RlYWQgb2Ygc2V0dGluZy11cCBh bmQgbWFpbnRhaW5pbmcgZW5kLXRvLWVuZCBjb21tdW5pY2F0aW9ucw0KIGJldHdlZW4gaG9zdHMg aWRlbnRpZmllZCBieSBJUCBhZGRyZXNzZXMuIFdoaWNoIHNlZW1zIHZlcnkgcHJvbWlzaW5nLCBh bHNvIGluIG5ldHdvcmtzIHdpdGggZmFzdCBjaGFuZ2luZyB0b3BvbG9naWVzIGxpa2UgVkFORVTi gJlzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVsYXRlZCB0byB0aGlzLCBzb21l IGludGVyZXN0aW5nIHdvcmsgaGFzIGFscmVhZHkgYmVlbiBkb25lIGluIGltcGxlbWVudGluZyBh IHByb3RvdHlwZSBvZiBWZWhpY3VsYXItTkROIGFuZCBwcmVmb3JtaW5nIHNvbWUgaW5pdGlhbCBw ZXJmb3JtYW5jZSBtZWFzdXJlbWVudHMsIHNlZSB0aGUgZm9sbG93aW5nIHBhcGVyOg0KPGEgaHJl Zj0iaHR0cDovL25hbWVkLWRhdGEubmV0L3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDE0LzAzL3ZhbmV0 X3ZpYV9uZG5faW5mb2NvbV9ub20ucGRmIj4NCmh0dHA6Ly9uYW1lZC1kYXRhLm5ldC93cC1jb250 ZW50L3VwbG9hZHMvMjAxNC8wMy92YW5ldF92aWFfbmRuX2luZm9jb21fbm9tLnBkZjwvYT48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoYXQgZG8geW91IHRoaW5rPzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IGlkPSIiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHls ZT0id2lkdGg6IDEyNDVweDsgIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzog MGNtOyAiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3Bh Y2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iNTcwIiBzdHlsZT0i d2lkdGg6IDQyNy41cHQ7ICI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjE3IiB2YWxpZ249 ImJvdHRvbSIgc3R5bGU9IndpZHRoOiAxMi43NXB0OyBwYWRkaW5nOiAwY207ICI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9yOiB3aGl0 ZTsgIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDhwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBz YW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjIwMyIgdmFsaWduPSJib3R0 b20iIHN0eWxlPSJ3aWR0aDogMTUyLjI1cHQ7IHBhZGRpbmc6IDBjbTsgIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IHdoaXRlOyAi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDhwdDsgZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5CLkYuIChCYXN0aWFhbikgV2lzc2lu Z2ggTVNjPGJyPg0KU2NpZW50aXN0IElubm92YXRvcjxicj4NCk1lZGEgYW5kIE5ldHdvcmsgU2Vy dmljZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyMTAiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lk dGg6IDE1Ny41cHQ7IHBhZGRpbmc6IDBjbTsgIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IHdoaXRlOyAiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDhwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl cmlmOyBjb2xvcjogYmxhY2s7Ij5UPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0i d2hpdGUtc3BhY2U6cHJlIj4NCjwvc3Bhbj4tPGJyPg0KTTxzcGFuIGNsYXNzPSJBcHBsZS10YWIt c3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+IDwvc3Bhbj4tPGJyPg0KRTxzcGFuIGNsYXNz PSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+IDwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGNvbG9yOiBibGFjazsgIj48YSBocmVmPSJtYWlsdG86YmFzdGlhYW4ud2lzc2luZ2hAdG5v Lm5sIiBzdHlsZT0iY29sb3I6IHJlZDsgIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiByZ2IoODcsIDE0OSwgMTk1KTsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyAiPmJhc3RpYWFuLndp c3NpbmdoQHRuby5ubDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTQwIiB2YWxpZ249 ImJvdHRvbSIgc3R5bGU9IndpZHRoOiAxMDVwdDsgcGFkZGluZzogMGNtOyAiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBjb2xvcjogd2hpdGU7 ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA4cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fu cy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PGEgaHJlZj0iaHR0cDovL3d3dy50bm8ubmwvbG9jYXRp ZXMvZHRiIiBzdHlsZT0iY29sb3I6IHJlZDsgIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig4Nywg MTQ5LCAxOTUpOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7ICI+TG9jYXRpZTwvc3Bhbj48L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy50bm8ubmwvZW1haWxkaXNjbGFpbWVyIiBzdHlsZT0iY29s b3I6IHJlZDsgIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig4NywgMTQ5LCAxOTUpOyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7ICI+RGlzY2xhaW1lcjwvc3Bhbj48L2E+PGJyPg0KJm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCBjb2xzcGFuPSI0IiBzdHlsZT0icGFkZGluZzogMGNtOyAiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBjb2xvcjogd2hpdGU7ICI+ DQo8YSBocmVmPSJodHRwOi8vd3d3LnRuby5ubC8iIHN0eWxlPSJjb2xvcjogcmVkOyAiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDhwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBj b2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PGltZyBib3JkZXI9IjAiIHdpZHRo PSI1NzAiIGhlaWdodD0iMzYiIGlkPSJfeDAwMDBfaTEwMjciIHNyYz0iY2lkOjMzMUNCMEJBLTM2 NEUtNDJFMS1BMkVELUFDNUJGM0JCNUUzRiIgdHlwZT0iaW1hZ2UvcG5nIj48L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJv ZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpF OiA4cHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGkt Zm9udC1zaXplOiAxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48Zm9udCBzdHls ZT0iRk9OVC1TSVpFOiAxMXB4IiBzaXplPSIzIj4NCjwvZm9udD48cCBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc3R5bGU9IkZPTlQtU0laRTogMTFw eCIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlm JzsgRk9OVC1TSVpFOiA4cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogOC41cHQiPlRoaXMgbWVzc2Fn ZSBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIG5vdCBpbnRlbmRlZCBmb3IgeW91LiBJ ZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9yIGlmIHRoaXMgbWVzc2FnZSB3YXMgc2VudCB0 byB5b3UgYnkgbWlzdGFrZSwgeW91IGFyZSByZXF1ZXN0ZWQgdG8gaW5mb3JtIHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGUgbWVzc2FnZS4gVE5PIGFjY2VwdHMgbm8gbGlhYmlsaXR5IGZvciB0aGUg Y29udGVudCBvZiB0aGlzIGUtbWFpbCwgZm9yIHRoZSBtYW5uZXIgaW4gd2hpY2ggeW91IHVzZSBp dCBhbmQgZm9yIGRhbWFnZSBvZiBhbnkga2luZCByZXN1bHRpbmcgZnJvbSB0aGUgcmlza3MgaW5o ZXJlbnQgdG8gdGhlIGVsZWN0cm9uaWMgdHJhbnNtaXNzaW9uIG9mIG1lc3NhZ2VzLjxicj48YnI+ PC9zcGFuPjwvZm9udD48L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_D5DFE44F6397474C932F62F3D75F44B3tnonl_-- --_004_D5DFE44F6397474C932F62F3D75F44B3tnonl_ Content-Type: image/png; name="53B9F042-076B-4503-8350-7B12BFBD44EA.png" Content-Description: 53B9F042-076B-4503-8350-7B12BFBD44EA.png Content-Disposition: inline; filename="53B9F042-076B-4503-8350-7B12BFBD44EA.png"; size=3214; creation-date="Wed, 04 Nov 2015 01:53:05 GMT"; modification-date="Wed, 04 Nov 2015 01:53:05 GMT" Content-ID: <331CB0BA-364E-42E1-A2ED-AC5BF3BB5E3F> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAjoAAAAkCAYAAACAC5ACAAAMVUlEQVR4Ae2dB2yUVxLHZ8FAaKaH DqYeJZRQ7wgcAtEOML0IJBJKgoLoHVGjREAkOCFA9C44OhxC4gSXUA5kQejdNCHTm+i9vpv/w5/l Xe96veYDlvB/kr37vTdvvvf9VvKO583ME2EjARIgARIgARIgARIgARIgARIgARIgARIgARIgARIg ARIgARIgARIgARIgARIgARIgARIgARIgARIgARIggTAn8Pr1axPqEvfv329WrVoV8rxQ7xNM/sWL F2bFihXm2LFjH30twdYa6nhEqBMoTwIkQAIkQAIfg8CBAwdMx44dXbt1qVKl5IcffpA2bdp4Eiut VauWefDggbx580ZevXolERER0rBhQ5k6daqXnMqYGTNmSExMjJw8eVLSpUsnOXPmNGXLlpXo6Gir O1euXF5zEt8H7xcvXixz58717f4g19OnTzcTJ06Uq1evep49eyadOnWSsWPHfpB78yYkQAIkQAIk QAI+BHbv3g1vg6s/adKkMevXr/fyYmTKlMnvPW7fvm3l1AAy06ZNM3ny5PEr56wxR44cZt68eV66 fR5JcO/hw4dbmZ07d5pdu3aZffv2mUWLFpn79+/b/i1bthh4fnbs2GGWLl1qnj59avuxjs2bN5uF CxeauLg427dhwwYTz0nQt23bNtu/d+9eowaVwTi8N7GxsUYNPBMZGWnWrFljHj58aIYMGWJwL6wR 1/A0wcsDgw59p06dMuvWrTMXL140CxYsMGfPnrX9GGMjARIgARIgARJ4RwJ//PEHvlhd/8GX/enT pxO+tNUz4/ce6vmwMgMHDvQ7HmhtgwYNStDti6BPnz4mffr0drxBgwamcOHCpmDBglZ/69atbX+Z MmVMsWLFTN68eW0/5kDPd999Zw2VJk2amMyZMxvwady4sSlevLgdhxzWOmHCBJMhQwbTrl07AyOu R48eBt4cvIehV6hQIXPlyhWrWz065vHjxwb3LFGihKlWrZpRz5c1un799VcrX7lyZbtm9VaZ58+f 23v5PhevSYAESIAESIAEQiQAr4ZOeS8/X331lXn06JGBlyTQPWAM/PTTTwHHA81Dv25xYV6S5mvo wAv08uVLU7duXWtgYAKMDt0OM4gBKlmypKlXr571quiQGT16tF1zlixZrCED7w76EWtTpEgRs2fP HgNvzsaNG62nCIYL9EFvly5dHK+UxHttDAwd3U6zOuANwnzomzlzpoGhg/fwGP3yyy/2veNJgr5w bWnCdWFcFwmQAAmQAAkkJpA2bdrEl66+P378uPTs2VPUyAio99KlSzJ+/PiA48kNjBgxQq5fvw7j INmm3hXE+njU4LHxQY5wVFSU6PN7smfPbvtVlx1Sr4qoV8aj22hy7do1adWqlaiHSH7++Wf0S40a NUQNROnQoYPodpvotpc8efLEUev31dGt8Uby5ZdfWhnodpp6lwTrQ0MMU7g3BiOH+yfE9ZEACZAA CVgC6qEQ3W4J+kWdWlzLly+XihUrBpw+ZcqUZA0h3R4S3crxO19jXmTOnDl+x1LTWbp0acmaNasc PnxY1ADD1pa0bNkSwdCe5s2bI+5GNPbHGkHYDtPtJpk9e7bX88Eg0jggGEKI20lYhnp97PsjR47Y QGxcVK9e3QZcJwh9Qm/o0fmEPiwulQRIgAQ+ZwLIYDp37pzgS1yDZO1PnTp1/CLJmDGj6HZLglz/ /v39yvl2jho1yrcr4Xrt2rUJ7xO/KV++vDU44C3RQGKBEeKv6faRv+5U9alnxzN//nzR4GLRmBzR rS7RbSyry8lMgxcHTWNz5ODBg1KlShUrq1t0tr9p06ZijBEYNhpgbPvwS2OFPBpXZD1c3bt3l379 +kmLFi2SzR5LmMw3JEACJEACJEAC7hFAnIlqS/KjWzZe20SrV69OIuNvXmr64uNYEh4qPtMpyf0Q R5Mg5NIbxO04WVHJqUSAcXz8kZcYsqtu3brld13I7nIyvLwmfWIX3Lr6xD4wLpcESIAESCA4gfcZ z+N793Llynl1+V47g2psYOvLIAbH6XvXV8TtpESHZmX5ldPtL7/90KlesYBjKblnuMjQ0AmXT4Lr IAESIIFPgMBrzUrS3Q5XGxSmSKd+7aaPSNkXu6sLDKJs06ZNXhK+184gAof9GTmohXP06FG7VYQt KUc+2KsGCJvLly9LpUqV5NChQ4jVwTYViv+h/o0teKip5CnWB4/PKy3u7NEZHv2F17Qa6BxsHeE+ HgF3nr9KiPrAFpK/Bxg2bJh06dpdJm08LS9evvEnwj4SIAEfAvh7MTi6tPzv5C3Zfea2z2jSS/zh d/sbBTr1ayrpzd6hB9rcVJniL70Q1oxndvep3z5zuH8+bn82QN5r3sEQyLsrmvUL9/83z5Ytmw1u Ti7bynkKyCJ417chW2vSpEmoOSOaei19+/b1FbHXVatWFS3I5zWGba769euLprdL586dvcaCXSxb tkyGDh2Kysa2ujJil9BGjhxpM6wQmxNKu3n/uYxdfcJrSs85NqX/rfETP5Im3gjCpWMQwRpC/9u+ t/0J723v23GIOHPsuP7CvN5NSsq/FsywAdPx4q68aBFEibh37x6qHYakEGlr3377rZQtGCm/Hb0R 0lwKk8DnTGDrsZtSu0xu+c/Ba2pwfM4k+OwkEB4EkM6NYyAGDBgQdEHxBk0SOWRUweAI1tq3b+9l 6MDzonV07DQE/xYoUMDWs4FHCKnhzZo1E43r8ejxEubMmTNStGhRQWaXbo0l8bJooUDJly+ffP/9 96h4bIOOe/fuLZpJZrZu3WqNIa2/I5q5lmRusHVjHP/MOH+yvP9ZcnpToiWwzJYj1+0RFAioxnEU brW7d+9KqrKu4CrD+RyNKuWVdOHnRXSLD/WQgOsEdpy4KZkzpJW/ls7lum4qJAESSB0BNXI8TqZS chq6desmuXPnTk4k4JgW+kOBPq9xZD85XpgxY8bg2AWB12fcuHGixflsNhSKGOqxC9bb06hRI1sT x0tJ/AU8RVrtWLQ4oJw4cUIuXLhgvTw//vijraGDjDGkzmv2lTuWib9FvEPf3rN35IvI3ALGbrdU GTpYhJ7JIXAj5onM4PaaqI8E/rQEnulW7+XbT6Vk3ix/2mfkg5HAp0hAz6QSHMaZXEMNH9TagVcl lAb5JUuWYJ6XN0WNJg8KCaLpERSioSSi50eJVje2W0/YbVm5cqUdR5E/eGhQEDC5pgabBzVv9GBS W9wQz4UDSZEmjvVPnjw5uekfbeyVurjP33hk0+TdXkSqDB3srw0ePFiOX3ogV++652Jy++GojwTC jUDR3JmkZL7M8vsxbvmG22fD9XzeBPS8Kw88JwgYDtQQk6VeFQ8MEg0qDiTm1a/ZTqKHY8o333zj ZeR4CcVf+KtIjPgbp+m2lGCdznWwV+y+YM03btywW2ZaC8fW0gk272OM58qaXr4ulkNQlNHtlipD R6suwr3m2aRxBmwkQAIpJ/CPr/PJobj7/Ach5cgoSQLJEkBcSkpaVFRUUDHEvmgGlCDo2F9zgs+1 ArEHFYnhXcE//oGaFt4TrbEDucBCiSZj2woNFYkR1IyGIxychmMeQml6ppXA0AIjbI3FxcWl2EAL 5T5uyDaulE9+/+2/ogeTuqHOS0dE7dq1ZdasWV6dwS7w4a1a+2+z99wd+RtjDYLh4jgJWAJpNeuq clR2OXX1oXT5e1FSCVMC+DJjoHh4fjjpI9LIP32WhuQYZC2hYnLilj9/flsR2OlDRhTiWBDUm7jB g5M420m3fTx37twx27dvtwG8vrLOtVZDtsYLYl5iYmIkNjZWzp8/jyMY7BZYdHS06LELngoVKjhT gr5qpWKPZmyZrl27WlnsnOjJ5J74AzSDzvcVwHEQyKzu1auX6Ino1pvTtm1bCVQlOjJTOulcu4iv mg9yXesvuSTmZoaQ7ZFgi6tZs2YwEY6TAAmQAAmQAAl8SAIaj2OQkeXWPVEfR7OPXNPn1rqohwRI gARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARI gARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARI gARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARI4D0R +D8jpEQGCAmZ7QAAAABJRU5ErkJggg== --_004_D5DFE44F6397474C932F62F3D75F44B3tnonl_-- From nobody Wed Nov 4 01:23:12 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 DF9CB1B2BCA for ; Wed, 4 Nov 2015 01:23:02 -0800 (PST) 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=unavailable 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 mIfvBlmwzCrP for ; Wed, 4 Nov 2015 01:22:50 -0800 (PST) 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 EFACA1B2BC8 for ; Wed, 4 Nov 2015 01:22:49 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id tA49Ml3B014721; Wed, 4 Nov 2015 10:22:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DF2AD205B7B; Wed, 4 Nov 2015 10:28:46 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D1A04202431; Wed, 4 Nov 2015 10:28:46 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.151]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id tA49MgND025325; Wed, 4 Nov 2015 10:22:46 +0100 To: its@ietf.org References: <56370B24.1050000@gmail.com> From: Alexandre Petrescu Message-ID: <5639CE62.1030308@gmail.com> Date: Wed, 4 Nov 2015 18:22:42 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56370B24.1050000@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "George, Wes" Subject: Re: [its] Fwd: comments on vehicular communication drafts X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 09:23:03 -0000 Hi, and thanks for reading through the documents. Let me reply to some aspects. > -------- Message transféré -------- Sujet : comments on vehicular > communication drafts Date : Sun, 1 Nov 2015 13:08:47 +0000 De : > George, Wes Pour : > draft-ietf-ecrit-ecall@ietf.org , > draft-ietf-ecrit-car-crash@ietf.org > , > draft-petrescu-its-problem@ietf.org > , > draft-petrescu-its-cacc-sdo@ietf.org > > > Either way (text quoted from the eCall draft) this gave me pause: O > The ability to handle text o The ability for the PSAP to access > vehicle components (e.g., an onboard camera (such as rear facing or > blind-spot cameras) for a visual assessment of the crash site > situation) o The ability for the PSAP to request the vehicle to take > actions (e.g., sound the horn, disable the ignition, lock/unlock > doors) [PSAP: Public Safety Answering Point, might be an emergency center] > The security considerations sections need bolstering in light of > recent revelations around the vulnerability of many CANBUS vehicles > for attacks via their existing cellular/data connections. I agree. > The ability to handle text brings with it the ability to trigger > buffer overruns and other exploits, and so there should be specific > discussion about input validation and protection against this attack > vector. Accessing and manipulating vehicle components especially > critical systems is enough of a privacy and safety concern that there > should be more specific text about how to prevent unauthorized > access. I think this starts with removing this (IMO) faulty > assertion: "emergency call placed over a cellular network, there is a > higher degree of trust that the source is indeed a PSAP" and > replacing it with something that reinforces the "trust but verify" > model, since the cellular network, while marginally more secure, is > subject to call interception and manipulation from a suitably > motivated and equipped actor, just like any other network. (google > Stingray, for example) This section should also discuss, in detail, > what is an acceptable level of security for the certificate to > validate that the PSAP is authorized to send these sorts of commands, > whether in call-back or in initial call, whether the payload data > MUST/SHOULD be encrypted on the path to prevent > interception/manipulation, and usual certificate based best practices > such as mandatory to implement (or mandatory to avoid due to proven > insecurity) algorithms, best practices for keyrolls, cert revocation, > etc. as well as probably some text about general security best > practices (remote software updates, third-party pentesting, airgaps, > signed software, etc). There's no reason to reinvent this, but you > need to reference existing IETF standards defining this for e.g. TLS, > PKI, etc. and adapt where appropriate. Yes, the tools available at IETF should be referenced, such as the basic IPsec, TLS tools, and PKI concepts. > Automakers have demonstrated on multiple occasions that they either > don't understand these aspects of security in the connected car or > don't understand why it's important, (e.g BMW not using HTTPS) so > erring on the side of too much info is IMO the right model, because > we have no reason to believe that the other SDOs involved in this > effort will possess the standards and expertise, nor motivation to > document it properly. Work was performed recently to adapt TLS to vehicular-specific certificates such as defined by IEEE and ETSI ITS: draft-lonc-tls-certieee1609-01.txt This was presented in a TLS session in Prague. Is there any other vehicular security specific work at IETF? Other vehicular related SDOs such as ISO TC204 start as we speak to consider the use of such tools, refraining from defining new ones. > In the case of the Petrescu drafts, explicit language identifying > the system as read-only would probably limit the exposure to some of > the concerns I raised above specific to manipulating important > systems as described in the eCall drafts, Sorry, what do you mean by identifying the system as read-only? In the V2V use-cases such as CACC/Platooning we have an effort ongoing to understand the relationship with V2I. Namely, how should the IP path establishment tools of V2V be involved when communicating with the immediate infrastructure, how should the downwards path from the Internet be considered. In some prototype demonstrators the V2V protocol paths are commpletely independent of the V2Internet paths (e.g. two different disconnected boxes in the car, one in charge of V2V other for V2I). The V2I boxes do run TLS with certificates. And, specific vehicular industry activities consider seriously the establishment of a "vehicular PKI" which is independent of the typical Internet PKI, with some prototype demonstrators in Europe. This raises several questions: 1. Can two boxes in a car be disconnected from each other? 2. How should the V2V tools be used to communicate with the immediate fixed infrastructure? 3. Can an independent PKI be used specifically for vehicles? > but ultimately due to the interconnectedness of these systems within > the vehicle and these drafts, it might make more sense to assume that > this opens a new attack vector to pivot through systems via V2V > communications, and discuss ways to harden the overall system > accordingly. I agree. Given one hacked car, if it is V2V-connected to other cars it leads to an amplified risk. > I am by no means a security expert, so I'm sure that there's more > I'm missing. It may be useful to ask for an early security > directorate review for this set of drafts, or even to ask the > Security ADs to suggest one or more security folks that you can ask > to assist in fleshing out the security considerations. I will ask this around. > You're also missing an opportunity to suggest that if this uses IP > networking, that it MUST support IPv6, given the number of devices > expected to be present, the timeline for deployment, etc. For the ITS problem statement we do assume IPv6 whenever we write IP. In the Charter proposal I think we mean the current generation of Internet Protocols is IPv6. But, one must know that in the current advanced IP-connected cars and prototypes IPv4 is considered first. In vehicles where IP has not yet arrived, IPv4 is already very advanced. Some car manufacturers depend on large fixed infrastructure (datacenters) which is IPv4 only. The immediate infra near the car - the intelligent road - may be more IPv6 though. There is a significant amount of work to do to talk IPv6 concepts (as opposed of IPv4) to car manufacturers. Some times it may be easier to propose just IP, regardless of the version. The word "IPv6" has so much of other aspects attached to it that are irrelevant to some vehicle manufacturers. > While that is not necessarily critical to the function of the > protocol itself, it definitely bears mentioning as acknowledging the > reality of applications that want to add hundreds of thousands of IP > nodes to the mobile data network in the era of exhausted IPv4. I fully agree, this is a good point. In some countries IPv6 is largely available through the cellular operators, which is an essential link for cars. In other countries this is far from happening. And cars target markets on a per-country basis, as opposed to smartphones for example which are much more able to cross borders. For example, I am wondering whether onstar and ecall migration to IPv6 is being considered somewhere. This will be a large effort I think. Alex > > > Thanks, > > > > Wes George > > Anything below this line has been added by my company’s mail server, > I have no control over it. ----------- > > > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or > subject to copyright belonging to Time Warner Cable. This E-mail is > intended solely for the use of the individual or entity to which it > is addressed. If you are not the intended recipient of this E-mail, > you are hereby notified that any dissemination, distribution, > copying, or action taken in relation to the contents of and > attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > > > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Wed Nov 4 05:29:13 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 B7D091B2F47 for ; Wed, 4 Nov 2015 05:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 iC4eN5Yn22-1 for ; Wed, 4 Nov 2015 05:29:09 -0800 (PST) Received: from ndmsvnpf103.ndc.nasa.gov (NDMSVNPF103.ndc.nasa.gov [198.117.0.153]) by ietfa.amsl.com (Postfix) with ESMTP id 09F2B1B2F45 for ; Wed, 4 Nov 2015 05:29:09 -0800 (PST) Received: from ndjsppt102.ndc.nasa.gov (ndjsppt102.ndc.nasa.gov [198.117.1.196]) by ndmsvnpf103.ndc.nasa.gov (Postfix) with ESMTP id 59EB14037E4E; Wed, 4 Nov 2015 07:29:08 -0600 (CST) Received: from NDJSCHT115.ndc.nasa.gov (ndjscht115-pub.ndc.nasa.gov [198.117.1.215]) by ndjsppt102.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id tA4DT8UZ026766; Wed, 4 Nov 2015 07:29:08 -0600 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.84]) by NDJSCHT115.ndc.nasa.gov ([198.117.1.215]) with mapi id 14.03.0248.002; Wed, 4 Nov 2015 07:29:08 -0600 From: "Ivancic, William D. (GRC-LCA0)" To: "Wissingh, B.F. (Bastiaan)" , "its@ietf.org" Thread-Topic: [its] How about using ICN? Thread-Index: AQHRFwTIO+d48bM+o0qd/Gpzly1fiQ== Date: Wed, 4 Nov 2015 13:29:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.6.150930 x-originating-ip: [139.88.7.142] Content-Type: multipart/mixed; boundary="_004_D25F727A3790Cwilliamdivancicnasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-11-04_08:, , signatures=0 Archived-At: Subject: Re: [its] How about using ICN? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 13:29:11 -0000 --_004_D25F727A3790Cwilliamdivancicnasagov_ Content-Type: multipart/alternative; boundary="_000_D25F727A3790Cwilliamdivancicnasagov_" --_000_D25F727A3790Cwilliamdivancicnasagov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I absolutely agree. V2V is highly likely to be publish/subscribe and ICN f= its that very well and, if done properly, handles multi-homed, mobile commu= nications and, to some extent, intermittent connections. Will From: its > on behalf of = "Wissingh, B.F. (Bastiaan)" > Date: Tuesday, November 3, 2015 8:53 PM To: "its@ietf.org" > Subject: [its] How about using ICN? Hi all, During the Welcome Reception past Sunday, Alex and I had a discussion regar= ding what the benefits would be for having IP based communication in V2V sc= enarios and what other possibilities would be suitable. One of the concepts= we discussed is the concept of Information Centric Networking (https://dat= atracker.ietf.org/rg/icnrg/charter/), where ICN focuses on finding and deli= vering named contents, instead of setting-up and maintaining end-to-end com= munications between hosts identified by IP addresses. Which seems very prom= ising, also in networks with fast changing topologies like VANET=92s. Related to this, some interesting work has already been done in implementin= g a prototype of Vehicular-NDN and preforming some initial performance meas= urements, see the following paper: http://named-data.net/wp-content/uploads= /2014/03/vanet_via_ndn_infocom_nom.pdf What do you think? Best regards, B.F. (Bastiaan) Wissingh MSc Scientist Innovator Meda and Network Services T- M - E bastiaan.wissingh@tno.nl Locatie Disclaimer [cid:331CB0BA-364E-42E1-A2ED-AC5BF3BB5E3F] This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. --_000_D25F727A3790Cwilliamdivancicnasagov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <304E0C0C6AE18D4A947BAE8A57388ED1@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable
I absolutely agree.  V2V is highly likely to be publish/subscribe= and ICN fits that very well and, if done properly, handles multi-homed, mo= bile communications and, to some extent, intermittent connections.

Will

From: its <its-bounces@ietf.org> on behalf of "Wissingh= , B.F. (Bastiaan)" <bas= tiaan.wissingh@tno.nl>
Date: Tuesday, November 3, 2015 8:5= 3 PM
To: "its@ietf.org" <its@ietf.= org>
Subject: [its] How about using ICN?=

Hi all,

During the Welcome Reception past Sunday, Alex and I had a discussion = regarding what the benefits would be for having IP based communication in V= 2V scenarios and what other possibilities would be suitable. One of the con= cepts we discussed is the concept of Information Centric Networking (https://datatracker.ietf.org/rg/icnrg/charter/), wh= ere ICN focuses on finding and delivering named contents, instead of settin= g-up and maintaining end-to-end communications between hosts identified by IP addresses. Which seems very promising, also= in networks with fast changing topologies like VANET=92s.

Related to this, some interesting work has already been done in implem= enting a prototype of Vehicular-NDN and preforming some initial performance= measurements, see the following paper: http://named-data.net/wp-content/uploads/2014/03/vanet_via_ndn_infocom_nom.= pdf

What do you think?

Best regards,

 

 B.F. (Bastiaan) Wissingh MSc
Scientist Innovator
Meda and Network Services

 T-
M -
E = bastiaan.wissingh@tno.nl

Locatie=
Disclaimer
 

 

This message may contain information that is not intended for yo= u. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender= and delete the message. TNO accepts no liability for the content of this e= -mail, for the manner in which you use it and for damage of any kind result= ing from the risks inherent to the electronic transmission of messages.

--_000_D25F727A3790Cwilliamdivancicnasagov_-- --_004_D25F727A3790Cwilliamdivancicnasagov_ Content-Type: image/png; name="53B9F042-076B-4503-8350-7B12BFBD44EA.png" Content-Description: 53B9F042-076B-4503-8350-7B12BFBD44EA.png Content-Disposition: attachment; filename="53B9F042-076B-4503-8350-7B12BFBD44EA.png"; size=3214; creation-date="Wed, 04 Nov 2015 13:29:07 GMT"; modification-date="Wed, 04 Nov 2015 13:29:07 GMT" Content-ID: <331CB0BA-364E-42E1-A2ED-AC5BF3BB5E3F> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAjoAAAAkCAYAAACAC5ACAAAMVUlEQVR4Ae2dB2yUVxLHZ8FAaKaH DqYeJZRQ7wgcAtEOML0IJBJKgoLoHVGjREAkOCFA9C44OhxC4gSXUA5kQejdNCHTm+i9vpv/w5/l Xe96veYDlvB/kr37vTdvvvf9VvKO583ME2EjARIgARIgARIgARIgARIgARIgARIgARIgARIgARIg ARIgARIgARIgARIgARIgARIgARIgARIgARIgARIggTAn8Pr1axPqEvfv329WrVoV8rxQ7xNM/sWL F2bFihXm2LFjH30twdYa6nhEqBMoTwIkQAIkQAIfg8CBAwdMx44dXbt1qVKl5IcffpA2bdp4Eiut VauWefDggbx580ZevXolERER0rBhQ5k6daqXnMqYGTNmSExMjJw8eVLSpUsnOXPmNGXLlpXo6Gir O1euXF5zEt8H7xcvXixz58717f4g19OnTzcTJ06Uq1evep49eyadOnWSsWPHfpB78yYkQAIkQAIk QAI+BHbv3g1vg6s/adKkMevXr/fyYmTKlMnvPW7fvm3l1AAy06ZNM3ny5PEr56wxR44cZt68eV66 fR5JcO/hw4dbmZ07d5pdu3aZffv2mUWLFpn79+/b/i1bthh4fnbs2GGWLl1qnj59avuxjs2bN5uF CxeauLg427dhwwYTz0nQt23bNtu/d+9eowaVwTi8N7GxsUYNPBMZGWnWrFljHj58aIYMGWJwL6wR 1/A0wcsDgw59p06dMuvWrTMXL140CxYsMGfPnrX9GGMjARIgARIgARJ4RwJ//PEHvlhd/8GX/enT pxO+tNUz4/ce6vmwMgMHDvQ7HmhtgwYNStDti6BPnz4mffr0drxBgwamcOHCpmDBglZ/69atbX+Z MmVMsWLFTN68eW0/5kDPd999Zw2VJk2amMyZMxvwady4sSlevLgdhxzWOmHCBJMhQwbTrl07AyOu R48eBt4cvIehV6hQIXPlyhWrWz065vHjxwb3LFGihKlWrZpRz5c1un799VcrX7lyZbtm9VaZ58+f 23v5PhevSYAESIAESIAEQiQAr4ZOeS8/X331lXn06JGBlyTQPWAM/PTTTwHHA81Dv25xYV6S5mvo wAv08uVLU7duXWtgYAKMDt0OM4gBKlmypKlXr571quiQGT16tF1zlixZrCED7w76EWtTpEgRs2fP HgNvzsaNG62nCIYL9EFvly5dHK+UxHttDAwd3U6zOuANwnzomzlzpoGhg/fwGP3yyy/2veNJgr5w bWnCdWFcFwmQAAmQAAkkJpA2bdrEl66+P378uPTs2VPUyAio99KlSzJ+/PiA48kNjBgxQq5fvw7j INmm3hXE+njU4LHxQY5wVFSU6PN7smfPbvtVlx1Sr4qoV8aj22hy7do1adWqlaiHSH7++Wf0S40a NUQNROnQoYPodpvotpc8efLEUev31dGt8Uby5ZdfWhnodpp6lwTrQ0MMU7g3BiOH+yfE9ZEACZAA CVgC6qEQ3W4J+kWdWlzLly+XihUrBpw+ZcqUZA0h3R4S3crxO19jXmTOnDl+x1LTWbp0acmaNasc PnxY1ADD1pa0bNkSwdCe5s2bI+5GNPbHGkHYDtPtJpk9e7bX88Eg0jggGEKI20lYhnp97PsjR47Y QGxcVK9e3QZcJwh9Qm/o0fmEPiwulQRIgAQ+ZwLIYDp37pzgS1yDZO1PnTp1/CLJmDGj6HZLglz/ /v39yvl2jho1yrcr4Xrt2rUJ7xO/KV++vDU44C3RQGKBEeKv6faRv+5U9alnxzN//nzR4GLRmBzR rS7RbSyry8lMgxcHTWNz5ODBg1KlShUrq1t0tr9p06ZijBEYNhpgbPvwS2OFPBpXZD1c3bt3l379 +kmLFi2SzR5LmMw3JEACJEACJEAC7hFAnIlqS/KjWzZe20SrV69OIuNvXmr64uNYEh4qPtMpyf0Q R5Mg5NIbxO04WVHJqUSAcXz8kZcYsqtu3brld13I7nIyvLwmfWIX3Lr6xD4wLpcESIAESCA4gfcZ z+N793Llynl1+V47g2psYOvLIAbH6XvXV8TtpESHZmX5ldPtL7/90KlesYBjKblnuMjQ0AmXT4Lr IAESIIFPgMBrzUrS3Q5XGxSmSKd+7aaPSNkXu6sLDKJs06ZNXhK+184gAof9GTmohXP06FG7VYQt KUc+2KsGCJvLly9LpUqV5NChQ4jVwTYViv+h/o0teKip5CnWB4/PKy3u7NEZHv2F17Qa6BxsHeE+ HgF3nr9KiPrAFpK/Bxg2bJh06dpdJm08LS9evvEnwj4SIAEfAvh7MTi6tPzv5C3Zfea2z2jSS/zh d/sbBTr1ayrpzd6hB9rcVJniL70Q1oxndvep3z5zuH8+bn82QN5r3sEQyLsrmvUL9/83z5Ytmw1u Ti7bynkKyCJ417chW2vSpEmoOSOaei19+/b1FbHXVatWFS3I5zWGba769euLprdL586dvcaCXSxb tkyGDh2Kysa2ujJil9BGjhxpM6wQmxNKu3n/uYxdfcJrSs85NqX/rfETP5Im3gjCpWMQwRpC/9u+ t/0J723v23GIOHPsuP7CvN5NSsq/FsywAdPx4q68aBFEibh37x6qHYakEGlr3377rZQtGCm/Hb0R 0lwKk8DnTGDrsZtSu0xu+c/Ba2pwfM4k+OwkEB4EkM6NYyAGDBgQdEHxBk0SOWRUweAI1tq3b+9l 6MDzonV07DQE/xYoUMDWs4FHCKnhzZo1E43r8ejxEubMmTNStGhRQWaXbo0l8bJooUDJly+ffP/9 96h4bIOOe/fuLZpJZrZu3WqNIa2/I5q5lmRusHVjHP/MOH+yvP9ZcnpToiWwzJYj1+0RFAioxnEU brW7d+9KqrKu4CrD+RyNKuWVdOHnRXSLD/WQgOsEdpy4KZkzpJW/ls7lum4qJAESSB0BNXI8TqZS chq6desmuXPnTk4k4JgW+kOBPq9xZD85XpgxY8bg2AWB12fcuHGixflsNhSKGOqxC9bb06hRI1sT x0tJ/AU8RVrtWLQ4oJw4cUIuXLhgvTw//vijraGDjDGkzmv2lTuWib9FvEPf3rN35IvI3ALGbrdU GTpYhJ7JIXAj5onM4PaaqI8E/rQEnulW7+XbT6Vk3ix/2mfkg5HAp0hAz6QSHMaZXEMNH9TagVcl lAb5JUuWYJ6XN0WNJg8KCaLpERSioSSi50eJVje2W0/YbVm5cqUdR5E/eGhQEDC5pgabBzVv9GBS W9wQz4UDSZEmjvVPnjw5uekfbeyVurjP33hk0+TdXkSqDB3srw0ePFiOX3ogV++652Jy++GojwTC jUDR3JmkZL7M8vsxbvmG22fD9XzeBPS8Kw88JwgYDtQQk6VeFQ8MEg0qDiTm1a/ZTqKHY8o333zj ZeR4CcVf+KtIjPgbp+m2lGCdznWwV+y+YM03btywW2ZaC8fW0gk272OM58qaXr4ulkNQlNHtlipD R6suwr3m2aRxBmwkQAIpJ/CPr/PJobj7/Ach5cgoSQLJEkBcSkpaVFRUUDHEvmgGlCDo2F9zgs+1 ArEHFYnhXcE//oGaFt4TrbEDucBCiSZj2woNFYkR1IyGIxychmMeQml6ppXA0AIjbI3FxcWl2EAL 5T5uyDaulE9+/+2/ogeTuqHOS0dE7dq1ZdasWV6dwS7w4a1a+2+z99wd+RtjDYLh4jgJWAJpNeuq clR2OXX1oXT5e1FSCVMC+DJjoHh4fjjpI9LIP32WhuQYZC2hYnLilj9/flsR2OlDRhTiWBDUm7jB g5M420m3fTx37twx27dvtwG8vrLOtVZDtsYLYl5iYmIkNjZWzp8/jyMY7BZYdHS06LELngoVKjhT gr5qpWKPZmyZrl27WlnsnOjJ5J74AzSDzvcVwHEQyKzu1auX6Ino1pvTtm1bCVQlOjJTOulcu4iv mg9yXesvuSTmZoaQ7ZFgi6tZs2YwEY6TAAmQAAmQAAl8SAIaj2OQkeXWPVEfR7OPXNPn1rqohwRI gARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARI gARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARI gARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARIgARI4D0R +D8jpEQGCAmZ7QAAAABJRU5ErkJggg== --_004_D25F727A3790Cwilliamdivancicnasagov_-- From nobody Wed Nov 4 18:08:17 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 6358D1B365C for ; Wed, 4 Nov 2015 17:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 5cIXFOttj40g for ; Wed, 4 Nov 2015 17:51:51 -0800 (PST) Received: from cdcipgw02.twcable.com (unknown [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 69FF31B365A for ; Wed, 4 Nov 2015 17:51:51 -0800 (PST) X-SENDER-IP: 10.64.163.147 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.20,245,1444708800"; d="scan'208";a="402177858" Received: from unknown (HELO exchpapp06.corp.twcable.com) ([10.64.163.147]) by cdcipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 04 Nov 2015 20:21:52 -0500 Received: from EXCHPAPP06.corp.twcable.com (10.64.163.147) by exchpapp06.corp.twcable.com (10.64.163.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 20:51:43 -0500 Received: from EXCHPAPP06.corp.twcable.com ([10.64.163.147]) by exchpapp06.corp.twcable.com ([10.64.163.147]) with mapi id 15.00.1104.000; Wed, 4 Nov 2015 20:51:43 -0500 From: "George, Wes" To: Alexandre Petrescu , "its@ietf.org" Thread-Topic: [its] Fwd: comments on vehicular communication drafts Thread-Index: AQHRFKZxT7ivrsrTc0m+Es1Gi0Ydw56IpCIAgANLGQCAAK+8gA== Date: Thu, 5 Nov 2015 01:51:42 +0000 Message-ID: References: <56370B24.1050000@gmail.com> <5639CE62.1030308@gmail.com> In-Reply-To: <5639CE62.1030308@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-21922.002 x-tm-as-result: No--44.884200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 04 Nov 2015 18:08:16 -0800 Subject: Re: [its] Fwd: comments on vehicular communication drafts X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 01:51:53 -0000 VGhhbmtzIGZvciB0aGUgcmVzcG9uc2UNCg0KDQoNCk9uIDExLzQvMTUsIDQ6MjIgQU0sICJBbGV4 YW5kcmUgUGV0cmVzY3UiIDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPg0Kd3JvdGU6DQoN Cj4+IEluIHRoZSBjYXNlIG9mIHRoZSBQZXRyZXNjdSBkcmFmdHMsIGV4cGxpY2l0IGxhbmd1YWdl IGlkZW50aWZ5aW5nDQo+PiB0aGUgc3lzdGVtIGFzIHJlYWQtb25seSB3b3VsZCBwcm9iYWJseSBs aW1pdCB0aGUgZXhwb3N1cmUgdG8gc29tZSBvZg0KPj4gdGhlIGNvbmNlcm5zIEkgcmFpc2VkIGFi b3ZlIHNwZWNpZmljIHRvIG1hbmlwdWxhdGluZyBpbXBvcnRhbnQNCj4+IHN5c3RlbXMgYXMgZGVz Y3JpYmVkIGluIHRoZSBlQ2FsbCBkcmFmdHMsDQo+DQo+U29ycnksIHdoYXQgZG8geW91IG1lYW4g YnkgaWRlbnRpZnlpbmcgdGhlIHN5c3RlbSBhcyByZWFkLW9ubHk/DQoNCldHXSBzb3JyeSBJIHdh cyB1bmNsZWFyLSB3aGF0IEkgbWVhbiBpcyB0aGF0IHRoZSBWMlYgY29tbXVuaWNhdGlvbnMgYXJl DQpsYXJnZWx5IGluZm9ybWF0aW9uYWwgKHBvc2l0aW9ucywgb2JzdGFjbGVzLCBldGMpLCBhbmQg YXJlIG5vdCBpbnRlbmRlZCB0bw0KYmUgYWJsZSB0byBkbyBhbnkgc29ydCBvZiBjb250cm9sIG9m IHRoZSB2ZWhpY2xlJ3Mgc3lzdGVtcywgc28gaXQgd291bGQgYmUNCmFwcHJvcHJpYXRlIHRvIG1h a2UgdGhpcyByZWxhdGlvbnNoaXAgYW5kIHJlc3RyaWN0aW9uIGV4cGxpY2l0LCBiZWNhdXNlIGl0 DQp3b3VsZCBtZWFuIHRoYXQgdGhlIGdhdGV3YXkgYmV0d2VlbiBWMlYgYW5kIHRoZSByZXN0IG9m IHRoZSB2ZWhpY2xlIHdvdWxkDQpuZXZlciBzZWUgaW5ib3VuZCBhdHRlbXB0cyB0byBjb21tdW5p Y2F0ZSB0aHJvdWdoIHRoYXQgZ2F0ZXdheSB0byBvdGhlcg0KcGFydHMgb2YgdGhlIGNhci4gSXQg d291bGQgdGFrZSBpbiB3aGF0ZXZlciBpbmZvcm1hdGlvbiBpdCBuZWVkcyBmcm9tDQpvdGhlciB2 ZWhpY2xlcywgYW5hbHl6ZSBpdCwgYW5kIHBhc3MgaXQgdG8gdGhlIG1vcmUgdHJ1c3RlZCBwYXJ0 cyBvZiB0aGUNCmNhciB2aWEgYSB2ZXJ5IGNsZWFybHkgZGVmaW5lZCBtZXRob2QgKHZzIGEgbW9y ZSBvcGVuIG1vZGVsIHdoZXJlIHRoYXQNCm5lYXIgYWlyLWdhcCBkb2Vzbid0IGV4aXN0IGJldHdl ZW4gdGhlIHN5c3RlbXMpLiBTb3VuZHMgbGlrZSBmcm9tIHRoZQ0KYmVsb3cgdGhhdCB5b3UncmUg YWxyZWFkeSB0aGlua2luZyBhbG9uZyB0aG9zZSBsaW5lcy4NCg0KPg0KPkluIHRoZSBWMlYgdXNl LWNhc2VzIHN1Y2ggYXMgQ0FDQy9QbGF0b29uaW5nIHdlIGhhdmUgYW4gZWZmb3J0IG9uZ29pbmcN Cj50byB1bmRlcnN0YW5kIHRoZSByZWxhdGlvbnNoaXAgd2l0aCBWMkkuICBOYW1lbHksIGhvdyBz aG91bGQgdGhlIElQIHBhdGgNCj5lc3RhYmxpc2htZW50IHRvb2xzIG9mIFYyViBiZSBpbnZvbHZl ZCB3aGVuIGNvbW11bmljYXRpbmcgd2l0aCB0aGUNCj5pbW1lZGlhdGUgaW5mcmFzdHJ1Y3R1cmUs IGhvdyBzaG91bGQgdGhlIGRvd253YXJkcyBwYXRoIGZyb20gdGhlDQo+SW50ZXJuZXQgYmUgY29u c2lkZXJlZC4NCg0KW3NuaXBdDQo+DQo+SW4gc29tZSBjb3VudHJpZXMgSVB2NiBpcyBsYXJnZWx5 IGF2YWlsYWJsZSB0aHJvdWdoIHRoZSBjZWxsdWxhcg0KPm9wZXJhdG9ycywgd2hpY2ggaXMgYW4g ZXNzZW50aWFsIGxpbmsgZm9yIGNhcnMuICBJbiBvdGhlciBjb3VudHJpZXMgdGhpcw0KPmlzIGZh ciBmcm9tIGhhcHBlbmluZy4gIEFuZCBjYXJzIHRhcmdldCBtYXJrZXRzIG9uIGEgcGVyLWNvdW50 cnkgYmFzaXMsDQo+YXMgb3Bwb3NlZCB0byBzbWFydHBob25lcyBmb3IgZXhhbXBsZSB3aGljaCBh cmUgbXVjaCBtb3JlIGFibGUgdG8gY3Jvc3MNCj5ib3JkZXJzLg0KPg0KPkZvciBleGFtcGxlLCBJ IGFtIHdvbmRlcmluZyB3aGV0aGVyIG9uc3RhciBhbmQgZWNhbGwgbWlncmF0aW9uIHRvIElQdjYN Cj5pcyBiZWluZyBjb25zaWRlcmVkIHNvbWV3aGVyZS4gIFRoaXMgd2lsbCBiZSBhIGxhcmdlIGVm Zm9ydCBJIHRoaW5rLg0KDQpXR10gdGhpcyBpcyBhIGdvb2QgcG9pbnQgdG8gYWRkcmVzcywgYnV0 IHJlYWxseSBpdCdzIGp1c3QgYSB2YXJpYW50IG9mIHRoZQ0KY2F0Y2gtMjIgd2UndmUgYmVlbiBk ZWFsaW5nIHdpdGggZm9yIHllYXJzIHdoZW4gaXQgY29tZXMgdG8gSVB2Ng0KZGVwbG95bWVudCAt IHdlIGNhbid0IHJlcXVpcmUgSVB2NiBvciBkZXZlbG9wIElQdjYtb25seSBmZWF0dXJlcyBiZWNh dXNlDQpub3QgZXZlcnlvbmUgc3VwcG9ydHMgaXQvbm90IGV2ZXJ5b25lIHN1cHBvcnRzIGl0IGJl Y2F1c2UgdGhlcmUgaXMgbm90IGENCmNvbnNpc3RlbnQsIG5vbi1uZWdvdGlhYmxlIHJlcXVpcmVt ZW50IGZvciBpdC4gR2l2ZW4gdGhhdCB0aGlzIGlzIGxpa2VseQ0KdG8gYmUgc29tZXRoaW5nIHRo YXQgY2FycmllcyB0aGUgZm9yY2UgYW5kIHdlaWdodCBvZiBzZXZlcmFsIGxhcmdlDQpnb3Zlcm5t ZW50cyBiZWhpbmQgaXQsIGl0IGlzIGEgZ29vZCBsZXZlciB0byBwdWxsIGFzIGEgZm9yY2luZyBm dW5jdGlvbiB0bw0KZW5zdXJlIHRoYXQgdGhlIG1vYmlsZSBvcGVyYXRvcnMgc3VwcG9ydCBJUHY2 IGNvbnNpc3RlbnRseSAoaW5jbHVkaW5nDQpyb2FtaW5nKSBhbmQgdGhhdCB0aGUgaW5mcmFzdHJ1 Y3R1cmUgaXMgZGVzaWduZWQgd2l0aCBJUHY2IGluIG1pbmQgZnJvbQ0KdGhlIGdldC1nbywgdGFr aW5nIGEgc3RlcCBhd2F5IGZyb20gdGhlIGxlZ2FjeSBiYWdnYWdlIHRoYXQgY29tZXMgd2l0aA0K b2xkZXIgc3lzdGVtcy4gQXV0b21ha2VycyBhbmQgZ292ZXJubWVudHMgd2lsbCBib3RoIGJlIGFw cGx5aW5nIHByZXNzdXJlDQpvbiB0aGUgU1BzIGFuZCB0aGVpciBzdXBwbGllcnMgdG8gZW5zdXJl IGNvbXBsaWFuY2UsIGFuZCBhcyB0aGF0IHN0YXJ0cw0KYmVpbmcgYSByZWFsaXR5IGluIG1ham9y IG1hcmtldHMsIGl0IHN0YXJ0cyBiZWNvbWluZyBtb3JlIGxpa2VseSB0byBiZQ0KdGhlcmUgaW4g c2Vjb25kYXJ5IG1hcmtldHMgYmVjYXVzZSB0aGUgaGVhdnkgbGlmdGluZyBpcyBhbHJlYWR5IGRv bmUuDQoNClRoYW5rcw0KDQpXZXMNCg0KQW55dGhpbmcgYmVsb3cgdGhpcyBsaW5lIGhhcyBiZWVu IGFkZGVkIGJ5IG15IGNvbXBhbnnigJlzIG1haWwgc2VydmVyLCBJDQpoYXZlIG5vIGNvbnRyb2wg b3ZlciBpdC4NCi0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g VGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZp bGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRv IFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3Nl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRz IG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk IGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVu dGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBh bnkgcHJpbnRvdXQuDQo= From nobody Mon Nov 9 02:09: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 A2DD61B7BCB for ; Mon, 9 Nov 2015 02:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 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, HTML_MESSAGE=0.001, 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 KzEHXDNHfW2k for ; Mon, 9 Nov 2015 02:09:45 -0800 (PST) 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 677091B7BC5 for ; Mon, 9 Nov 2015 02:09:45 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id tA9A9hhV028667 for ; Mon, 9 Nov 2015 11:09:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6E9D22041F7 for ; Mon, 9 Nov 2015 11:15:49 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 64ACD2041E7 for ; Mon, 9 Nov 2015 11:15:49 +0100 (CET) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id tA9A9ftV030204 for ; Mon, 9 Nov 2015 11:09:43 +0100 From: Alexandre Petrescu To: "its@ietf.org" Message-ID: <564070E5.2030500@gmail.com> Date: Mon, 9 Nov 2015 11:09:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050703090905040406000701" Archived-At: Subject: [its] minutes of Yokohama ITS bar bof and other informal meetings X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 10:09:47 -0000 This is a multi-part message in MIME format. --------------050703090905040406000701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [re-sent] Hi ITSers, With Dapeng we met in Yokohama with our IAB advisors. We discussed ways forward for an ITS activity at IETF. Much of the discussion revolved around the topic of motivating the use of IP protocols for vehicular communications; different arguments pro and con were made (about link heterogeneity, latency), while all at the same time tryng to answer the question of why do the work at IETF. We briefly mentioned the kinds of solutions that have been mentioned until now in this space (MIP, ND, AODV and most recently ICN). Security mechanisms are necessary in this context, especially after the recent attacks on connected cars, reported largely in the media. A question was made about which layer of the protocols suffered in these attacks, not clear whether it was IP or other. A particular topic was the relationship with SDOs, in particular with ISO TC204. The exchanges and actions between IAB Chair and ISO have accelerated at the IETF meeting. ISO group meets in December in Tokyo. Next steps and deadlines were set until February, preceding the BA meeting. I met individually with Paul, Charlie, Bastiaan. With Paul we discussed way forward about a complementary Problem Statement for V2I that would (1) use same concepts as in V2V and (2) involve service discovery such as DNS. With Charlie with discussed key characteristics and history of a manet routing protocol that could be useful in the V2V discussion. With Bastiaan we discussed ICN and CCN in the context of V2V. Alex --------------050703090905040406000701 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit [re-sent]

Hi ITSers,

With Dapeng we met in Yokohama with our IAB advisors.  We discussed
ways forward for an ITS activity at IETF.  Much of the discussion
revolved around the topic of motivating the use of IP protocols for
vehicular communications; different arguments pro and con were made
(about link heterogeneity, latency), while all at the same time tryng
to answer the question of why do the work at IETF.  We briefly
mentioned the kinds of solutions that have been mentioned until now in
this space (MIP, ND, AODV and most recently ICN).  Security mechanisms
are necessary in this context, especially after the recent attacks on
connected cars, reported largely in the media.  A question was made
about which layer of the protocols suffered in these attacks, not
clear whether it was IP or other.

A particular topic was the relationship with SDOs, in particular with
ISO TC204.  The exchanges and actions between IAB Chair and ISO have
accelerated at the IETF meeting.  ISO group meets in December in Tokyo.

Next steps and deadlines were set until February, preceding the BA
meeting.

I met individually with Paul, Charlie, Bastiaan.  With Paul we
discussed way forward about a complementary Problem Statement for V2I
that would (1) use same concepts as in V2V and (2) involve service
discovery such as DNS.  With Charlie with discussed key
characteristics and history of a manet routing protocol that could be
useful in the V2V discussion.  With Bastiaan we discussed ICN and CCN
in the context of V2V.

Alex
 --------------050703090905040406000701-- From nobody Mon Nov 9 04:30:56 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 556CC1B7C3B for ; Mon, 9 Nov 2015 04:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 QY7EKiCil2w1 for ; Mon, 9 Nov 2015 04:30:53 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7D21B7C3C for ; Mon, 9 Nov 2015 04:30:53 -0800 (PST) Received: by pasz6 with SMTP id z6so204267632pas.2 for ; Mon, 09 Nov 2015 04:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=cZShkNoaLyqVOUr6Pw/NXZnv1hv0qwEquF2yQhiPmz8=; b=EEDrz62FcaN9BnSR+ClqJ/but+ARsRMV0DVQXRo3CgY++Wp2Od34C8OUpCSs1qZiL2 k/JkfWiWKgExrS7XIZZDB02KAcc7bj7TgFBUJ4doqKII+moc+3yPQwYgT9ekLKJaXLaB GqRzQmETo613PMPzvf0gC95m6s+DucoX81nJFrmqk+6oBCqWez7rT856b+3nbfI+eHQI /4MzQCYhicjWYvIPVGlhVJGca/cqK6NRf9zm2NHfwdnJsBUGUskeklVPxn+G29xFhNWC FZ8RNdOcDs56bju53JcEXHVYZfvAHeXNGEl9j9FIYcWwdIlFnH++8kPyY7P5mTJE1n3H cXfQ== X-Received: by 10.66.218.170 with SMTP id ph10mr11551830pac.58.1447072252444; Mon, 09 Nov 2015 04:30:52 -0800 (PST) Received: from [10.0.1.6] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id yz3sm16200211pbb.37.2015.11.09.04.30.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Nov 2015 04:30:51 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_787DEFAE-8760-428E-8616-12581AAE0E1D" From: Jong-Hyouk Lee In-Reply-To: <564070E5.2030500@gmail.com> Date: Mon, 9 Nov 2015 21:30:48 +0900 Message-Id: <0A72F2EE-5F96-401B-A09B-528B52CB7731@gmail.com> References: <564070E5.2030500@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "its@ietf.org" Subject: Re: [its] minutes of Yokohama ITS bar bof and other informal meetings X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:30:55 -0000 --Apple-Mail=_787DEFAE-8760-428E-8616-12581AAE0E1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the minutes, Alex. Regarding recent hacking reports for real = vehicles, those are not related to IP yet. For instance, at the Black = Hat 2015 USA, the work "Remote Exploitation of an Unaltered Passenger = Vehicle" has been presented. The targeted vehicle was "Jeep Cherokee=E2=80= =9D that uses the CAN bus as a in-vehicle control bus. The demonstrated = hacking was breaking the CAN messages, e.g., causing to kill the engine, = no breaking, etc. IP protocols whatever IPv4 or IPv6 are not yet used for in-vehicle, v2v, = and v2i, but this does not mean that such hacking will not target to IP = protocols. Without securing IP protocols for vehicles, easier hackings = that are not required media specific hacking tricks will be available as = various hacking tools used for the Internet will be easily used for = vehicle hacking. J. -- 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 Nov 9, 2015, at 7:09 PM, Alexandre Petrescu = wrote: >=20 > [re-sent] >=20 > Hi ITSers, >=20 > With Dapeng we met in Yokohama with our IAB advisors. We discussed > ways forward for an ITS activity at IETF. Much of the discussion > revolved around the topic of motivating the use of IP protocols for > vehicular communications; different arguments pro and con were made > (about link heterogeneity, latency), while all at the same time tryng > to answer the question of why do the work at IETF. We briefly > mentioned the kinds of solutions that have been mentioned until now in > this space (MIP, ND, AODV and most recently ICN). Security mechanisms > are necessary in this context, especially after the recent attacks on > connected cars, reported largely in the media. A question was made > about which layer of the protocols suffered in these attacks, not > clear whether it was IP or other. >=20 > A particular topic was the relationship with SDOs, in particular with > ISO TC204. The exchanges and actions between IAB Chair and ISO have > accelerated at the IETF meeting. ISO group meets in December in = Tokyo. >=20 > Next steps and deadlines were set until February, preceding the BA > meeting. >=20 > I met individually with Paul, Charlie, Bastiaan. With Paul we > discussed way forward about a complementary Problem Statement for V2I > that would (1) use same concepts as in V2V and (2) involve service > discovery such as DNS. With Charlie with discussed key > characteristics and history of a manet routing protocol that could be > useful in the V2V discussion. With Bastiaan we discussed ICN and CCN > in the context of V2V. >=20 > Alex > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_787DEFAE-8760-428E-8616-12581AAE0E1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the minutes, Alex. Regarding recent hacking = reports for real vehicles, those are not related to IP yet. For = instance, at the Black Hat 2015 USA, the work "Remote Exploitation of an = Unaltered Passenger Vehicle" has been presented. The targeted vehicle = was "Jeep Cherokee=E2=80=9D that uses the CAN bus as a in-vehicle = control bus. The demonstrated hacking was breaking the CAN messages, = e.g., causing to kill the engine, no breaking, etc.

IP protocols whatever IPv4 or IPv6 are = not yet used for in-vehicle, v2v, and v2i, but this does not mean that = such hacking will not target to IP protocols. Without securing IP = protocols for vehicles, easier hackings that are not required media = specific hacking tricks will be available as various hacking tools used = for the Internet will be easily used for vehicle hacking.

J.
--
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 Nov 9, 2015, at 7:09 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

=20 =20
[re-sent]

Hi ITSers,

With Dapeng we met in Yokohama with our IAB advisors.  We discussed
ways forward for an ITS activity at IETF.  Much of the = discussion
revolved around the topic of motivating the use of IP protocols for
vehicular communications; different arguments pro and con were made
(about link heterogeneity, latency), while all at the same time tryng
to answer the question of why do the work at IETF.  We = briefly
mentioned the kinds of solutions that have been mentioned until now in
this space (MIP, ND, AODV and most recently ICN).  Security mechanisms
are necessary in this context, especially after the recent attacks on
connected cars, reported largely in the media.  A question = was made
about which layer of the protocols suffered in these attacks, = not
clear whether it was IP or other.

A particular topic was the relationship with SDOs, in particular with
ISO TC204.  The exchanges and actions between IAB Chair and = ISO have
accelerated at the IETF meeting.  ISO group meets in December = in Tokyo.

Next steps and deadlines were set until February, preceding the = BA
meeting.

I met individually with Paul, Charlie, Bastiaan.  With Paul we
discussed way forward about a complementary Problem Statement for V2I
that would (1) use same concepts as in V2V and (2) involve service
discovery such as DNS.  With Charlie with discussed key
characteristics and history of a manet routing protocol that could be
useful in the V2V discussion.  With Bastiaan we discussed = ICN and CCN
in the context of V2V.

Alex
_______________________________________________
its = mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

= --Apple-Mail=_787DEFAE-8760-428E-8616-12581AAE0E1D--