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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 09 April 2019 13:54 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4959E120098 for <its@ietfa.amsl.com>; Tue, 9 Apr 2019 06:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfpcVNZMdwV3 for <its@ietfa.amsl.com>; Tue, 9 Apr 2019 06:54:16 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48E81202EB for <its@ietf.org>; Tue, 9 Apr 2019 06:54:15 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x39DsAVP045119; Tue, 9 Apr 2019 15:54:10 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EC85E20421E; Tue, 9 Apr 2019 15:54:09 +0200 (CEST)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D6B4520419E; Tue, 9 Apr 2019 15:54:09 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x39Ds9So026398; Tue, 9 Apr 2019 15:54:09 +0200
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Cc: "its@ietf.org" <its@ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, "Stanley, Dorothy" <dorothy.stanley@hpe.com>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <9d5c8168-a915-358e-d7eb-0362cad96d81@gmail.com> <27AE185B-1D95-4DCD-8C76-AECE90E46802@cisco.com> <MN2PR11MB35651C4D8957516CF034BFADD8510@MN2PR11MB3565.namprd11.prod.outlook.com> <CALypLp9SuURGJ4f8FBzZg1WQOo9B4xsB8Y4uGW+Jtfm2b=8Sww@mail.gmail.com> <F4BC9027-35E0-4ADB-845A-15B5DD27C069@cisco.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <64e1744b-6fc6-17b8-0186-399dd0fe91fc@gmail.com>
Date: Tue, 09 Apr 2019 15:54:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <F4BC9027-35E0-4ADB-845A-15B5DD27C069@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/ZVt17c02pM4zntTUivBp33p7pB0>
Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2019 13:54:19 -0000


Le 09/04/2019 à 02:04, Pascal Thubert (pthubert) a écrit :
> Hello Carlos
> 
> I think we’re a bit stuck.
> 
>   I spent really a long time explaining why RFC 4861 does not cut it

Pascal, with all due respect.

You seem to be claiming RFC4861 does not work on WiFi altogether.

Is it so?

> itself. No magic will make that happen. I tried to help by indicating a 
> version of ND that was designed for radios and to my best knowledge will 
> work here. I understand that people will not trust that on “face value” 
> but I do not understand that people prefer something that was designed 
> before the concept of a radio link was even considered and is known not 
> to work.

Pascal,

We take ND efficient as important for wireless.

For OCB text I ponder over some text.

There is understanding.

Some small point that would help further is if I had an implementation 
available of ND efficient (Address Registration, etc) running at 5.9GHz 
in OCB mode in some cars.  Or some packet dump of it.

> In any fashion I cannot support a doc that lets the outside of the IETF 
> believe that RFC 4861 is suited for OCB. RFC 4861 survives on BSS thanks 
> to the association process that provides a signal for DNA and emulates 
> an Ethernet broadcast domain. Nothing like that on OCB.
> 
> Best can do is send the doc back to the WG till it can provide a 
> satisfactory solution to ND.

Pascal - I would like to ask you which hat you wear when you send the 
doc back?  (it is for my clarification as there are so many roles at 
IETF recently and I do not understand them all).

Yours,

Alex

> 
> Regards,
> 
> Pascal
> 
> Le 9 avr. 2019 à 03:04, CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es 
> <mailto:cjbc@it.uc3m.es>> a écrit :
> 
>> Hi Pascal, all,
>>
>> Sorry to jump late into this discussion.
>>
>> Thanks for the provided text.
>>
>> I think it contains good parts that I'd recommend authors to consider 
>> incorporating into the draft. I see you are already discussing about 
>> that and I hope the WG reaches an agreement on how to modify current text.
>>
>> I have some comments from my side:
>>
>> - I tend to agree with Alex in that I'd skip the RECOMMENDED part of 
>> the text (referring to RFC 8505). I agree that some pieces of RFC 8505 
>> could be adapted to be used in OCB, but I think using RECOMMENDED with 
>> further analysis within the WG is too much. I'd rather prefer that RFC 
>> 8505 is referenced in the draft as a solution that could be used as 
>> starting point to enhance ND over OCB (but we have agreed already in 
>> the WG that ND enhacements are outside the scope of current draft).
>>
>> - I see good points in Pascal's text, but probably need some language 
>> fixing, as it might lead to some questions as the Alex has pointed out.
>>
>> - I'd appreciate if we all acknowledge here all the work Alex (and the 
>> rest of the authors) have been doing so far, as well as Pascal's help. 
>> Please, try to keep the discussion positive. That _always_ helps.
>>
>> Thanks,
>>
>> Carlos
>>
>> On Fri, Apr 5, 2019 at 5:09 PM Pascal Thubert (pthubert) 
>> <pthubert@cisco.com <mailto:pthubert@cisco.com>> wrote:
>>
>>     Dear all;____
>>
>>     __ __
>>
>>     As promised I put together some words on using IPv6 ND and then
>>     RFC 8505 for OCB. Please find attached early text. This could
>>     become a section 4.7.____
>>
>>     Note that RFC 8505 enables a DAD operation for both link local and
>>     global addresses, the associated global prefix being owned by
>>     either a car or a RSU. RSUs connected to the internet can
>>     advertise a default router preference to indicate they are willing
>>     to relay packets for global addresses.____
>>
>>     The attached text impacts other sections in particular the
>>     discussion on global addresses which is somehow avoided in the
>>     current draft and could be reintroduced.____
>>
>>     __ __
>>
>>     Comments welcome : )____
>>
>>     __ __
>>
>>     Pascal____
>>
>>     __ __
>>
>>     *From:* Pascal Thubert (pthubert)
>>     *Sent:* jeudi 28 mars 2019 11:29
>>     *To:* Alexandre Petrescu <alexandre.petrescu@gmail.com
>>     <mailto:alexandre.petrescu@gmail.com>>
>>     *Cc:* its@ietf.org <mailto:its@ietf.org>
>>     *Subject:* Re: Intdir early review of
>>     draft-ietf-ipwave-ipv6-over-80211ocb-34____
>>
>>     __ __
>>
>>     Yes Alex. Also as an offer to help...____
>>
>>     __ __
>>
>>     Regards,____
>>
>>     __ __
>>
>>     Pascal____
>>
>>
>>     Le 28 mars 2019 à 11:08, Alexandre Petrescu
>>     <alexandre.petrescu@gmail.com
>>     <mailto:alexandre.petrescu@gmail.com>> 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____
>>
>>             __  __
>>
>>             __  __
>>
>>             __  __
>>