Subject: Genart telechat review of draft-ietf-ipwave-ipv6-over-80211ocb-47

From: Roni Even via Datatracker <[email-masked]>
Date: Wed, 03 Jul 2019 23:05:36 -0700

Reviewer: Roni Even
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ipwave-ipv6-over-80211ocb-47
Reviewer: Roni Even
Review Date: 2019-07-03
IETF LC End Date: None
IESG Telechat date: 2019-07-11

Summary:
The document is ready to be published as a standard track RFC with an issue

Major issues:

Minor issues:

this is about my previous comment.
The text in section 5.1 "A vehicle embarking  an IP-OBU whose egress interface
is 802.11-OCB may expose itself to  eavesdropping and subsequent correlation of
data; this may reveal data considered private by the vehicle owner; there is a
risk of being tracked.  In outdoors public environments, where vehicles
typically circulate, the privacy risks are more important than in indoors
settings." and "there is a strong necessity to use protection tools such  as
dynamically changing MAC addresses"
 so even though there are privacy concerns there is no normative text saying
 that some method is needed. "strong necessity" is not normative .

A new sentence was added to section 5.1 "An example of change policy is to
change the MAC address of the OCB interface each time the system boots up"

I got more confused by section 5.2 text "The policy dictating when the MAC
address is changed on the 802.11-OCB interface is to-be-determined."

So what I got from section 5.1 and 5.2 is that protection tools to address
privacy concern are needed but without any normative text.  Dynamic changing 
of MAC address is an option, no other option is mentioned.  Example for when to
change MAC address is on system boot and the policy when to change MAC address
is to be determined.

To summarize what the document currently says is that privacy risks are more
important for outdoor public environment and it is left for implementations to
decide if and how to address it.

Nits/editorial comments:

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 4 Jul 2019 10:00:04 +0200

> decide if and how to address it.

Thank you for the comment.

In a sense, I agree with you: normative text is always helpful for 
implementer.  S/he will know what method for privacy of IID MUST be 
implemented, and do it.

However, I do not want to work on this because of the following: (1) the 
random MAC generation has an unknown IPR status (to me) and (2) the 
64bit IID length is imposed.

This draft imposes a 64bit for the IID length.  Given that, it is 
impossible for me personally to make sense about what should be 
implemented for privacy for IID.  I have several methods in mind, and I 
can get help from implementer to test and demonstrate.  But not within 
the upper and lower bounds of the 64bit boundaries.

Shorter than 64bit IIDs (like ::1, or ::5) are easier to manipulate by 
humans when building systems, and they can be obfuscated as well: 
instead of saying '1' one can say '2' so the listener is fooled, 
provided a secret agreement between the ends is in place.  Also, longer 
IIDs (like ::1:2:3:4:5) resist better to brute force algorithm attacks.

There is a method for generating the MAC address in a more random 
manner, and use it to form a 64bit IID.  That method is implemented 
widely in Windows on PC and on Windows Phone.  There is also an ETSI 
standard that suggests the same.  This draft IPv6-over-OCB has that 
method in mind when it talks about changing the MAC address each time a 
system boots up.  However, I do not know the IPR status of that method. 
I would like to know it, because personally I dont want to work on 
documents that are IPRed by other organisations.  It is also for this 
reason that it says 'a possibility is', and not 'MUST do'.

Finally, having retired my name from the author list, please consider 
these comments as an individual opinion.  The fact that I state it with 
certainty does not mean any form of authority on the document.  There is 
a WG for authority, an Editor, etc. (see IPWAVE WG).

I do not know what others think about privacy and IIDs and IPv6-over-OCB?

Alex

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 5 Jul 2019 09:41:10 +0100

Dear Roni,

Thank you for your review. Indeed, you raised a crucial privacy issue that
we need to tackle in this draft.

If we look at https://tools.ietf.org/html/rfc8065 which recommends the
generic https://tools.ietf.org/html/rfc8064, we can say that we  comply by
inheritance from Ethernet since our current draft is targeted at using the
RFC 2464 (plus IPv6 suite over Ethernet) with minimal changes, as we
mention in the abstract (...for using IPv6 to communicate among nodes in
range of

   one another over a single IEEE 802.11-OCB link *with minimal change to *

*   existing stacks*).

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.

Thank you!

-- 

Best Regards

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

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 10 Jul 2019 14:29:13 -0400

Roni, thanks for your review. Alex, Nabil, thanks for your responses. I entered a DISCUSS ballot to try to get more clarity about the relationship between MAC address changes and IID changes, among other things.

Alissa

> On Jul 4, 2019, at 2:05 AM, Roni Even via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Roni Even
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

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

Hi Alissa,

Thank you for your review. However, I have updated the draft and now it's
in -49 reflecting previous comments.

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

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

> Roni, thanks for your review. Alex, Nabil, thanks for your responses. I
> entered a DISCUSS ballot to try to get more clarity about the relationship
> between MAC address changes and IID changes, among other things.
>
> Alissa
>
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 10 Jul 2019 20:44:27 +0000

Hi Nabil,
  Roni's telechat review is for the version on which I issued the ballot (in this case it is -47). If you think the issue is resolved in a later version (I do not believe so in this case), you can respond to point out the actual text change that you made to address Roni’s comment.

Thanks
Suresh

On Jul 10, 2019, at 4:38 PM, Nabil Benamar <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alissa,

Thank you for your review. However, I have updated the draft and now it's in -49 reflecting previous comments.

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

On Wed, Jul 10, 2019 at 7:29 PM Alissa Cooper <[email-masked]<mailto:[email-masked]>> wrote:
Roni, thanks for your review. Alex, Nabil, thanks for your responses. I entered a DISCUSS ballot to try to get more clarity about the relationship between MAC address changes and IID changes, among other things.

Alissa

> On Jul 4, 2019, at 2:05 AM, Roni Even via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
>
> Reviewer: Roni Even
> [email-masked]<mailto:[email-masked]>

_______________________________________________
its mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 10 Jul 2019 16:47:04 -0400

I reviewed the -49 version so my questions are on that version.
Alissa

> On Jul 10, 2019, at 4:44 PM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Nabil,
>> On Jul 10, 2019, at 4:38 PM, Nabil Benamar <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Alissa,
>> 
>> On Wed, Jul 10, 2019 at 7:29 PM Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
>> > On Jul 4, 2019, at 2:05 AM, Roni Even via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
>> > 
>> > Reviewer: Roni Even
>> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
>> > 
>> > [email-masked] <mailto:[email-masked]>
>> > https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
>

---

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

Dear Alissa,

I have previously replied to Roni as follows:

*   existing stacks*).

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.

and then I updated the to -49 by adding this text: "Furthermore, 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."

When I got no further comment from Roni, I thought it was resolved!

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

On Wed, Jul 10, 2019 at 9:47 PM Alissa Cooper <[email-masked]> wrote:

>   Roni's telechat review is for the version on which I issued the ballot
> (in this case it is -47). If you think the issue is resolved in a later
> version (I do not believe so in this case), you can respond to point out
> the actual text change that you made to address Roni’s comment.
>
> Thanks
> Suresh
>
> On Jul 10, 2019, at 4:38 PM, Nabil Benamar <[email-masked]> wrote:
>
> Hi Alissa,
>

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 18 Jul 2019 05:00:13 +0000

Hi,
I still do not think that the following sentence in section 5.2 text "The policy dictating when the MAC address is changed on the 802.11-OCB interface is to-be-determined." make sense. I think that a sentence that will say
“implementations should use a policy dictating when the MAC address is changed on the 802.11-OCB interface”

Roni

From: Gen-art [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: Wednesday, July 10, 2019 11:47 PM
To: Suresh Krishnan
Cc: [email-masked] Discussion; [email-masked]; Gen art; [email-masked]; Nabil Benamar
Subject: Re: [Gen-art] [ipwave] Genart telechat review of draft-ietf-ipwave-ipv6-over-80211ocb-47

On Jul 10, 2019, at 4:44 PM, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:

Hi Nabil,

Thanks
Suresh

Hi Alissa,

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

Alissa

> that some method is needed. "strong necessity" is not normative ..
>

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 18 Jul 2019 08:38:47 +0100

Hi Roni,

Thank you for your comment. I will reflect it in the new version.

On Thu, Jul 18, 2019 at 6:00 AM Roni Even (A) <[email-masked]> wrote:

> Hi,
>
> I still do not think that the following sentence in section 5.2 text "The
> policy dictating when the MAC address is changed on the 802.11-OCB
> interface is to-be-determined." make sense. I think that a sentence that
> will say
>
> *From:* Gen-art [mailto:[email-masked]] *On Behalf Of *Alissa
> Cooper
> *Sent:* Wednesday, July 10, 2019 11:47 PM
> *To:* Suresh Krishnan
> *Cc:* [email-masked] Discussion; [email-masked]; Gen art;
> [email-masked]; Nabil Benamar
> *Subject:* Re: [Gen-art] [ipwave] Genart telechat review of
> draft-ietf-ipwave-ipv6-over-80211ocb-47
>
>
>

-- 

Best Regards

Nabil Benamar
Associate Professor