Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46

[Alexandre Petrescu <[e-mail]>]

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:[e-mail]]
> On Behalf Of Alexandre Petrescu Sent: Tuesday, June 18, 2019 12:10
> PM To: [e-mail] 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:[e-mail]] *Sent:* Monday, June
>> 17, 2019 10:48 PM *To:* Roni Even (A); 'NABIL BENAMAR'; 'Roni
>> Even' *Cc:* [e-mail]; 'IETF Discussion'; [e-mail]; 
>> [e-mail] *Subject:* RE:
>> [ipwave] [Gen-art] Genart last call review of 
>> draft-ietf-ipwave-ipv6-over-80211ocb-46
>> 
>> ----------------------------------------------------------------------
>>
>> 
--
>> 
>> *From:*its [mailto:[e-mail]] *On Behalf Of *Roni Even
>> (A) *Sent:* Monday, June 17, 2019 6:26 AM *To:* NABIL BENAMAR; Roni
>> Even *Cc:* [e-mail] <mailto:[e-mail]>; IETF
>> Discussion; [e-mail] <mailto:[e-mail]>; 
>> [e-mail] 
>> <mailto:[e-mail]> 
>> *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:[e-mail]] *On Behalf Of
>> *NABIL BENAMAR *Sent:* Monday, June 17, 2019 12:48 PM *To:* Roni
>> Even *Cc:* [e-mail] <mailto:[e-mail]>; IETF
>> Discussion; [e-mail] <mailto:[e-mail]>; 
>> [e-mail] 
>> <mailto:[e-mail]> 
>> *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 
>> <[e-mail] <mailto:[e-mail]>> 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.
>> 
> 
>