Re: [Gen-art] Genart telechat review of draft-ietf-ipwave-ipv6-over-80211ocb-47 - privacy

[Alexandre Petrescu <[e-mail]>]

Le 04/07/2019 à 08:05, Roni Even via Datatracker a écrit :
> 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.

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

> 
> Nits/editorial comments:
> 
> 
>