Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-38

[Alexandre Petrescu <[e-mail]>]

Brian,

Le 12/04/2019 à 22:28, Brian E Carpenter a écrit :
> On 13-Apr-19 02:59, Sri Gundavelli (sgundave) wrote:
>> 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.
> 
> This is of course possible. In general the IETF hasn't done that,
> but has followed the lead set by RFC 2464 with the complete
> specification of IPv6-over-foo in one document.
> 
> However, I don't believe that publishing an RFC about the frame 
> format without *simultaneously* publishing an RFC about ND etc would 
> be a good idea.

Brian - it took us several years to arrive at this IP-over-OCB spec.  I
suspect an ND-over-OCB would take even longer, as it seems more complex
in particular mobility contexts; mobility contexts are hard tot try.
What happens with the IP-over-OCB spec during these additional years?  A
draft expires after 6 months.  Would one update the IP-over-OCB draft
update it every 6 months with just artificial ' ' in it just to keep it
alive?  It does not seem feasible.

> That would leave developers absolutely unable to write useful code,
> and might easily lead to incompatible implementations. Since we'd
> presumably like Fords to be able to communicate with Peugeots, that
> seems like a bad idea.

Fords talking to Peugeots in a convoy can work fine today, without 
additional ND work.  ND works fine on PHYs and MACs that are set up 
properly.

Alex

> 
> Regards Brian
> 
>> https://mailarchive.ietf.org/arch/msg/its/9NvUfRigGd4Klu0Q2Ee-63ziATw
>>
>>
>>
>> 
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/____
>> 
>> __ __
>> 
>> 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____
>> 
>> __ __
>> 
>> __ __
>> 
>> __ __
>> 
>> _______________________________________________ its mailing list 
>> [e-mail] <mailto:[e-mail]> 
>> https://www.ietf.org/mailman/listinfo/its
>> 
> 
>