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

Nabil Benamar <benamar73@gmail.com> Fri, 12 April 2019 14:34 UTC

Return-Path: <benamar73@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 0764C120254; Fri, 12 Apr 2019 07:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hDq00c-ncTDu; Fri, 12 Apr 2019 07:34:16 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F117512006F; Fri, 12 Apr 2019 07:34:15 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id l7so9074156ljg.6; Fri, 12 Apr 2019 07:34:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oCbvfEFAUkd0hmC8xNBCXaO1AOc5bnM/mQnZtM5c8eM=; b=ksz77ZSslVJLbplMn6polawciJLrVNLqWO7uatwS7C0ts380Dd+eQ4szwkzpf6kleq xPqglMg0B71ZDCQC8fwM7Sbmrq4QMvm5jDFeo/QKttvePOEDx2rC/EVlmfyXnXh3lUJP PMc5Zh0Qxle8c01KOIjNkuwS+ykrdj+nTbBSlYiILWMDy5FFj1splEH0lvU/rRS1Gutr mY7Yn++Ih3i0kIRsL8vDybrcfEOx3XzFYssxAT4w7g+hhD48szdaGtrh/mxA6nTomvQp fJqBlmVLeJESF/UT2sUPFxsKILa5WB3Lmikb33jA5RadHRKT7Z4/gChKXUUvYS3Me3oO OfJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oCbvfEFAUkd0hmC8xNBCXaO1AOc5bnM/mQnZtM5c8eM=; b=PkADYlX46GW4rTdVKXk+30x98wc9k6RnuvEjgHE6svy+oZsWkw5xotb6t1YJAWEXJ5 n6NRo24wU9Qxuvvcu6NUP3bVqx6NZU1qwqzj6i5Wk/grtgMMPA13Hss49hoBkfTBuSA5 UtFvkJmh9BYOK0zqzuHUSn/tnq+2wpGhL82bOse8YUdFvct/Ds1/0oJYbOB0xNHtWHkW rt4Ro/Ekh8glwkXYZXtnYZWqINkdRlweApiHX3jXsmJyzjvmXPqICJwxvHko7kE7qRkc Kkjzyi7fKbgkRs7U1T1LZHp0lSqEt26YnsZtDw1WVcJEa9VWOVYWTKFV1soNbCqES5SV Uosg==
X-Gm-Message-State: APjAAAXDpy0Gm65i9atLbaS+hKifrBR7iq1rjdJrO1d3eOTlpBOD+dOf KR6RiwKSB7gT3Jd5LRrZL5yd1mNo/vYT5B35PN0=
X-Google-Smtp-Source: APXvYqzAmAsFy5v1vHbbYwr0cmqS+4hxROGCKz7wVwP7/lD8v0ugASzya/9/xfIc+J0hAnD9Cm6DxuFZ91jd/TuVBcg=
X-Received: by 2002:a2e:5bcc:: with SMTP id m73mr22247687lje.100.1555079654013; Fri, 12 Apr 2019 07:34:14 -0700 (PDT)
MIME-Version: 1.0
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <a8aad636-069c-4451-dbf1-72c1db2204ef@gmail.com> <CAD8vqFfx_FVi5NobrR1p6xEKjkSNa1_ZejgrEs3JPDHJQoxD7A@mail.gmail.com> <MN2PR11MB356570FDBC5798F155DDEE25D82C0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB356570FDBC5798F155DDEE25D82C0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Nabil Benamar <benamar73@gmail.com>
Date: Fri, 12 Apr 2019 15:34:02 +0100
Message-ID: <CAMugd_Xce5cWLtVB4DbR1ZEaFbdfiRpXre9oq61ukRC+n+3cZw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Nabil Benamar <n.benamar@est.umi.ac.ma>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "its@ietf.org" <its@ietf.org>, "int-dir@ietf.org" <int-dir@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005fff7c0586563274"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/mDgloA02pwSUcgTVscjU63bpmu8>
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: Fri, 12 Apr 2019 14:34:20 -0000

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) <pthubert@cisco.com>
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 <n.benamar@est.umi.ac.ma>
> *Sent:* lundi 8 avril 2019 17:53
> *To:* Alexandre Petrescu <alexandre.petrescu@gmail.com>
> *Cc:* Pascal Thubert (pthubert) <pthubert@cisco.com>; int-dir@ietf.org;
> ietf@ietf.org; its@ietf.org;
> 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 <
> alexandre.petrescu@gmail.com> 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
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>