Subject: [its] Fwd: comments on vehicular communication drafts

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 2 Nov 2015 16:05:08 +0900

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 <[email-masked]>
Pour : 	[email-masked] 
<[email-masked]>, [email-masked] 
<[email-masked]>, 
[email-masked] 
<[email-masked]>, 
[email-masked] <[email-masked]>

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.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 4 Nov 2015 18:22:42 +0900

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 <[email-masked]> Pour :
> [email-masked] <[email-masked]>,
> [email-masked]

> 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

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.

> 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
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: "George, Wes" <[email-masked]>
Date: Thu, 5 Nov 2015 01:51:42 +0000

Thanks for the response

>Sorry, what do you mean by identifying the system as read-only?

WG] sorry I was unclear- what I mean is that the V2V communications are
largely informational (positions, obstacles, etc), and are not intended to
be able to do any sort of control of the vehicle's systems, so it would be
appropriate to make this relationship and restriction explicit, because it
would mean that the gateway between V2V and the rest of the vehicle would
never see inbound attempts to communicate through that gateway to other
parts of the car. It would take in whatever information it needs from
other vehicles, analyze it, and pass it to the more trusted parts of the
car via a very clearly defined method (vs a more open model where that
near air-gap doesn't exist between the systems). Sounds like from the
below that you're already thinking along those lines.

>immediate infrastructure, how should the downwards path from the

[snip]
>is being considered somewhere.  This will be a large effort I think.

WG] this is a good point to address, but really it's just a variant of the
catch-22 we've been dealing with for years when it comes to IPv6
deployment - we can't require IPv6 or develop IPv6-only features because
not everyone supports it/not everyone supports it because there is not a
consistent, non-negotiable requirement for it. Given that this is likely
to be something that carries the force and weight of several large
governments behind it, it is a good lever to pull as a forcing function to
ensure that the mobile operators support IPv6 consistently (including
roaming) and that the infrastructure is designed with IPv6 in mind from
the get-go, taking a step away from the legacy baggage that comes with
older systems. Automakers and governments will both be applying pressure
on the SPs and their suppliers to ensure compliance, and as that starts
being a reality in major markets, it starts becoming more likely to be
there in secondary markets because the heavy lifting is already done.

Thanks

Wes