Because of the non-plain text and the commenting styles used, I am unclear who wrote what below, but please see my comment in line: On 23-Jun-19 18:18, Roni Even (A) wrote: > > Inline > > ________________________________ > From: Roni Even (A) [mailto:roni.even@xxxxxxxxxx] > Sent: Tuesday, June 18, 2019 1:41 AM > To: dickroy@xxxxxxxxxxxx<mailto:dickroy@xxxxxxxxxxxx>; '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 > > 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. > [RR] FYI ... there is no such thing as an IP-OBU unless this group chooses to define one. I highly recommend against it for a variety of reasons including adding a network protocol identifier in front of a device identifier makes no sense. > > [RE] IP-OBU is defined in section 2 and is used in 5.1 when discussing privacy > > > 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. > > [RR] Yes, but it does NOT make such changes mandatory! I made sure of that for the same reasons stated below. The draft says, in section 5: For this reason, in the 802.11-OCB deployments, there is a strong necessity to use protection tools such as dynamically changing MAC addresses Section 5.2, semantically opaque Interface Identifiers and stable Interface Identifiers Section 4.4. This may help mitigate privacy risks to a certain level. I'm not quite sure how "strong necessity" relates to RFC2119 terminology, but the current text seems to say that changing MAC addresses is at least RECOMMENDED. Also the quoted text is very hard to parse. Does "semantically opaque" qualify "Interface Identifiers" or "Interface Identifiers and stable "Interface Identifiers"? And how do stable Interface Identifiers help to protect privacy? (FYI, the data tracker does show that a SECDIR review has been requested.) Regards Brian Carpenter > > > > 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<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 > > > > ________________________________ > 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. > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art >
