Subject: [ipwave] Alissa Cooper's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Wed, 10 Jul 2019 11:27:22 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-ipwave-ipv6-over-80211ocb-49: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Roman's DISCUSS.

Overall I am unclear on the privacy properties of what this document specifies.
I think it would help to have a clear statement about the circumstances under
which each kind of address generation scheme is recommended. Were RFC 4941
addresses not considered because addresses generated according to RFC 8064 have
functionally equivalent properties given how often moving vehicle change
subnets? For link-local addresses, is it possible to give recommendations for
when IIDs should be re-generated?

= Section 5.2 =

"An Interface ID SHOULD be of length specified in other documents."

Isn't the length specified for each of the two IID generation mechanisms
discussed in Section 4.3 and 4.4?

= Section 5.3 =

"The demand for privacy protection of vehicles' and drivers'
   identities, which could be granted by using a pseudonym or alias
   identity at the same time, may hamper the required confidentiality of
   messages and trust between participants"

Pseudonymity and confidentiality are not mutually exclusive, so I think this is
incorrect.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please expand OCB and STA on first use.

= Section 2 =

"Note: compliance with
   standards and regulations set in different countries when using the
   5.9GHz frequency band is required."

I'm not familiar with the standards and regulations being referenced here, but
is there any specific reason why this needs to be said here? Presumably users
of regulated spectrum bands the world over must comply with associated
regulations governing their use. It's not clear to me that it makes sense to
note this here.

= Section 5.1.1 =

"Further
   correlation of this information with other data captured by other
   means, or other visual information (car color, others) MAY constitute
   privacy risks."

The normative MAY is not appropriate here.

= Section 5.2 =

"In 802.11-OCB networks, the MAC addresses MAY change during well
   defined renumbering events."

The normative MAY is not appropriate here (since this is not the 802.11-OCB
spec).

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 10 Jul 2019 21:57:25 +0100

Hi Alissa,

Thanks again for your review. Please see my answers below

On Wed, Jul 10, 2019 at 7:27 PM Alissa Cooper via Datatracker <
[email-masked]> wrote:

> Here is the new text in -49

An example of change policy is to change the MAC
   address of the OCB interface each time the system boots up.  This may
   help mitigate privacy risks to a certain level.  Futhermore, for
   pricavy concerns ([RFC8065 <https://tools.ietf.org/html/rfc8065>])
recommends using an address generation
   scheme rather than addresses generated from a fixed link-layer

   address.

> discussed in Section 4.3 and 4.4?

We decided to remove this sentence from the text since ther is no other
document.

> Pseudonymity and confidentiality are not mutually exclusive, so I think

I agree.

-- 

Best Regards

Nabil Benamar
Associate Professor
Department of Computer Sciences
School of Technology
Moulay Ismail University
Meknes. Morocco

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 11 Jul 2019 09:52:08 -0400

Hi Nabil,

> On Jul 10, 2019, at 4:57 PM, Nabil Benamar <[email-masked]> wrote:
> 
> Hi Alissa,
> 
> On Wed, Jul 10, 2019 at 7:27 PM Alissa Cooper via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ <https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/>
> 
> 
> 
>    pricavy concerns ([RFC8065 <https://tools.ietf.org/html/rfc8065>]) recommends using an address generation

I saw this when I read the document but it doesn’t address my questions above. Also in your email to Roni you mentioned other environmental factors that might trigger a change in link-local address, so I was hoping to see that in the document text.

Thanks,
Alissa

> We decided to remove this sentence from the text since ther is no other document.
> 
> = Section 5.3 =
>

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 11 Jul 2019 15:25:31 +0100

Hi Alissa,

Are you referring to this text that may be added to the document?

"However, there are some specificities related to vehicles. Since they roam
a lot, the use of the same Link-Local Address over time can leak the
presence of the same vehicle in multiple places. Location tracking, if the
same interface identifier is used with different prefixes as a
device/vehicle moves between different networks."

On Thu, Jul 11, 2019 at 2:52 PM Alissa Cooper <[email-masked]> wrote:

> I saw this when I read the document but it doesn’t address my questions
> above. Also in your email to Roni you mentioned other environmental factors
> that might trigger a change in link-local address, so I was hoping to see
> that in the document text.
>
> Thanks,
> Alissa
>
>
>
>> = Section 5.2 =
>>

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Jul 2019 13:02:37 +0200

This is a difficult thing to do, and it needs some long reflection on my
side.  But I would like to help progress the document.

Allow me to group below the privacy-related quotations from Alissa
Cooper, Barry Leiba and Roman Danyliw.  This is in order to reduce the
number of emails that I send.

Le 10/07/2019 à 20:27, Alissa Cooper via Datatracker a écrit :
[...]

Basically, at this stage the situation is that there are privacy issues
with talking cars and talking Road-Side Units.  These issues can be
witnessed in all IP car trials that I looked at.

They come from:
- lack of implementation of RFC7217 ('privacy' IIDs) in the embedded
   computers.  To my knowledge no embedded linux displays obfuscated
   (random) IIDs in IP LL addresses when typing ifconfig command.
- lack of common recommendation of how to generate a more obfuscated MAC
   address ('random').  There is a recommendation at ETSI ITS, a
   recommendation at Microsoft, and a recommendation at IEEE.  These
   three distinct recommendations are supposedly different.  Others may
   disagree.
- unknowns about the IPR status of the MAC generation techniques.
   The places to explore are Microsoft, ETSI and IEEE.  There are some
   clarifications I received in private from something about Microsoft,
   but more exploration is needed.  BEcause, on my side, I do not want to
   put here a method of MAC address generation that is protected by
   somebody else.

> I think it would help to have a clear statement about the 
> circumstances under which each kind of address generation scheme is 
> recommended.

After much reflection, I express I agree with the need.  It would be so
much helpful for implementer reading an RFC to see an algorithm in front
of his eyes telling what to implement, and what to not care about.

The recommendation could be something like this: if on your embedded
platform the RFC 7217 (privacy IIDs) implementation is available then
use it all while making sure the changes in IIDs dont break your
application; if they do, dont use it, and inform users there are
Privacy risks.

And I have some doubts.  I often fear that it is not because we make 
MUST RFC 7217 that it becomes implemented.  There are good reasons from 
implementers not to implement it.

Others think the contrary: put the MUST RFC 7217 in the I-D and the 
implementers will have to.

So, I am some times tempted to just reflect the current situation (there
is no privacy) and develop later a method to protect.

But it is just my thoughts.  Others may have another oppinion, that I am
curious to learn.

> Were RFC 4941 addresses not considered because addresses generated 
> according to RFC 8064 have functionally equivalent properties given 
> how often moving vehicle change subnets?

YEs, that is one reason why.

There are more reasons:
- rfc 4941 (privacy addresses) are not implemented in many embedded
systems.  rfc 4941 and rfc 7217 (privacy addresses) are implemented
mainly in BSD and derivatives; these BSD flavors do not implement OCB;
given the choice, BSD is not used.  There are other OSs specific to 
embedded systems, and none has MAC address generations schemes, as far 
as I know.

- stable link-local addresses are needed when forming subnets of cars,
because there are routing table entries with next hop values that must
stay stable.  (worse, they should be easily remembered by humans in the
beginning, and even the LL addresses EUI64 are hard to work with).

> For link-local addresses, is it possible to give recommendations for

It is possible.

On my side I do not want to do it (re-generate), because I have never
tried to regenerate.  I do not want it.

There are groups of people at ETSI and some trials that do consider
re-generations of LL address.  This implies re-generatin of certificates
as well.  These certificates are not openly available; they depend on
closed-circuit CAs.  They are hard to test and dont scale to large
sizes.  They are hard to access.

I do not want to get in the way of satisfying the request of giving
recommendations for when IIDs should be re-generated.  Maybe a
recommendation should be given by somebody trying it.

Barry Leiba wrote recently:
>>>> If semantically opaque IIDs are needed, they MAY be generated 
>>>> using the method for generating semantically opaque IIDs
>>> 
>>> This isn’t wrong with the “MAY”, but I think it really is just a
>>>  non-keyword “may”.

I tend to agree.  It is a non-keyword 'may'.

>>>> In 802.11-OCB networks, the MAC addresses MAY change during 
>>>> well defined renumbering events.
>>> 
>>> Also a statement of fact, so “may”.

I agree.

Roman Danyliw wrote recently:
> ** What specific ETSI protocols are being recommended from
> [ETSI-sec-archi]?

I do not know for sure myself.  One would ask Jérôme Härri.

I looked myself at the public document referred (ETSI TS 102 940 V1.2.1
(2016-11)).  I could find a recommendation to generate MAC address:
"shall be derived from the identifier provided by the Security Entity in
the ID change notification".  (the "ID Change Notification" seems to be
an application layer message).

 From my side, I do not agree with this method to generate more
obfuscated MAC addresses.

I have some ideas how to generate more obfuscated MAC addresses, but
certainly not in that ETSI way.

> ** What is meant by the drivers’ identity in this case?

There is activity at Gemalto now Thales about e-Driver's License.
Supposedly that is an electronic format of a driver's license that is
more accessible.  I think that driver's license in some countries have
no electronic equivalent at this time.

The trials of electronic Driver's License happened mostly in America,
and were probably totally absent in Europe.

That is all I know.

> What is the pseudonym scheme is being used to protect it or what
> requirements are being set for it?

I do not know myself.

> ** What are the specific challenges of concern around
> pseudo-anonymization approaches to which an allusion is made?
> 
> ** Who is the trusted third parted needed?

There is no trusted third party in the automotive networks.  There are a
few efforts to build national Certificate Authorities, European
automotive PKIs, and similar.  Most are backed by trials.  But there is
no universally agreed CA (like is e.g. Verisign in the Internet world).
  They are all expensive to access, and some times even impossible.

What is needed is that the automotive networks use the CAs from Internet.

What is needed is that the automotive networks use the CAs from Internet.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Jul 2019 16:48:18 +0200

Le 11/07/2019 à 16:25, Nabil Benamar a écrit :
> "However, there are some specificities related to vehicles. Since
> they roam a lot, the use of the same Link-Local Address over time can
> leak the presence of the same vehicle in multiple places. Location
> tracking, if the same interface identifier is used with different
> prefixes as a device/vehicle moves between different networks."

Expressing the need of change of Link-local Address of an OCB interface
of an automobile in order to ensure privacy should be accompanied with
expressing the need of keeping Link-local Address stable next-hop of
routing table entry in nearby automobile.

The routing works like this: an Automobile holds a routing table entry
whose next-hop field contains the link-local address of the nearby
Automobile.  If that link-local address changes, then the two
Automobiles can no longer talk to each other.

So yes, change the LL address to ensure privacy and dodge the attackers,
but no, do not change it - i.e. keep it stable - otherwise the
legitimate users will be disconnected.

Alex

> 
> On Thu, Jul 11, 2019 at 2:52 PM Alissa Cooper <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Hi Nabil,
> 
>> On Jul 10, 2019, at 4:57 PM, Nabil Benamar <[email-masked]
>> <mailto:[email-masked]>> wrote:
>> 
>> Hi Alissa,
>> 
>> On Wed, Jul 10, 2019 at 7:27 PM Alissa Cooper via Datatracker 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to 
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer 
>> tohttps://www.ietf.org/iesg/statement/discuss-criteria.html for
>> more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> 
>> Overall I am unclear on the privacy properties of what this 
>> document specifies. I think it would help to have a clear statement
>> about the circumstances under which each kind of address generation
>> scheme is recommended. Were RFC 4941 addresses not considered
>> because addresses generated according to RFC 8064 have functionally
>> equivalent properties given how often moving vehicle change 
>> subnets? For link-local addresses, is it possible to give 
>> recommendations for when IIDs should be re-generated?
>> 
>> An example of change policy is to change the MAC address of the OCB
>> interface each time the system boots up. This may help mitigate
>> privacy risks to a certain level. Futhermore, for pricavy concerns
>> ([RFC8065 <https://tools.ietf.org/html/rfc8065>]) recommends using
>> an address generation scheme rather than addresses generated from a
>> fixed link-layer address.
>> 
> 
> I saw this when I read the document but it doesn’t address my 
> questions above. Also in your email to Roni you mentioned other 
> environmental factors that might trigger a change in link-local 
> address, so I was hoping to see that in the document text.
> 
> Thanks, Alissa
> 
>> = Section 5.2 =
>> 
>> Isn't the length specified for each of the two IID generation 
>> mechanisms discussed in Section 4.3 and 4.4?
>> 
>> 
>> identity at the same time, may hamper the required confidentiality
>> of messages and trust between participants"
>> 
>> Pseudonymity and confidentiality are not mutually exclusive, so I
>> think this is incorrect.
>> 
>> 
>> I agree.
>> 
>> 
>> 
>> 
>> = Section 2 =
>> 
>> "Note: compliance with standards and regulations set in different
>> countries when using the 5.9GHz frequency band is required."
>> 
>> I'm not familiar with the standards and regulations being 
>> referenced here, but is there any specific reason why this needs to
>> be said here? Presumably users of regulated spectrum bands the
>> world over must comply with associated regulations governing their
>> use. It's not clear to me that it makes sense to note this here.
>> 
>> = Section 5.1.1 =
>> 
>> "Further correlation of this information with other data captured
>> by other means, or other visual information (car color, others)
>> MAY constitute privacy risks."
>> 
>> The normative MAY is not appropriate here (since this is not the
>> 802.11-OCB spec).
>> 
>> 
>> 
>> 
>> --
>> 
>> Best Regards
>> 
>> Nabil Benamar Associate Professor Department of Computer Sciences 
>> School of Technology Moulay Ismail University Meknes. Morocco
> 
> 
> 
> --
> 
> Best Regards
> 
> Nabil Benamar Associate Professor Department of Computer Sciences 
> School of Technology Moulay Ismail University Meknes. Morocco
> 
> 
> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Jul 2019 16:46:37 +0200

Hi,

Sorry for following up on my own message, but I will be brief, and stop 
after it.

Le 12/07/2019 à 13:02, Alexandre Petrescu a écrit :
[...]
>    The places to explore are Microsoft, ETSI and IEEE.

I did some search.

The writer of the method 'MAC Address Generation' in the draft confirmed 
to me by email that he had no IPR claims on this method, even though he 
separates his reponsibility from others' (he cant realistically know 
what others do, which is obvious).

The ETSI ipr.etsi.org portal search on TS 102941 (the document that 
specifies the means to generate a privacy MAC address) issues no results.

The IPR search on qpat issues several IPRs when the title keyword is 
"MAC Address Generation".  Some of these methods, e.g. "CN105430118  B" 
or "JP2012222709  A", have an abstract that approaches a lot to what 
this method in IPv6-over-OCB does, even though there are differences in 
the number of bits used.

For IEEE I do not know how to search IPR status and I surelyt dont have 
necessary credentials.

I am not trained as a technical patent specialist, so that's how I see it.

For reminder, the MAC Address generation in IPv6-over-OCB draft is:
>   A 'randomized' MAC address has the following characteristics:
> 
>    o  Bit "Local/Global" set to "locally admninistered".
> 
>    o  Bit "Unicast/Multicast" set to "Unicast".
> 
>    o  The 46 remaining bits are set to a random value, using a random
>       number generator that meets the requirements of [RFC4086].

This is the best I could do for this IPR topic, I stop here.

Alex

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 17 Jul 2019 14:20:15 -0400

Hi Nabil,

> On Jul 11, 2019, at 10:25 AM, Nabil Benamar <[email-masked]> wrote:
> 
> Hi Alissa,
> 
> "However, there are some specificities related to vehicles. Since they roam a lot, the use of the same Link-Local Address over time can leak the presence of the same vehicle in multiple places. Location tracking, if the same interface identifier is used with different prefixes as a device/vehicle moves between different networks.”

That was part of it. I think this was the full text:

"However, there are some specificities related to vehicles. Since they roam a lot, the use of a same Link Local Address over time can leak the presence of the same vehicle in multiple places. Location tracking, if the same interface identifier is used with different prefixes as a device/vehicle moves between different networks.

Hence, a vehicle should get hints about a change of environment (e.g. , engine running, GPS, whatever) and renew the IID in LLAs.

I can make these proposed changes in a separate sub-section to emphasize the concern and fix the privacy issue."

I think to the extent there are hints the vehicle would use to trigger a refresh of the IID, that idea is worth mentioning.

Thanks,
Alissa

> 
> On Thu, Jul 11, 2019 at 2:52 PM Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Nabil,
> 
>> On Jul 10, 2019, at 4:57 PM, Nabil Benamar <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Alissa,
>>

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 17 Jul 2019 21:42:57 +0100

Hi Alissa,

Thank you for your reply.

What do you think of adding the following paragraph:

However, there are some specificities related to vehicles. Since roaming is
an important characteristic of vehicles, the use of the same Link-Local
Address over time can indicate the presence of the same vehicle in
different places and thus leads to location tracking. Hence, a vehicle
should get hints about a change of environment (e.g. , engine running, GPS,
etc..) and renew the IID in its LLAs.

On Wed, Jul 17, 2019 at 7:20 PM Alissa Cooper <[email-masked]> wrote:

> "However, there are some specificities related to vehicles. Since they
> roam a lot, the use of the same Link-Local Address over time can leak the
> presence of the same vehicle in multiple places. Location tracking, if
> the same interface identifier is used with different prefixes as a
> device/vehicle moves between different networks.”
>
>
> "However, there are some specificities related to vehicles. Since they
> roam a lot, the use of a same Link Local Address over time can leak the
> presence of the same vehicle in multiple places. Location tracking, if
> the same interface identifier is used with different prefixes as a
> device/vehicle moves between different networks.
>
>
> Hence, a vehicle should get hints about a change of environment (e.g. ,
> engine running, GPS, whatever) and renew the IID in LLAs.
>
>
>
> I think to the extent there are hints the vehicle would use to trigger a
> refresh of the IID, that idea is worth mentioning.
>
> Thanks,
> Alissa
>
>
>>> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> 802.11-OCB

-- 

Best Regards

Nabil Benamar
Associate Professor