Subject: [ipwave] Human Rights Review of draft-ietf-ipwave-vehicular-networking-04

From: Amelia Andersdotter <[email-masked]>
Date: Fri, 7 Sep 2018 12:08:17 +0200

Dear all,

As part of efforts in the Human Rights Protocol Considerations (HRPC)
group, I have reviewed the human rights considerations (RFC 8280) in
IPWAVE Problem Statement.
https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/

The below text has been sent to the author of the document on August 28.
I'm now hoping for input from the larger community.

best regards,

Amelia

# Summary
===============================

I understand that the draft contains a satisfactory treatment of the
human rights concerns listen in Section 6.2.1 (Connectivity), 6.2.3
(Content agnosticism), 6.2.8 (Heterogeneity support), Section 6.2.14
(Reliability), Section 6.2.16 (Integrity), Section 6.2.17 (Authenticity)
and 6.2.18 (Adaptability) of RFC8280. I have also traced some of the
dependencies of the draft on less accessible standards in accordance
with Section 6.2.7 (Open Standards) in RFC8280.

I have suggested improvements with respect to human rights concerns
listed in Sections 6.2.2 (Privacy), 6.2.4 (Security), 6.2.6 (Censorship
Resistenace), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.13
(Decentralization), 6.2.15 (Confidentiality) and 6.2.19 (Outcome
transparency) in RFC8280.

I finally make two suggestions related to Sections 6.2.5
(Internationalization), 6.2.11 (Accessibility) and 6.2.12 (Localization)
in RFC8280.

# Topical human rights review
====================
## Part 1: Privacy, decentralization, transparency
-----------------------------------------------------------------------

This part reviews IPWAVE Problem Statement draft from the perspectives
of Sections 6.2.2 (Privacy), 6.2.4 (Security), 6.2.6 (Censorship
Resistenace), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.13
(Decentralization), 6.2.15 (Confidentiality) and 6.2.19 (Outcome
transparency) in RFC8280.

In Section 4.1.7 Current Protocols for Vehicular Networking: Security
and Privacy, the focus is only on encryption and certificate exchanges.
I believe this can be complemented by raising topics that have been
prevalent in vehicular communications for a large number of years.
Notably data minimization and geolocalisation threats (see e.g. RFC6973,
section 6.1: Data minimization).

It is generally recognised that vehicular communications face particular
security and privacy challenges, with the driver of the connected
vehicle perhaps being obliged by law to disseminate specified, and
verifiably accurate, data. This makes the driver unable to deploy common
privacy strategies, such as obfuscation, and calls for extra careful
consideration of durable connections (such as connections that last over
pseudonym changes, thereby opening new privacy attack vectors).
Pseudonym changes are therefore proposed as alternative privacy risk
mitigations.

In Section 5.3, there is focus on integrity (RFC8280, Section 6.2.16)
and authenticity (RFC8280, Section 6.2.17), where the privacy and
security complications arising from vehicular networks are, I insist,
broader in scope. It is not clear that the Vehicle Identification Number
(VIN) would not be used to track a vehicle or its driver against his or
her wishes, even if the MAC address and IP address are randomized or
re-addressed. Of particular importance are those situations where
drivers are not legally alloId to discontinue a particular connection
(see also RFC6973, Section 6.2: User Control or RFC8280, Section 6.2.6:
Censorship Resistance and Section 6.2.15: Confidentiality).

I see a need for at least reflection on the centralized properties of
authentication and certificate schemes in Section 5.3 (see e.g. RFC8280,
Section 6.2.13: Decentralization). Depending on which agent is
ultimately endoId with the responsibility of issuing certificates for
security purposes, there may be large downstream market effects on
drivers and the service providers available for drivers to choose. In
fact, this is a central issue in drivers' associations concerns with
vehicular communications and, in general, telematics[2]. Both of these
considerations call into question whether the "same" network should be
used for all use-cases listed in Section 3 of the Problem Statement. It
may be, for instance, that pseudonym self-issuance should be considered
for some use-cases, but not for others. An overview of pseudonym
issuance strategies is found in [3].

Finally, there has been some attention in literature to the use of OBU
caching as a way of minimizing contacts with RSU[4], or including
options to collect information from other near-by vehicles instead of
from the RSU when a querying need arises. IPWAVE may want to delve
further into the topic of how this might work in an ad hoc 802.11
network and whether IPWAVE gives options for solutions that are not as
well present in other technologies.

## Part 2: Internationalization and accessibility
------------------------------------------------------------------

This part reviews IPWAVE Problem Statement draft from the perspectives
of Sections 6.2.5 (Internationalization), 6.2.11 (Accessibility) and
6.2.12 (Localization) in RFC8280. These sections deal with ways in which
affected parties can interact effortlessly with resulting specifications.

The IPWAVE Problem Statement draft any obvious efforts to address the
issues raised in those sections of RFC8280. That said, accessibility as
in Sections 6.2.11 or 6.2.12 may require the cooperation of user
interface designers and higher layers.

In the context of internationalization and localization, I note that
references to regulatory frameworks that put natural boundaries on the
scope of the projects proposed within the Problem Statement are limited
to North America and Europe. It is not clear whether those geographical
regions that use different alphabets or logographs have a greater
interest in internationalization and localization, than those
geographical regions that predominantly rely on the latin alphabet. This
could be clarified.

In the context of privacy options discussed above, it is the case that
the standards developed in IPWAVE are more likely to be consumed by
implementers and user interface designers at higher layers than by
drivers of vehicles. In the interest of accessibility and localization,
clarity with respect to privacy-, user control- or security-enhancing
features for the implementers is paramount to ensure that these features
do not end up obscured.

## Part 3: Open standards
--------------------------------------

This part reviews IPWAVE Problem Statement draft from the perspective of
Section 6.2.7 (Open Standards) in RFC8280.

It may be noted that the IETF as such makes open standards and maintains
openness throughout the standard developments deliberations. Many of the
standards referenced in Problem Statement are not open. IEEE 1609 and
IEEE 802.11-OCB may require subscriptions for researchers and
implementers to accesss for some time after the completion of a
standardisation project, while ISO standards are always closed to the
public, in the sense that they sell access to their standards. ETSI and
3GPP standards become accessible to the public only upon their conclusion.

# Recommendations
-----------------------------

1. In our literature review, I found one proposal to use Multipath TCP
to enable lasting connections in spite of re-addressing[1]. This study
could be tentatively inserted in Section 4.1.7. Reference [3] should be
added to section 5.3 together with observations made above. Similarly
section 5.3 could cover reference [4].

2. Due consideration should be given to the fact that a lasting
connection risks defeating some of the purposes of pseudonym
randomization/re-issuance, since the lasting connection would then in
and of itself become a way to track the vehicle. The Vehicle
Identification Number (VIN) risks defeating the purpose of re-addressing
or pseudonym handling, if it is used as an authentication mechanism.
Section 4.2.4 Pseudonym Handling or Section 5.3 could raise this issue.
Of particular importance for a vehicle owner or driver will be whether
these durable connections are mandatory to enable under any legislation.

It could be considered whether different certificate issuance strategies
can be deployed for different types of connections.

3. I believe an additional definition is needed for the word
"pseudonym", in order to clarify that by this word the document means
the same thing as is meant by MAC/Layer-2 Randomization in P802.11aq,
the readdressing feature described in IEEE 1609.4-2016, or the temporary
identifiers referenced in ETSI TS 102 941.

4. IPWAVE should make it clear it intends that privacy-friendly options
should be made explicit to implementers in the developed standards.

5. The working group may consider whether to undertake greater
internationalization efforts inside the group, or request it from other
working groups, bearing in mind that some of the geographical regions
not covered by the regulatory review may consider this a perk.

[1] S. Han, H. Kim and Y. Park, "Overcoming IP communication breakdown
upon pseudonym changes in the IEEE WAVE," 2017 IEEE Vehicular Networking
Conference (VNC), Torino, 2017, pp. 183-186.
doi: 10.1109/VNC.2017.8275622
URL:
http://ieeexplore.ieee.org.ludwig.lub.lu.se/stamp/stamp.jsp?tp=&arnumber=8275622&isnumber=8275590

[2] FIA, http://mycarmydata.eu

[3] J. Petit, F. Schaub, M. Feiri and F. Kargl, "Pseudonym Schemes in
Vehicular Networks: A Survey," in IEEE Communications Surveys &
Tutorials, vol. 17, no. 1, pp. 228-255, Firstquarter 2015.
doi: 10.1109/COMST.2014.2345420
URL:
http://ieeexplore.ieee.org.ludwig.lub.lu.se/stamp/stamp.jsp?tp=&arnumber=6873216&isnumber=7061782

[4] B. Liu, W. Zhou, T. Zhu, L. Gao, T. H. Luan and H. Zhou, "Silence is
Golden: Enhancing Privacy of Location-Based Services by Content
Broadcasting and Active Caching in Wireless Vehicular Networks,"
in /IEEE Transactions on Vehicular Technology/, vol. 65, no. 12, pp.
9942-9953, Dec. 2016.
doi: 10.1109/TVT.2016.2531185
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7414507&isnumber=7779452

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 7 Sep 2018 07:18:24 -0400

Hi Amelia,

Very interesting and potentially useful.

It appears, however, that the draft is based on relatively old
specifications and work - in an arena where the activity changes from
week to week.  There are also significant venues that are not even
recognized.

For example, ITU-T Study Group 17 (security) met the past two weeks in
Geneva where it consider 56 documents.  This venue is also a global
intergovernmental one with liaison relationships to numerous over
venues, so it is of some increased significance. 

It has an entire rapporteur group now dedicated to vehicular
communication security and privacy chaired by Korea's ETRI and Hyundai
Motors.  You can check out its terms of reference and 9 current work
items here https://www.itu.int/net4/ITU-T/lists/loqr.aspx?Group=17&Period=16

They also just added five new work items - all of  which have hrpc
implications:

  * Requirements of security information sharing and analysis for
    connected vehicles    
  * Information of gap analysis for proposed new work item, security
    aspects of cloud-based EDR in ITS context    
  * Security guideline for automotive Ethernet in In-Vehicle networks    
  * Security guidelines for cloud-based event data recorders in ITS
    context    
  * Distributed Ledger based Vehicle Information Sharing 

There is also an enormous amount of ongoing work in 3GPP and GSMA in
this area that is not reflected in the draft.

So admittedly, timeliness here is a challenge.  However, you probably
don't want to start out using material that is many years out of date
and significantly incomplete.

--tony

ps. +1 on the plea for open standards!  It costs thousands of Euros to
even look at some of sets.

---

From: Amelia Andersdotter <[email-masked]>
Date: Fri, 7 Sep 2018 13:23:32 +0200

Dear Tony,

On 2018-09-07 13:18, Tony Rutkowski wrote:
> items here
> https://www.itu.int/net4/ITU-T/lists/loqr.aspx?Group=17&Period=16
>
The working group was brought to my attention and I have surveyed their
documents. For the purposes of this review, I considered the recently
initiated ITU-T SG 17 initiatives too undeveloped for an RFC8280 Section
6.2.7 Open Standards mention.

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 8 Sep 2018 07:59:23 +0900

Hi Amelia,
As the editor of this document, I sincerely appreciate your review and will
use it in the next revision.

Thanks

Best Regards,
Paul

2018년 9월 7일 (금) 오후 7:08, Amelia Andersdotter <[email-masked]>님이 작성:

> http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7414507&isnumber=7779452
>
> --
> Amelia Andersdotter
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>