Subject: [its] FW: Automotive Network Discussion

From: Alison Chaiken <[email-masked]>
Date: Sun, 15 Jul 2012 11:49:26 -0700

As before, I know nothing about the event beyond what's in the announcement:

Christie Dudley <[email-masked]> Jul 14 06:49PM -0700
A reminder, a request and further information for the event next Tuesday.

We will be getting together on Tuesday July 17th at 7:00PM at Hacker Dojo
for this DC650 event.

I'd request that only people who have something specific to add to the
discussion of privacy and security implementation attend. The meeting will
be formatted as a working group rather than a presentation. We only have
space for 15 participants, including me. I am also working on a tight
deadline to get this in and I want to offer the opportunity for community
contribution. I would hate to have to exclude someone who has something
important to contribute because someone has decided to attend just out of
curiosity.

I plan to offer a presentation on what we are covering here in more detail
suitable for a wider audience at a later point, so there's still
opportunity to get involved even if you don't feel you have any
contribution to offer just yet.

To prepare for the working group, we will be starting with the recently
published white paper on the security approach, considering accuracy,
relevancy and completeness. In the interest of time, I'd request that
participants have a look at this before attending, so I don't have to
discuss it in any detail. (Please don't make any assumptions that any of
the propositions in this white paper are necessarily true.)

http://ntl.bts.gov/lib/43000/43500/43513/FHWA-JPO-11-130_FINAL_Comm_Security_Approach_11_07_11.pdf

More information on the communication technology employed:
DSRC (Dedicated Short Range Communications), the communication medium:
http://www.its.dot.gov/factsheets/dsrc_factsheet.htm

The focus I expect to maintain in this discussion is privacy. Personal
privacy is *not* a negotiable condition for the implementation of this
system. (We start getting into 5th Amendment issues if we can't maintain
it.) If users privacy may be compromised in any foreseeable way, then the
system will not be implemented.

As an interesting note, we are not limited to technical issues, but may
want to consider weaknesses of policy decisions as well.

Christie
_______
"Privacy is not a discrete commodity, possessed absolutely or not at all."
Justice Marshall, Smith v. Maryland dissent

-- 
Alison Chaiken                           [email-masked]
650-279-5600                            http://{she-devel.com,
exerciseforthereader.org}
"Each success only buys an admission ticket to a more difficult problem."
-- Henry Kissinger

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 16 Jul 2012 12:40:04 -0700

> We will be getting together on Tuesday July 17th at 7:00PM at Hacker
I don't know where Hacker Dojo is nor do I know what time zone you're
working from.  Without that metadata, I can't be there (and probably
won't anyway due conflicts).

> http://ntl.bts.gov/lib/43000/43500/43513/FHWA-JPO-11-130_FINAL_Comm_Security_Approach_11_07_11.pdf
The paper is not very good.

Executive Summary, 2nd paragraph.  The uses of the network are very
constricted by ... "will use wireless, short-range communications to
deliver data and create a dynamic data exchange between and among
vehicle-to-vehicle ..."  This omits what I consider some very important
needs:
	- instrumenting an ambulance (as just one use case).  Is the
'short-range communications' to be a routable network?  The tunnel
vision of the requirements indicates that it doesn't need to be.  Yet
exporting the data to an emergency room requires that it be.
	- importing weather and traffic conditions.  Same arguments. 
The fact sheet page reinforces the perception that some rather important
use cases are left out of the requirements analysis.  By
tunnel-visioning the scope, the notion that this network segment needs
to be an extension of the internet gets lost.   

To the security issues directly.  Nowhere in the security treatment is
authenticity of the data discussed.  If I'm driving in iffy weather and
want to know road conditions ahead, I don't give a hoot about
confidentiality of the data nor do I care about the infrastructure
protection ... but I DO care about whether or not the road condition
information is bogus or not.  
	One of the listed requirements is emergency braking ahead.  How hard
would it be to phony up a gadget that emits bogus emergency braking
messages?  
	I can't find any treatment of the scope of the security.  In this case
of importing wx data, the needed scope is end-to-end, meaning that the
security measures must be implemented in layers 6/7.  
	The security treatment does not contain any factual errors that jump
out at me, but the organization and correlation to requirements needs
help.

Policy.  If this paper were to evolve into a program, what would be the
program's relationship to FirstNet?  (This is a US-centric question).  

> "Each success only buys an admission ticket to a more difficult
> problem." -- Henry Kissinger
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Christie Dudley <[email-masked]>
Date: Mon, 16 Jul 2012 14:07:53 -0700

Thanks for the commentary. That report is more or less what the DOT has
been operating from when contemplating the mandate. Although a small amount
of information has been made available under NDA beyond that, it hasn't
been significant enough to make any appreciable difference.

This announcement went out to local lists and spread from there. Hacker
Dojo is in Mountain View California, so the meeting is scheduled for 7PM
PDT. I don't have the capability to do a remote host for this session,
although it's beginning to sound like a good idea. This will certainly not
be the last of the discussion on this topic.

Christie

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Jul 2012 11:37:26 +0200

Le 16/07/2012 23:07, Christie Dudley a écrit :
> Thanks for the commentary. That report is more or less what the DOT
> has been operating from when contemplating the mandate.

Interesting to learn that DoT (Department of Transportation, US) itself
is involved in performing demonstrations of this vehicular kind.

In France, DoT would be akin to Ministère des Transports but more
recently named Ministère de l'Écologie something... but I doubt they'd
do any demo at all.

There is however IFSTTAR in France concerned more about transportation
and research.  They are involved often in larger scale demonstrations of
use of communication technologies for vehicular and transportation.

> Although a small amount of information has been made available under
>  NDA beyond that, it hasn't been significant enough to make any
> appreciable difference.
>
> This announcement went out to local lists and spread from there.

It's good to learn that the ITS list is known to the local lists at your
organization.  If further detail is needed one could announce it further:

ITS at ietf.org is an informal group interested in the use of IP
technologies in Intelligent Transportation Systems.  There is an email
list [email-masked] and ietf.org/mailman/listinfo/its.  There was an
face-to-face meeting March 2012 in Paris, France, during the IETF.
There exist initiatives to perform further work at IETF in this direction.

Alex

> Hacker Dojo is in Mountain View California, so the meeting is
> scheduled for 7PM PDT. I don't have the capability to do a remote
> host for this session, although it's beginning to sound like a good
> idea. This will certainly not be the last of the discussion on this
> topic.
>
> Christie
>
> On Jul 16, 2012 12:41 PM, "Rex Buddenberg" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Christie Dudley <[email-masked]
> <mailto:[email-masked]>> Jul 14 06:49PM -0700
>> We will be getting together on Tuesday July 17th at 7:00PM at
>> Hacker Dojo for this DC650 event.
>>
> I don't know where Hacker Dojo is nor do I know what time zone
> you're working from.  Without that metadata, I can't be there (and
> probably won't anyway due conflicts).
>
>> discussion of privacy and security implementation attend. The
>> meeting will be formatted as a working group rather than a
>> presentation. We only have space for 15 participants, including me.
>> I am also working on a tight deadline to get this in and I want to
>> offer the opportunity for community contribution. I would hate to
>> have to exclude someone who has something important to contribute
>> because someone has decided to attend
> just out
>> of curiosity.
>>
>> I plan to offer a presentation on what we are covering here in
>> more detail suitable for a wider audience at a later point, so
>> there's still opportunity to get involved even if you don't feel
>> you have any contribution to offer just yet.
>>
>> To prepare for the working group, we will be starting with the
>> recently published white paper on the security approach,
>> considering accuracy, relevancy and completeness. In the interest
>> of time, I'd request that participants have a look at this before
>> attending, so I don't have to discuss it in any detail. (Please
>> don't make any assumptions that any of the propositions in this
>> white paper are necessarily true.)
>>
>>
> vehicle-to-vehicle ..."  This omits what I consider some very
> important needs: - instrumenting an ambulance (as just one use case).
> Is the 'short-range communications' to be a routable network? The
> tunnel vision of the requirements indicates that it doesn't need to
> be.  Yet exporting the data to an emergency room requires that it be.
> - importing weather and traffic conditions.  Same arguments. The fact
> sheet page reinforces the perception that some rather important use
> cases are left out of the requirements analysis.  By tunnel-visioning
> the scope, the notion that this network segment needs to be an
> extension of the internet gets lost.
>
>
> To the security issues directly.  Nowhere in the security treatment
> is authenticity of the data discussed.  If I'm driving in iffy
> weather and want to know road conditions ahead, I don't give a hoot
> about confidentiality of the data nor do I care about the
> infrastructure protection ... but I DO care about whether or not the
>  road condition information is bogus or not. One of the listed
> requirements is emergency braking ahead. How hard would it be to
> phony up a gadget that emits bogus emergency braking messages? I
> can't find any treatment of the scope of the security. In this case
> of importing wx data, the needed scope is end-to-end, meaning that
> the security measures must be implemented in layers 6/7. The security
> treatment does not contain any factual errors that jump out at me,
> but the organization and correlation to requirements needs help.
>
>
>
> Policy.  If this paper were to evolve into a program, what would be
> the program's relationship to FirstNet?  (This is a US-centric
> question).
>
>
>
>
>
>
>> More information on the communication technology employed: DSRC
>> (Dedicated Short Range Communications), the communication
> medium:
>> system. (We start getting into 5th Amendment issues if we can't
>> maintain it.) If users privacy may be compromised in any
>> foreseeable way, then the system will not be implemented.
>>
>> As an interesting note, we are not limited to technical issues,
>> but may want to consider weaknesses of policy decisions as well.
>>
>> Christie _______ "Privacy is not a discrete commodity, possessed
>> absolutely or not at all." Justice Marshall, Smith v. Maryland
>> dissent
>>
>>
>>
>> -- Alison Chaiken [email-masked]
>> <mailto:[email-masked]> 650-279-5600 <tel:650-279-5600>
>>
> http://{she-devel.com <http://she-devel.com>,
>> exerciseforthereader.org <http://exerciseforthereader.org>} "Each
>> success only buys an admission ticket to a more difficult problem."
>> -- Henry Kissinger _______________________________________________
>> its mailing list [email-masked] <mailto:[email-masked]>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Jul 2012 17:00:03 +0200

> On Sun, 2012-07-15 at 11:49 -0700, Alison Chaiken wrote:
[...]
> The paper is not very good.

This is one kind of papers which, together with e.g. the ETSI ITS
specifications about IPv6, are good to discuss here.  We may help
improve them.

Alex

> important needs: - instrumenting an ambulance (as just one use
> case). Is the 'short-range communications' to be a routable network?
> The tunnel vision of the requirements indicates that it doesn't need
> to be.  Yet exporting the data to an emergency room requires that it
> be. - importing weather and traffic conditions.  Same arguments. The
> fact sheet page reinforces the perception that some rather important
> tunnel-visioning the scope, the notion that this network segment
> needs to be an extension of the internet gets lost.
>
>
> the security measures must be implemented in layers 6/7. The
> security treatment does not contain any factual errors that jump out
> at me, but the organization and correlation to requirements needs
> help.
>
>
>
>> (Dedicated Short Range Communications), the communication medium:
>> The focus I expect to maintain in this discussion is privacy.
>> Personal privacy is *not* a negotiable condition for the
>> implementation of this system. (We start getting into 5th
>> Amendment issues if we can't maintain it.) If users privacy may be
>> compromised in any foreseeable way, then the system will not be
>> implemented.
>>
>> As an interesting note, we are not limited to technical issues, but
>> may want to consider weaknesses of policy decisions as well.
>>
>> exerciseforthereader.org} "Each success only buys an admission
>> ticket to a more difficult problem." -- Henry Kissinger