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!
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:
Best Regards
