Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-slap-quadrant-07

"Ms. Li HUANG" <bleuoisou@gmail.com> Fri, 19 June 2020 05:52 UTC

Return-Path: <bleuoisou@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696013A0E45; Thu, 18 Jun 2020 22:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 UJiN-kQnH_wK; Thu, 18 Jun 2020 22:52:00 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 4D7333A0E39; Thu, 18 Jun 2020 22:52:00 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id u13so9919999iol.10; Thu, 18 Jun 2020 22:52:00 -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=9h1AoCT9DFuE2s++pMCG0y3LSw3zdTTzmoLGD6VpWUY=; b=QMQpmkPhOx0qIxYAPbKdW9rFlUBKKbLKgAtG2NiypfujYBgYG0hf4mjhA6ZH75oqlh jEVZTPQz4FMJ4R6xTTCdFKsvQfpdTudR3ITmK5GGFF1azKz+CjVaMffINzabHQ8qcdRp xqbuYgRA60x3gRbU1Gxk70O+Fh24unpRknF0tkhwkFRxN+VQzgLyL9spsusKjG8M5bcO wt97zEI6m7IoEaBEDSXrAXfUlp2h2GyO15mfCinQYRMPqDz3/6XXWIEtRDDUlf73AoSi ayn7iROjx2GKZ/RB8+BjI3GC5dl04KtOr+d4TVXKhZ8eYLhEFHerrf9yPwJ4yZuQGE/z gsCA==
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=9h1AoCT9DFuE2s++pMCG0y3LSw3zdTTzmoLGD6VpWUY=; b=P0vEN/DdxFLbusg6yNAOJRlwkeyBxJ5fWfrimFunAQNZqXti4eMKyuEkHXV3goAyHg eNIv0SDWo1KpnAdVYZ9PMw3cZIyyUY6qtoYIULy75pS2GVoYy8tr37dEfrj9EkpHHO4d MENdCfsdvVYNd5qJH20occ6e54yttmcNw1iA8gQuyErQ+ur+GIxDBd0zOIDuiYUM4qCK Q5p2+jjTEsZSFDhWxzaAubPK78VMVeGmxwatwqUNZbLVrfM++UX5d285e73Zex/c5y+T Fa8Lb5gsAYoOtVqi3ozoKFqohUjzNI/2+A5PTheMZo6L0AusH2nicXooVHyKoMt9pO5I KbGg==
X-Gm-Message-State: AOAM533xvWsqoZiHPDTrxg3dLt3UMZ5koq8TS/eqyBmzKo2jxcfO7NoJ n+MwDaGoybSU7pnKnRf5dgDCsxIU1OeKlQQeSE3bDllpOqo=
X-Google-Smtp-Source: ABdhPJyQuawmNPgDZ/7yXAvszSb2oOamj8uScM4w35Hyra/SIqYluIBJA+Ws9ZuXPhruCc8PT5ccusK3mRY3TMQKum0=
X-Received: by 2002:a05:6638:604:: with SMTP id g4mr2321086jar.80.1592545919614; Thu, 18 Jun 2020 22:51:59 -0700 (PDT)
MIME-Version: 1.0
References: <159125749726.19650.16749433552197061248@ietfa.amsl.com> <CALypLp9hZLFTMhMF7azE9Pe6e_UWS-HhKfoJ-vJ1h1xX6VeZFg@mail.gmail.com> <20200608111417.awizl3vnf5egcaep@EMB-918HFH01>
In-Reply-To: <20200608111417.awizl3vnf5egcaep@EMB-918HFH01>
From: "Ms. Li HUANG" <bleuoisou@gmail.com>
Date: Fri, 19 Jun 2020 13:51:47 +0800
Message-ID: <CAGGiuEZj183Jii6_RDWFMRVyR2OOX53eQzAUQOMNqadhh7zK0w@mail.gmail.com>
To: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= <jaime@iki.fi>
Cc: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>, iot-directorate@ietf.org, dhcwg <dhcwg@ietf.org>, draft-ietf-dhc-slap-quadrant.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d3c50005a8697d18"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/hG8P7qx8HouZD4pBPYfcdSowr9E>
Subject: Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-slap-quadrant-07
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2020 05:52:04 -0000

the Terpedo after isp ipv6 offering later, function, quandary, and set at
sg3xx routes remaining:

    -    os such vista 2002:...via it got ipv6 first,
    -     found 2001:… prefix , added after, resulting no.e nothing ipv6
showing?

    -      isp claiming not their scope managing Teredo  , who set ipv4
1800 time on, to dhcpv4 server isp, as well Terredo servers to care off
these, when IPv6 Only is a dreaming yet reality completely ?



Sincerely
Li H

On Mon, Jun 8, 2020, 19:14 Jaime Jiménez <jaime@iki.fi> wrote:

> Hi Carlos,
>
>
> I believe this solves all of the issues I raised on my review. Thanks
> for the prompt response, I wrote some comments below.
>
> Ciao,
>
> -- Jaime Jiménez
>
> On Sun, Jun 07, 2020 at 11:45:07AM +0200, CARLOS JESUS BERNARDOS CANO
> wrote:
> > Hi Jaime,
> >
> > Thanks a lot for your review. Please see my comments and responses inline
> > below.
> >
> > On Thu, Jun 4, 2020 at 9:58 AM Jaime Jimenez via Datatracker <
> > noreply@ietf.org> wrote:
> >
> > > Reviewer: Jaime Jimenez
> > > Review result: Ready with Nits
> > >
> > > draft-ietf-dhc-slap-quadrant-07 iodir review
> > > ============================================
> > >
> > > This draft is complementary to draft-ietf-dhc-mac-assign. It defines
> > > mechanisms
> > > to allow for the use of IEEE's SLAP quadrant when using DHCP for MAC
> > > allocation. It also defines a new DHCPv6 Option (QUAD) for that
> purpose.
> > >
> > > Both drafts verse on the use of DHCP to assign MAC addresses to hosts,
> > > which as
> > > a concept was strange to me to begin with. However I am not up-to-date
> in
> > > the
> > > latest developments on host configuration so I am likely to be missing
> a
> > > big
> > > part of the picture.
> > >
> > > I find this draft quite useful to understand the rationale behind
> > > draft-ietf-dhc-mac-assign, and I regret not having paid more attention
> to
> > > it
> > > before I did the draft-ietf-dhc-mac-assign review. At the time I
> > > understood the
> > > rationale to be the use of MAC address as a deployment mechanisms
> while in
> > > reality, it is a privacy mechanism. I think the security scenario makes
> > > more
> > > sense as IoT devices normally are deployed with MAC information from
> the
> > > factory. I believe that is the primary purpose of both
> dhc-slap-quadrant
> > > and
> > > draft-ietf-dhc-mac-assign when it comes to IoT, perhaps that
> information
> > > should
> > > be emphasized on draft-ietf-dhc-mac-assign.
> > >
> > > This draft is clearly written and seems ready, below are few concrete
> > > comments:
> > >
> > > Abstract:
> > >
> > >    Consider splitting in two shorter sentences the paragraph below.
> > >
> > >    "                                         [...] Recently, the IEEE
> > >    has been working on a new specification (IEEE 802c) which defines a
> > >    new "optional Structured Local Address Plan" (SLAP) that specifies
> > >    different assignment approaches in four specified regions of the
> > >    local MAC address space."
> > >
> >
> > [Carlos] Done. Changes applied in -10 version (to be released after
> > collecting all comments from IESG review).
> >
>
> [Jaime] OK
>
> >
> > > Section 1:
> > >
> > >     s/specified regions/regions/ ?
> > >     "different assignment approaches in four specified regions of the"
> > >
> >
> > [Carlos] Since IEEE 802c also defines the regions, we believe it's better
> > to keep the original wording to make this more explicit.
> >
> >
>
> [Jaime] OK
>
> > >
> > > Section 3:
> > >
> > >     "[...] if the IoT device can move, then it might prefer to
> > >       select the SAI or AAI quadrants to minimize address collisions
> > >       when moving to another network."
> > >
> > >     I wonder if collisions are likely to occur in practice.
> > >
> >
> > [Carlos] Collisions are always possible, since devices can always select
> > their own address without using a delegation mechanism, but not very
> > likely. draft-ietf-dhc-mac-assign has some security considerations about
> >  address collisions.
> >
>
> [Jaime] Thanks, if you have some literature on the topic, I'd be happy to
> read
> it off-list.
>
> >
> > >
> > > Section 4.1:
> > >
> > >     Naive questions on MAC usage. Could an IoT device self-assign a MAC
> > > with a
> > >     specific SLAP quadrant information? Would the DHCP Server accept it
> > > without
> > >     the negotiation mechanisms described here (providing it is not in
> the
> > > MAC
> > >     address pool)? Could an endpoint use an OUI from a different
> vendor?
> > > If so,
> > >     how are potential collisions or attacks preventable?
> > >
> >
> > [Carlos] It is always possible that a device self-assigns a MAC address
> > from any quadrant, though for some quadrants it is not the expected use
> > (therefore, if a device does it, it would not be behaving as
> > specified). draft-ietf-dhc-mac-assign has some security considerations
> > about  address collisions that would apply here as well.
> >
> >
>
> [Jaime] draft-ietf-dhc-mac-assign Security considerations where rather
> thin too,
> mostly the references to RFC8415 and RFC8200 and the mention of link-layer
> address collision. If that is the only new issue then that's OK, I
> assume the SECDIR had a look on it.
>
> > >     "[...] The server MAY alter the
> > >        allocation at this time."
> > >
> > >     It would be helpful to explain in which way allocation might be
> altered
> > >     (i.e., by reducing the address block)
> > >
> >
> > [Carlos] OK, we have added some examples in -10.
> >
> >
>
> [Jaime] I am unable to find -10 but I trust the changes are addressed.
>
> > >
> > >     "5.  When the assigned addresses are about to expire, the client
> sends
> > >        a Renew message.  It includes the preferred SLAP quadrant(s) in
> > >        the new QUAD IA_LL-option, so in case the server is unable to
> > >        extend the lifetime on the existing address(es), the preferred
> > >        quadrants are known for the allocation of any "new" addresses."
> > >
> > >     Is it correct to assume that step 5 causes either:
> > >      - to assign the existing block
> > >      - to start on step 1 with the new QUAD if the block is no longer
> > > available.
> > >
> >
> > [Carlos] Not sure I got it right, but Step 5 does not cause going back to
> > step 1. It basically includes the preferred SLAP quadrants again to
> > facilitate the server allocating _different_ addresses to the ones the
> > client got assigned, in case the server cannot extend the lifetime of
> these
> > ones (e.g., because of a renumbering policy).
> >
> >
>
> [Jaime] When we say "preferred SLAP quadrants" are we to assume that they
> are
> the same the client has already been using or is that an uncommon case?
>
> I would maybe write a sentence or two including your explanation and
> some normative text (e.g., that the client MAY try with the existing ones
> and
> that the server MAY assign different ones due to renumbering or other
> factors).
>
> > >     So, is it then the case that the client sends a Renew message -for
> the
> > >     existing block- with _alternative_ SLAP quadrants different than
> the
> > > ones
> > >     in use in case the block is no longer available?
> > >
> >
> > [Carlos] Please check if my response beforer clarifies this.
> >
> >
>
> [Jaime] From the previous response I understand that the client can choose
> to
> request the same SLAP quadrant or another different one.
>
> > >
> > >     "6.  The server responds with a Reply message, including an LLADDR
> > >        option with extended lifetime."
> > >
> > >     What happens with the _fail_ case, in which the block is no longer
> > >     available? How is the REPLY format denying the addresses?
> > >
> >
> > [Carlos] In this case the client would know by checking the allocated
> > address(es) (if they are different, that means that the addresses are no
> > longer available, and the client would know from which quadrant they
> belong
> > to, as this is implicit from the address itself).
> >
> >
>
> [Jaime] OK so the server will _always_ reply with some address
> allocation. Could this mechanism not be abused by clients requesting
> new blocks too frequently?
>
> > >     A style suggestion, as "Advertise", "Renew", "Reply", etc are
> specific
> > > DHCP
> > >     message types, you might want to write them capitalized
> "ADVERTISE",
> > >     "RENEW", "REPLY", etc to avoid potential confusion.
> > >
> >
> > [Carlos] Here we've followed the same approach as
> > in draft-ietf-dhc-mac-assign. If we change it, we should do it in both.
> >
> >
>
> [Jaime] It was just a style suggestion, someone versed in the field will
> probably know it right away. So, it's up to the authors.
>
> > > Section 4.2:
> > >
> > >     "9.   When the assigned addresses are about to expire, the client
> > >       sends a Renew message.
> > >     [...]
> > >     12.  The relay sends the Reply message back to the client."
> > >
> > >     Same as in section 4.1, steps 9 to 12 might need to be revised.
> > >
> >
> > [Carlos] Please see if my responses to 4.1 are satisfactory.
> >
>
> [Jaime] I think the Relay behaviour is OK as described.
>
> >
> > >
> > > Section 7:
> > >
> > >     The Security section looks a bit thin but I have no good
> suggestions to
> > >     improve. Is it even possible for a bad actor to spoof a RENEW
> lease on
> > >     behalf of another node? Perhaps some information on authentication
> > >     mechanisms for DHCP would be handy.
> > >
> >
> > [Carlos] We mainly refer to RFC 8415 and RFC 7227 for all the security
> > mechanisms of DHCP, and also to draft-ietf-dhc-mac-assign for some
> > additional considerations regarding link-layer address assignments using
> > DHCP.
> >
> >
>
> [Jaime] As I mentioned above, if the authors consider that new potential
> threats are covered and SECDIR is fine then it should be OK.
>
> > > References:
> > >
> > >     [IEEEStd802c-2017] does not provide a link to the document. It
> would be
> > >     useful to include that when available.
> > >
> >
> > [Carlos] OK, noted. Thanks.
> >
>
> [Jaime] Thanks!
>
> > Thanks a lot.
> >
> > Carlos
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>