Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

[Jong-Hyouk Lee <[e-mail]>]

Agree.
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: [e-mail]
#webpage: https://sites.google.com/site/hurryon

> 2019. 4. 12. 오후 11:59, Sri Gundavelli (sgundave) <[e-mail]> 작성:
> 
> If you go back and check 2017 archives, I did raise many of these issues.  But, we clearly decided to limit the scope excluding address configuration, DAD, ND aspect, link models. When there is such a scope statement, it should clearly move these comments to the draft that defines how ND works for 802.11-OCB links.
> 
> 
> https://mailarchive.ietf.org/arch/msg/its/9NvUfRigGd4Klu0Q2Ee-63ziATw <https://mailarchive.ietf.org/arch/msg/its/9NvUfRigGd4Klu0Q2Ee-63ziATw>
> 
> https://mailarchive.ietf.org/arch/msg/its/VcrwNSvNJVIZNcRLNjDY0iSw3CA <https://mailarchive.ietf.org/arch/msg/its/VcrwNSvNJVIZNcRLNjDY0iSw3CA>
> 
> Sri
> 
> 
> 
> 
> From: its <[e-mail] <mailto:[e-mail]>> on behalf of Sri Gundavelli <[e-mail] <mailto:[e-mail]>>
> Date: Friday, April 12, 2019 at 7:38 AM
> To: Nabil Benamar <[e-mail] <mailto:[e-mail]>>, "Pascal Thubert (pthubert)" <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Nabil Benamar <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Alexandre Petrescu <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
> 
> I am not following these discussions.  From my point of view, many of the discussions are totally out of scope for this document.
> 
> Some one needs to moderate these discussions. 
> 
> Sri
> 
> 
> 
> From: its <[e-mail] <mailto:[e-mail]>> on behalf of Nabil Benamar <[e-mail] <mailto:[e-mail]>>
> Date: Friday, April 12, 2019 at 7:34 AM
> To: "Pascal Thubert (pthubert)" <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Nabil Benamar <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Alexandre Petrescu <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
> 
> Hello Pascal,
> 
> I seconded Akex and would like to suggest you to add the missing text in the draft. 
> 
> Best regards
> Nabil
> 
>    
> 
> On Mon, Apr 8, 2019, 14:01 Pascal Thubert (pthubert) <[e-mail] <mailto:[e-mail]>> wrote:
>> Hello Nabil.
>>  
>> You will get a number of IESG reviews as part of the submission process, one per area. This is just a beginning…
>>  
>> Cheers,
>>  
>> Pascal
>>  
>> From: NABIL BENAMAR <[e-mail] <mailto:[e-mail]>> 
>> Sent: lundi 8 avril 2019 17:53
>> To: Alexandre Petrescu <[e-mail] <mailto:[e-mail]>>
>> Cc: Pascal Thubert (pthubert) <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf..org>
>> Subject: Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
>>  
>> Yes definitely Alex....
>>  
>> There have been many reviews until now. This should be a late or final review.
>>  
>> On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu <[e-mail] <mailto:[e-mail]>> wrote:
>>> As a note: please improve the title of this.
>>> It is not an early review.
>>> It is a late review.
>>> There have been several reviews of this document until here, and two shepherd reviews.
>>> Alex
>>> Le 04/03/2019 à 12:24, Pascal Thubert a écrit :
>>>> Reviewer: Pascal Thubert
>>>> Review result: Not Ready
>>>>  
>>>> Reviewer: Pascal Thubert
>>>> Review result: Not ready. Need to clarify IEEE relationship, IOW which SDO
>>>> defines the use of L2 fields, what this spec enforces vs. recognizes as being
>>>> used that way based on IEEE work. The use of IPv6 ND requires a lot more
>>>> thoughts, recommendation to use 6LoWPAN ND. The definition of a subnet is
>>>> unclear. It seems that RSUs would have prefixes but that is not discussed.
>>>>  
>>>> I am an assigned INT and IOT directorates reviewer for <
>>>> draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments were written
>>>> primarily for the benefit of the Internet Area Directors. Document editors and
>>>> shepherd(s) should treat these comments just like they would treat comments
>>>> from any other IETF contributors and resolve them along with any other Last
>>>> Call comments that have been received. For more details on the INT Directorate,
>>>> see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/>
>>>>  
>>>> Majors issues
>>>> -----------------
>>>>  
>>>> “
>>>>  
>>>> o  Exceptions due to different operation of IPv6 network layer on
>>>>       802.11 than on Ethernet.
>>>>  
>>>> “
>>>> Is this doc scoped to OCB or 802.11 in general? Is there an expectation that an
>>>> implementer of IPv6 over Wi-Fi refers to this doc? Spelled as above, it seems
>>>> that you are defining the LLC. Figure 1 shows the proposed adaptation layer as
>>>> IEEE LLC work. Who defines those fields, IETF or IEEE, or mixed? Who defines
>>>> their use? If this spec defines a new LLC header (vs. how to use an IEEE field)
>>>>  then it should be very clear, and the newly defined fields should be isolated
>>>> from IEEE fields.
>>>>  
>>>> "
>>>>    The IPv6 packet transmitted on 802.11-OCB MUST be immediately
>>>>    preceded by a Logical Link Control (LLC) header and an 802.11 header.
>>>>  
>>>> "
>>>> Is there anything new or specific to OCB vs. classical 802.11 operations?
>>>> If/when this is echoing the IEEE specs then this text should not use uppercase
>>>> but say something like: 'Per IEEE Std 802.11, the IPv6 packet transmitted on
>>>> 802.11-OCB is immediately  preceded by a Logical Link Control (LLC) header and
>>>> an 802.11 header ...'
>>>>  
>>>> different things? Why define both?
>>>>  
>>>> "   An 'adaptation' layer is inserted between a MAC layer and the
>>>>    Networking layer.  This is used to transform some parameters between
>>>>    their form expected by the IP stack and the form provided by the MAC
>>>>    layer.
>>>> "
>>>> Is this different from what an AP does when it bridges Wi-Fi to Ethernet? Is
>>>> this IETF business?
>>>>  
>>>> "
>>>>    The Receiver and Transmitter Address fields in the 802.11 header MUST
>>>>    contain the same values as the Destination and the Source Address
>>>>    fields in the Ethernet II Header, respectively.
>>>> "
>>>> Same,  this is IEEE game isn't it?
>>>>  
>>>> "
>>>>  
>>>> Solutions for these problems SHOULD
>>>>    consider the OCB mode of operation.
>>>> "
>>>> This is not specific enough to be actionable. I suggest to remove this sentence.
>>>> It would be of interest for the people defining those solutions to understand
>>>> the specific needs of OCB vs. Wi Fi, but I do not see text about that.
>>>>  
>>>> "
>>>>  
>>>> The method of forming IIDs
>>>>    described in section 4 of [RFC2464] MAY be used during transition
>>>>    time.
>>>> "
>>>> Contradicts section 4.3 that says
>>>> "
>>>> Among these types of
>>>>    addresses only the IPv6 link-local addresses MAY be formed using an
>>>>    EUI-64 identifier.
>>>> "
>>>>  
>>>> "
>>>>  
>>>> This
>>>>    subnet MUST use at least the link-local prefix fe80::/10 and the
>>>>    interfaces MUST be assigned IPv6 addresses of type link-local.
>>>> "
>>>> If this is conforming IPv6 then the MUST is not needed.
>>>>  
>>>> "
>>>>    A subnet is formed by the external 802.11-OCB interfaces of vehicles
>>>>    that are in close range (not by their in-vehicle interfaces).
>>>> "
>>>> Is the definition transitive? Do we really get a subnet?
>>>>  A is close to  B who is close to C .... to Z, makes Paris one subnet! Are you
>>>>  talking about a link, rather?
>>>>  
>>>> "
>>>>    The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over
>>>>    802.11-OCB links.
>>>> "
>>>>  
>>>> IPv6 ND is not suited for a non-broadcast network. How does DAD work?
>>>> Maybe you could consider RFC 6775 / RFC 8505 instead.
>>>>  
>>>> "
>>>> In the moment the MAC address is changed
>>>>    on an 802.11-OCB interface all the Interface Identifiers of IPv6
>>>>    addresses assigned to that interface MUST change.
>>>> "
>>>> Why is that? This is unexpected, and hopefully wrong.
>>>>  
>>>> Minor issues
>>>> ---------------
>>>>  
>>>> "   OCB (outside the context of a basic service set - BSS): A mode of
>>>>    operation in which a STA is not a member of a BSS and does not
>>>>    utilize IEEE Std 802.11 authentication, association, or data
>>>>    confidentiality.
>>>>  
>>>>    802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
>>>>    attribute dot11OCBActivited is true.  Note: compliance with standards
>>>>    and regulations set in different countries when using the 5.9GHz
>>>>    frequency band is required.
>>>> "
>>>>  
>>>> Are these 2 different things?
>>>>  
>>>> "
>>>> Among these types of
>>>>  addresses only the IPv6 link-local addresses MAY be formed using an
>>>>   EUI-64 identifier.
>>>> "
>>>> This text should not be in a LL specific section since it deals with the other
>>>> addresses. Maybe rename the section to "addressing" or something?
>>>>  
>>>> "
>>>>    For privacy, the link-local address MAY be formed according to the
>>>>    mechanisms described in Section 5.2.
>>>> "
>>>> The MAY is not helpful. I suggest to remove the sentence that does not bring
>>>> value vs. 5.2
>>>>  
>>>> Could you make sections 4.3 and 4.5 contiguous?
>>>>  
>>>> "
>>>> If semantically
>>>>    opaque Interface Identifiers are needed, a potential method for
>>>>    generating semantically opaque Interface Identifiers with IPv6
>>>>    Stateless Address Autoconfiguration is given in [RFC7217]...
>>>>  
>>>>    Semantically opaque Interface Identifiers, instead of meaningful
>>>>    Interface Identifiers derived from a valid and meaningful MAC address
>>>>    ([RFC2464], section 4), MAY be needed in order to avoid certain
>>>>    privacy risks.
>>>>  
>>>> ...
>>>>  
>>>>    In order to avoid these risks, opaque Interface Identifiers MAY be
>>>>    formed according to rules described in [RFC7217].  These opaque
>>>>    Interface Identifiers are formed starting from identifiers different
>>>>    than the MAC addresses, and from cryptographically strong material.
>>>>    Thus, privacy sensitive information is absent from Interface IDs, and
>>>>    it is impossible to calculate the initial value from which the
>>>>    Interface ID was calculated.
>>>>  
>>>> "
>>>> Duplicate and mis ordered text, isn't it?
>>>>  
>>>> " For this reason, an attacker may realize many
>>>>    attacks on privacy.
>>>> "
>>>> Do we attack privacy? Maybe say that privacy is a real concern, and maybe move
>>>> that text to security section?
>>>>  
>>>> "
>>>>    The way Interface Identifiers are used MAY involve risks to privacy,
>>>>    as described in Section 5.1.
>>>> "
>>>> Also duplicate
>>>>  
>>>> Nits
>>>> ------
>>>>  
>>>> "
>>>>    IP packets MUST be transmitted over 802.11-OCB media as QoS Data
>>>>    frames whose format is specified in IEEE Std 802.11.
>>>> "
>>>> Please add link to the reference
>>>>  
>>>> " the 802.11 hidden node"
>>>> Do not use 802.11 standalone (multiple occurrences).
>>>> => "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden terminal".
>>>>  
>>>> BCP 14 text:
>>>>  
>>>> Suggest to use this text:
>>>> “
>>>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>>>    "OPTIONAL" in this document are to be interpreted as described in
>>>>    https://tools.ietf.org/html/bcp14 <https://tools.ietf.org/html/bcp14> https://tools.ietf.org/html/bcp14 <https://tools.ietf.org/html/bcp14>
>>>>    [https://tools.ietf.org/html/rfc2119 <https://tools.ietf.org/html/rfc2119>][RFC8174] when, and only when, they
>>>>    appear in all capitals, as shown here.
>>>>  
>>>> “
>>>>  
>>>> All the best
>>>>  
>>>> Pascal
>>>>  
>>>>  
>>>>  
>> _______________________________________________
>> its mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>