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: Jaime Jiménez <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 >
- [dhcwg] Iotdir last call review of draft-ietf-dhc… Jaime Jimenez via Datatracker
- Re: [dhcwg] Iotdir last call review of draft-ietf… Eric Vyncke (evyncke)
- Re: [dhcwg] Iotdir last call review of draft-ietf… Ms. Li HUANG
- Re: [dhcwg] Iotdir last call review of draft-ietf… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Iotdir last call review of draft-ietf… Jaime Jiménez
- Re: [dhcwg] Iotdir last call review of draft-ietf… Ms. Li HUANG