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

[Alexandre Petrescu <[e-mail]>]

We consider the offer to help, thank you.  What would be most attractive 
for you to do for this draft?

Alex

Le 28/03/2019 à 11:28, Pascal Thubert (pthubert) a écrit :
> Yes Alex. Also as an offer to help...
> 
> 
> Regards,
> 
> Pascal
> 
> Le 28 mars 2019 à 11:08, Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> a 
> écrit :
> 
>> Pascal,
>>
>> Should we treat these two reviews (iotdir and intdir reviews) as just one?
>>
>> The contents appear to me to be the same.
>>
>> 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,
>>> seehttps://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/rfc2119][RFC8174] when, and only when, they
>>>     appear in all capitals, as shown here.
>>>
>>> “
>>>
>>> All the best
>>>
>>> Pascal
>>>
>>>
>>>