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

[Alexandre Petrescu <[e-mail]>]

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:[e-mail]] On Behalf Of Alexandre Petrescu
> Sent: Tuesday, June 18, 2019 3:24 AM
> To: Roni Even (A)
> Cc: [e-mail]; [e-mail]
> 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:[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.
>>>
>>
>>
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
> 
>