Le 18/06/2019 à 18:19, Dick Roy a écrit :
It is not up to the IETF to make ANY statement about when a MAC address
should be changed! It is a system issue, and the system is MYCH BIGGER than
any single interface and the protocols over that interface. Making any such
requirements is foolish at best.
I tend to agree.
With respect to QoS aspects, a potential way is for IPv6-over-OCB to
specify what goes into IPv6 Traffic Class field and how that value may
get mapped into a 802.11 QoS priority value.
Alex
-----Original Message-----
From: its [mailto:its-bounces@xxxxxxxx] On Behalf Of Alexandre Petrescu
Sent: Tuesday, June 18, 2019 3:24 AM
To: Roni Even (A)
Cc: ietf@xxxxxxxx; its@xxxxxxxx
Subject: Re: [ipwave] [Gen-art] Genart last call review of
draft-ietf-ipwave-ipv6-over-80211ocb-46
It is a good idea. It would unlock an important issue in the IPWAVE WG.
Le 18/06/2019 à 11:26, Roni Even (A) a écrit :
Hi, Maybe use similar language as in
https://tools.ietf.org/id/draft-ietf-ipwave-vehicular-networking-09.txt
For the protection of drivers' privacy, the pseudonym of a MAC
address of a vehicle's network interface should be used, with the
help of which the MAC address can be changed periodically.
YEs, and use 'MAY' instead of 'should'.
I only found the sentence " The policy dictating when the MAC address
is changed on the 802.11-OCB interface is to-be-determined" as too
weak.
I agree, it begs for clarification.
Alex
Roni
-----Original Message----- From: ietf [mailto:ietf-bounces@xxxxxxxx]
On Behalf Of Alexandre Petrescu Sent: Tuesday, June 18, 2019 12:10
PM To: ietf@xxxxxxxx Subject: Re: [ipwave] [Gen-art] Genart last call
review of draft-ietf-ipwave-ipv6-over-80211ocb-46
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.
_______________________________________________
its mailing list
its@xxxxxxxx
https://www.ietf.org/mailman/listinfo/its
