Hi,
I understand the text makes one think the way you do.
Privacy is indeed a major issue in vehicular networks.
I dont know how to better formulate this MAC address change such as to
be ready for the future, and also be compatible with the present.
1609.4 is not implemented in all places. Those who implement 1609.4 do
not implement IPv6-over-OCB. 1609.4 implementations, such as all 1609
implementations, come with a high cost in software, hardware and
necessary skillset.
IPv6-over-OCB comes at significantly lower cost in the three.
Alex
Le 18/06/2019 à 10:40, Roni Even (A) a écrit :
Hi,
I am not a security expert, I was just trying to reflect that when
reading the document I got the impression that privacy is a major
concern since the IP-OBU is moving and its location can be traced by
sniffing the MAC addresses.
Maybe it will be good to have a security review of the document. I also
noticed that there is support in IEEE SA - 1609.4-2016 for MAC address
change.
Roni Even
*From:*Dick Roy [mailto:dickroy@xxxxxxxxxxxx]
*Sent:* Monday, June 17, 2019 10:48 PM
*To:* Roni Even (A); 'NABIL BENAMAR'; 'Roni Even'
*Cc:* gen-art@xxxxxxxx; 'IETF Discussion'; its@xxxxxxxx;
draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx
*Subject:* RE: [ipwave] [Gen-art] Genart last call review of
draft-ietf-ipwave-ipv6-over-80211ocb-46
------------------------------------------------------------------------
*From:*its [mailto:its-bounces@xxxxxxxx] *On Behalf Of *Roni Even (A)
*Sent:* Monday, June 17, 2019 6:26 AM
*To:* NABIL BENAMAR; Roni Even
*Cc:* gen-art@xxxxxxxx <mailto:gen-art@xxxxxxxx>; IETF Discussion;
its@xxxxxxxx <mailto:its@xxxxxxxx>;
draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx
<mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx>
*Subject:* Re: [ipwave] [Gen-art] Genart last call review of
draft-ietf-ipwave-ipv6-over-80211ocb-46
Thanks,
The only comment left is:
2. In section 5.2 "The policy dictating when the MAC address is changed
on the
802.11-OCB interface is to-be-determined.". Reading the next sentence it
looks
to me that this is needed as part of the solution and should not be left for
the unknown future.
Should we reformulate here?
I was expecting some recommendation since the changing of MAC address is
important to address privacy issues (discussed in section 5). Currently
it is left open with no recommendation , only saying that dynamic change
of MAC address is needed.
Maybe the document should have some normative language for example in
section 5.1 that will say that IP-OBU MUST dynamic change their MAC
addresses
*/[RR] I highly recommend AGAINST this! There will be a number OBU and
RSU implementations that DO NOT require anonymity, and don’t want it
either. Furthermore, immutable identifier change must be coordinated
with all other interfaces and protocols otherwise changing them is
useless./*
Did the document go through security area review?
*/[RR] If it did, and the above was not mentioned, then something was
missed./*
Roni
*From:*Gen-art [mailto:gen-art-bounces@xxxxxxxx] *On Behalf Of *NABIL
BENAMAR
*Sent:* Monday, June 17, 2019 12:48 PM
*To:* Roni Even
*Cc:* gen-art@xxxxxxxx <mailto:gen-art@xxxxxxxx>; IETF Discussion;
its@xxxxxxxx <mailto:its@xxxxxxxx>;
draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx
<mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx>
*Subject:* Re: [Gen-art] Genart last call review of
draft-ietf-ipwave-ipv6-over-80211ocb-46
Dear Roni,
Thank you for your review.
Please, see my answers below.
On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracker <noreply@xxxxxxxx
<mailto:noreply@xxxxxxxx>> wrote:
Reviewer: Roni Even
Review result: Almost Ready
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 treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-ipwave-ipv6-over-80211ocb-??
Reviewer: Roni Even
Review Date: 2019-06-16
IETF LC End Date: 2019-06-26
IESG Telechat date: Not scheduled for a telechat
Summary:
The document is almost ready for publication as a standard track RFC
Major issues:
Minor issues:
1. Section 4.2 says "IP packets MUST be transmitted over 802.11-OCB
media as
QoS Data" while appendix F say "The STA may send data frames of
subtype Data,
Null, QoS Data, and
QoS Null.
I will update the appendix to reflect the text in section 4.2.
2. In section 5.2 "The policy dictating when the MAC address is
changed on the
802.11-OCB interface is to-be-determined.". Reading the next
sentence it looks
to me that this is needed as part of the solution and should not be
left for
the unknown future.
Should we reformulate here?
3. In Appendix I 4th paragraph " However, this does not apply if TBD
TBD TBD. "
... What are the TBDs?
The whole sentence will be removed.
Nits/editorial comments:
1. In appendix I last paragraph "Support of RFC 8505 is may be
implemented on
OCB." should be "Support of RFC 8505 may be implemented on OCB." 2.
In Appendix
I "OCB nodes that support RFC 8505 would support the 6LN operation
in order to
act as a host". I think that instead of "would" it should be
"should" also if
this is a recommendation why not have this paragraph not in an
appendix with
"MAY" and "SHOULD
Agreed.
