Subject: [hrpc] RFC8280 Human Rights Review of draft-ietf-ipwave-ipv6-over-80211ocb-25

From: Amelia Andersdotter <[email-masked]>
Date: Fri, 7 Sep 2018 22:49: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
IPv6-over-OCB v25.
https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/25/

I've briefly reviewed v26 of the document, and find that the general
recommendations and observations below still hold in general. The review
is ended with an ERRATA (editorial remarks).

The below text has been sent to the author of the document on September
4, and some comments were received today (September 7). In this
submission, I'm hoping to open up for input from the larger community.

best regards,

Amelia

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

I understand that Sections 6.2.1 (Connectivity), 6.2.3 (Content
agnosticism), 6.2.6 (Censorship Resistenace), 6.2.8 (Heterogeneity
support) and 6.2.18 (Adaptability) of RFC8280 are taken into account by
the draft. References in the draft on less accessible standards in
accordance with Section 6.2.7 (Open Standards) in RFC8280 follows a
previously submitted evaluation.

I suggest expansions on topics related to Sections 6.2.2 (Privacy),
6.2.4 (Security), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.14
(Reliability), 6.2.16 (Integrity) and 6.2.17 (Authenticity) in RFC8280.

I do not identify any concerns raised by Sections 6.2.5
(Internationalization), 6.2.11 (Accessibility), 6.2.12 (Localization)
and 6.2.19 (Outcome transparency) in RFC8280.

# Topical human rights review
====================

## Part 1: Privacy, reliability, integrity and authenticity
===================================
This part reviews IPv6-over-80211-OCB draft with respect to Sections
6.2.2 (Privacy), 6.2.4 (Security), 6.2.9 (Anonymity), 6.2.10
(Pseudonymity), 6.2.14 (Reliability), 6.2.16 (Integrity) and 6.2.17
(Authenticity) in RFC8280.

Privacy and security issues are raised in various places of the
documents, for instance in Section 1, Section 4.5, Section 5 and
Appendix C, D and F. HoIver, while they are raised, no specific
recommendations to mitigate concerns are made. It is only mentioned that
other documents and standards do propose risk mitigation strategies.

The considerations raised in Appendix F.3 regarding the reliability and
integrity of the transmission schemes seem like they could have a big
impact on what functionalities must be included in this draft. If the
IPv6 transmission itself needs to guarantee specified senders and
receivers, this would require different privacy trade-offs in the rest
of the document.

It was not immediately clear whether link-local addresses are
recommended for any particular purposes or use-cases. It is my
understanding that link-local addresses restrict the ability of an
interface to communicate with other interfaces than those with whom they
share a direct link, and that this may entail privacy benefits. But in
Section 4.6 there are conflicting references to RFC5889, where it's
specified that IPv6 link-local addressing should be avoided in ad hoc
networks.

Many considerations in the draft are impacted by the strong necessity to
use protection tools such as dynamic MAC re-addressing. This impacts the
ability to use IPv6 address generation as described in Section 4 of
RFC2464. But dynamic MAC re-addressing also would appear to justify the
recommendation to use stable IPv6 address generation as described in
RFC8064 or RFC7217. Currently, pseudonym handling is just briefly
mentioned at the end of Section 5 as a security issue but given its
impact on addressing and IPv6 address generation, I believe they merit
their own section.

In Appendix F.1, it is not clear why a mechanism to uniquely identify a
vehicle is necessary. It should be clarified whether this is a technical
requirement (for instance, whether this constitutes a proposal to
introduce a unique identifier different from the Layer-2 MAC unique
identifier), or a legal requirement, and whether this new unique
identifier is intended for use in networking in general, or only for
specific circumstances.

## Part 2: Internationalization, accessibility and transparency
=======================================

The functions described in this draft do not appear to be impacted by
Sections 6.2.5 (Internationalization), 6.2.11 (Accessibility) or 6.2.12
(Localization) in RFC8280. Similarly, the applicability of Section
6.2.19 (Outcome transparency) in RFC8280 seems largely related to issues
relating to authenticity, reliability and integrity.

# Recommendations:
==============

1. Collect all references to privacy and security in one place. If
privacy and security is in Section 4.5, 5 and Appendix F (as specified
in Section 4.5), this should be noted in Section 1. Also, privacy and
security issues are only mentioned in this document: recommendations for
their resolution are not present. This should be reflected in the Section 1.

2. In Section 4, add a section named "Pseudonym handling" at the very
top, describing the issues raised in the final paragraph of Section 5.
Remove the last paragraph of Section 5.

3.  The potential privacy benefits of link-local addresses could be
raised, especially since OCB transmissions are not secure against
curious nodes. On the other hand, RFC5889 Section 6.1 states that
link-local addressing is discouraged for ad hoc IPv6 networks. These
trade-offs could be expanded upon.

4. In Section 4.3 and 4.5 it should be clarified what privacy benefits,
if any, are expected from using semantically obscure IIDs as proposed in
RFC7217. It will at least be relevant to clarify whether privacy
benefits could arise in contexts that are explicitly out of scope (such
as during forming, termination or handover), e.g. with respect to
parameter selection as specified in Appendix A of RFC7217.

# References:
=========

[RFC8280] Research into Human Rights Protocol Considerations
https://tools.ietf.org/html/rfc8280

==# ERRATA:
=========

Neither the term IP-RSU nor the term IP-OBU defined in Section 2 are
actually used in the document.

In Section 2, definitions, the definition of IP-RSU can be made more
succinct by removing the second sentence (that is, remove "An IP-RSU has
at least two distinct IP-enabled interfaces; at least one interface is
operated in mode OCB of IEEE 802.11 and is IP-enabled.").

Section 4.5 only needs to recommend following the procedures in RFC8064
once.

In Appendix C, p. 26, 2nd to last paragraph, it is mentioned that MAC
re-addressing is described in IEEE-1609.4 Section 6.7. HoIver, in my
copy of IEEE-1609.4 this feature is described in Section 6.6.

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 14 Sep 2018 15:19:00 +0200

Dear Amelia,

Thank you for the Human Rights Review of the IPv6-over-OCB draft version 25.

In this email I address 'part 1' of the comments.

Alex

> submission, I'm hoping to open up for input from the larger community.

I agree with the comment.

To that end, I created a new "Privacy Considerations" subsection of the 
"Security Considerations" section, trying to gather most of the privacy 
discussion.

The privacy considerations are raised in section "Privacy Considerations".

The methods to address these privacy considerations (what you rightfully 
name 'risk mitigation strategies') are described in subsection "MAC 
Address Generation" and in section "SLAAC".

If necessary, I can explain why both subsections are needed, and 
situated at two distinct places.

> receivers, this would require different privacy trade-offs in the rest

I think the requirements in F.2 are necessary.  They are necessary for 
future mechanisms of improving the basic works of IPv6-over-OCB.  Ex.: 
this draft describes how IPv6 works basically over OCB.  But future 
drafts would describe how a common channel is selected between two 
parties, among 6 possible, thanks to this req in F.3 to "converge to a 
common channel".  That is why F.2 is there.

That said, I take into account your remark that what these requirements 
require is not present in this draft, and I take into account an earlier 
comment that suggests the same; thus I will remove appendix F.2.

The same reasoning applyes to appendifx F.3 "Multiple Interfaces" - I 
will remove F.3.

[ll discussion, pseudonym topic and unique identifiability question - to 
be addressed]

> ## Part 2: Internationalization, accessibility and transparency

I will treat these recommendations soon.

The term IP-RSU and the term IP-OBU are used in -25, ex. "The link model 
is the following: STA --- 802.11-OCB --- STA.  In vehicular networks, 
STAs can be IP-RSUs and/or IP-OBUs."

> operated in mode OCB of IEEE 802.11 and is IP-enabled.").

I do not understand why removing that sentence?  HAving two IP-enabled 
interfaces qualifies it as a router.  It is important we say the IP-RSU 
is a router because: many deployed RSUs (not IP-RSU) are routers yet do 
not forward IP packets to the OCB interface; so, an IP-RSU would forward 
IP packets to the OCB interface if that IP-RSU is a router.  It is 
circular, but it is positive, in the right direction: it allows to 
correct people who call an RSU a 'router' and suggest them to call it a 
'router' _only_ if it forwards on the OCB interface too.

That said, I agree the definition could be made more succinct.

TO that end, here is one part that is redundant: "at least one interface 
is operated in mode OCB of IEEE 802.11" and "the wireless PHY/MAC layer 
of at least one of its IP-enabled interfaces is configured to operate in 
802.11-OCB mode".

For this reason, I will remove "at least one interface is operated in 
mode OCB of IEEE 802.11", and so the definition will be a little more 
succinct.

> Section 4.5 only needs to recommend following the procedures in RFC8064

I agree.  In next rev we only refer once to RFC8064 in section 4.5.

> copy of IEEE-1609.4 this feature is described in Section 6.6.

Ah!  For confirmation - is your 1609.4 document the IEEE 1609.4-2016? 
(i.e. the document of year 2016).

But looks as these versions change often.  Maybe I want to remove the 
phrase "a relevant function is described in [1609...] ..."

Alex

---

From: Amelia Andersdotter <[email-masked]>
Date: Wed, 19 Sep 2018 12:15:44 +0200

Dear Alexander,

Thank you, and I'm sorry for this delayed response. See responses in line:

> To that end, I created a new "Privacy Considerations" subsection of
> the "Security Considerations" section, trying to gather most of the
> privacy discussion.
>
> The methods to address these privacy considerations (what you
> rightfully name 'risk mitigation strategies') are described in
> subsection "MAC Address Generation" and in section "SLAAC".
>
It looks easier to follow now, to me. Thanks!

> That said, I take into account your remark that what these
> requirements require is not present in this draft, and I take into
> account an earlier comment that suggests the same; thus I will remove
> appendix F.2.
>
> [ll discussion, pseudonym topic and unique identifiability question -
> to be addressed]
>
OK!

> The term IP-RSU and the term IP-OBU are used in -25, ex. "The link
> model is the following: STA --- 802.11-OCB --- STA.  In vehicular
> networks, STAs can be IP-RSUs and/or IP-OBUs."
>
Hm. They come up when I search for them now, but didn't before. Sorry
for the confusion.

> interfaces qualifies it as a router.  It is important we say the
> IP-RSU is a router because: many deployed RSUs (not IP-RSU) are
> routers yet do not forward IP packets to the OCB interface; so, an
> IP-RSU would forward IP packets to the OCB interface if that IP-RSU is
> a router.  It is circular, but it is positive, in the right direction:
> it allows to correct people who call an RSU a 'router' and suggest
> them to call it a 'router' _only_ if it forwards on the OCB interface
> too.
>
An IP-RSU is already defined as being "similar to an Access Network
Router" which is defined in RFC3753 as "An IP router in the Access
Network." So I thought perhaps that already covered its qualification as
router. Also, maybe the "similar to an Access Point as defined in IEEE
documents" should go, since OCB networks specifically do not have Access
Points.

My new suggestion would be: "An IP-RSU is situated along the road. It
has at least two distinct IP-enabled interfaces and the wireless PHY/MAC
layer of at least one of its IP-enabled interfaces is configured to
operate in 802.11-OCB mode. An IP-RSU communicates with the IP-OBU in
the vehicle over 802.11 wireless link operating in OCB mode. It is
similar to a Wireless Termination Point (WTP), as defined in [RFC5415]
or an Access Network Router (ANR) defined in [RFC3753]."

It preserves the technical requirements listed first, and puts analogies
with other similar terms last.

> phrase "a relevant function is described in [1609...] ..."

It is this one: 1609.4-2016 - IEEE Standard for Wireless Access in
Vehicular Environments (WAVE) -- Multi-Channel Operation, Revision of
IEEE Std 1609.4-2010 (Revision of IEEE Std 1609.4-2006) cited as DOI:
10.1109/IEEESTD.2016.7435228.

I assumed it was just a typo?

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Sep 2018 14:27:45 +0200

Le 19/09/2018 à 12:15, Amelia Andersdotter a écrit :
[...]
> with other similar terms last.

Sounds good, I modified it accordingly.

> I assumed it was just a typo?

I am not sure it was a typo.

There was some discussion about this number of the section in the IEEE 
document.  Some people argued about it, based on what appeared to me to 
be intermediary working IEEE documents, not fully released to the 
public.  This is moving ground.

So I removed that reference.

Alex

---

From: Amelia Andersdotter <[email-masked]>
Date: Wed, 19 Sep 2018 14:34:55 +0200

On 2018-09-19 14:27, Alexandre Petrescu wrote:
> document.  Some people argued about it, based on what appeared to me
> to be intermediary working IEEE documents, not fully released to the
You could have also put Clause 6 without subclause classifier, because
it's unlikely to change main clause (I guess)? (although it was added
only in 2010, so it's not in the 1609.4-2006 standard, for instance)

Otherwise it might be difficult to find for individuals reading the
text. Esp. if the entire reference is removed. There is some terminology
problem there as well, which I pointed out in the Problem Statement
review: the pseudonymization is known alternately as "re-addressing",
"pseudonymisation" or "randomization". But well, every document can't
solve every issue, that's how it is.

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Sep 2018 15:20:26 +0200

Le 19/09/2018 à 14:34, Amelia Andersdotter a écrit :
>>>> Ah!  For confirmation - is your 1609.4 document the IEEE 
>>>> 1609.4-2016? (i.e. the document of year 2016).
>>>> 
>>>> But looks as these versions change often.  Maybe I want to 
>>>> remove the phrase "a relevant function is described in 
>>>> [1609...] ..."
>>> 
>>> It is this one: 1609.4-2016 - IEEE Standard for Wireless Access 
>>> in Vehicular Environments (WAVE) -- Multi-Channel Operation, 
>>> Revision of IEEE Std 1609.4-2010 (Revision of IEEE Std 
>>> 1609.4-2006) cited as DOI: 10.1109/IEEESTD.2016.7435228.
>>> 
>> There was some discussion about this number of the section in the 
>> IEEE document.  Some people argued about it, based on what appeared
>> to me to be intermediary working IEEE documents, not fully released
>> to the public.  This is moving ground.
>> 
> You could have also put Clause 6 without subclause classifier, 
> because it's unlikely to change main clause (I guess)? (although it 
> was added only in 2010, so it's not in the 1609.4-2006 standard, for
>  instance)

I agree with the guessing part.

> text. Esp. if the entire reference is removed.

So you suggest to keep paragraph and remove clause, like this?

OLD:
> A relevant function is described in IEEE 1609.3-2016 [IEEE-1609.3], 
> clause 5.5.1 and IEEE 1609.4-2016 [IEEE-1609.4], clause 6.7.

NEW:
> A relevant function is described in IEEE 1609.3-2016 [IEEE-1609.3] 
> and IEEE 1609.4-2016 [IEEE-1609.4].

> There is some terminology problem there as well, which I pointed out
>  in the Problem Statement review: the pseudonymization is known 
> alternately as "re-addressing", "pseudonymisation" or 
> "randomization". But well, every document can't solve every issue, 
> that's how it is.

One can hear some vehi net talk about pseudonimisation as the use of an
equivalent identifier, like in calling someone the prince of persia
instead of true name.  Send packets to pseudonym 'car1' instead of MAC
address '00:09:0F:AA:00:01'.

Having agreement on the concept may need much work.

I will look at the psedonimisation earlier remarks in this sense.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Sep 2018 17:00:28 +0200

part 2 of addressing the Human Rights reviewer comments.

We clarified that by saying this in -28:
> 	  As recommended in <xref target='RFC5889'/>, when the timing
> 	  requirements are very strict (e.g. fast drive through IP-RSU
> 	  coverage), no on-link subnet prefix should be configured on
> 	  an 802.11-OCB interface.  In such cases, the exclusive use
> 	  of IPv6 link-local addresses is RECOMMENDED.
>
> 	  Additionally, even if the timing requirements are not very
> 	  strict (e.g. the moving subnet formed by two following
> 	  vehicles is stable, a fixed IP-RSU is absent), the subnet is
> 	  disconnected from the Internet (a default route is absent),
> 	  and the addressing peers are equally qualified (impossible
> 	  to determine that some vehicle owns and distributes
> 	  addresses to others) the use of link-local addresses is
> 	  RECOMMENDED.

> impact on addressing and IPv6 address generation, I believe they merit

What is a pseudonym?

It's easy to make a section for it.

> identifier is intended for use in networking in general, or only for

This I do not know.

At ETSI it is usual to say that every emitter of CAM messages must have 
a unique Station ID.

And, sure, every car must send CAMs.

But from there to say that the whole car is identified just by the 
Station ID there is a long way.

In the prototypes I work with there are very many identifiers.  Each is 
relevant for the particular application.

Then there is License Plate number, Vehicle Identification Number, 
insurance numbers, etc.

Then there is the IMEI of the SIMs of the cellular interface(s).

For IPv6-over-OCB - even here there is not only one MAC address, because 
there are multiple 802.11-OCB interfaces in one car.  They are so cheap 
you can put as many as you want.

I will remove Appendix F.1 "Vehicle ID".

> ## Part 2: Internationalization, accessibility and transparency

It is good.

> # Recommendations:

I collected all privacy and security in one place: the security 
considerations section.

We do have now the MAC address change and the subsequent Interface ID 
change, in Security Considerations section, as a recommendation for 
resolution of some of the privacy issues left over after RFC8064 and 
RFC7217 are referred.

For section 1: I added
> 	The Security Considerations section describes security and
> 	privacy aspects of 802.11-OCB.

> Remove the last paragraph of Section 5.

Earlier, I removed the last par of section 5.  Rewrote it largely and 
put it in a new sub-section 'Privacy Considerations' within the 
'Security Considerations' section.

Now, I created a new section 'Pseudonym Handling' at the beginning of 
section 4.  I do not know what to put inside.

> trade-offs could be expanded upon.

Well.

The use of link-local addresses are not a panacea to privacy worries. 
It could even be the reverse.

But a new method to form link-local addresses offering more privacy than 
existing privacy methods is given in this draft that is not described 
anywhere else.

As for RFC5889 forbidding LLs, I think I adressed that in other comment. 
  I made clear in the draft which case the LLs are recommended, against 
RFC5889.  This is in section 4.7 "Subnet Structure".

> parameter selection as specified in Appendix A of RFC7217.

This requires some work to understand.
It will be in part 3.

> https://tools.ietf.org/html/rfc8280

Should this RFC be referenced in the Internet Draft and how?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Sep 2018 14:40:35 +0200

This is part 3, and last, of addressing comments Human Rights.

> 4. In Section 4.3 and 4.5 it should be clarified what privacy
> benefits, if any, are expected from using semantically obscure IIDs
> as proposed in RFC7217. It will at least be relevant to clarify
> whether privacy benefits could arise in contexts that are explicitly
> out of scope (such as during forming, termination or handover), e.g.
> with respect to parameter selection as specified in Appendix A of
> RFC7217.

I propose the following NEW text to address your comment.

-----------------------------------------------------------------------

Semantically opaque Interface Identifiers, instead of meaningful
Interface Identifiers derived from a valid and meaningful MAC address
(RFC 2464, section 4), MAY be needed in order to avoid certain privacy
risks.

A valid MAC address includes a unique identifier pointing to a company
together with its postal address, and a unique number within that
company MAC space (see the oui.txt file).  The calculation operation
of the MAC address back from a given meaningful Interface Identifier
is straightforward (RFC 2464, section 4).  The Interface Identifier is
part of an IPv6 address that is stored in IPv6 packets.  The IPv6
packets can be captured in the Internet easily.  For these reasons, an
attacker may realize many attacks on privacy.  One such attack on
802.11-OCB is to capture, store and correlate Company ID information
of many cars in public areas (e.g. listen for Router Advertisements,
or IPv6 application data packets, and record the value of the source
address in these packets).  Further correlation of this information
with other data captured by other means, or other visual information
(car color, others) MAY constitute privacy risks.

In order to avoid these risks, opaque Interface Identifiers MAY be
formed according to rules described in RFC 7217.  These opaque
Interface Identifiers are formed starting from identifiers different
than the MAC addresses, and from cryptographically strong material.
Thus, privacy sensitive information is absent from Interface IDs, and
it is impossible to calculate the initial value from which the
Interface ID was calculated.

Some applications that use IPv6 packets on 802.11-OCB links (among
other link types) may benefit from IPv6 addresses whose Interface
Identifiers don't change too often.  It is RECOMMENDED to use the
mechanisms described in RFC 7217 to permit the use of Stable Interface
Identifiers that do not change within one subnet prefix.  A possible
source for the Net-Iface Parameter is a virtual interface name, or
logical interface name, that is decided by a local administrator.