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

[NABIL BENAMAR <[e-mail]>]

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]>
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/
>
> 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
>
>
>
>
>