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

"Ms. Li HUANG" <bleuoisou@gmail.com> Sat, 06 June 2020 07: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 1F5233A0F03; Sat, 6 Jun 2020 00:52:05 -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 jaGYG36FdFqW; Sat, 6 Jun 2020 00:52:02 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 D35C13A0EFC; Sat, 6 Jun 2020 00:52:02 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id s18so12999964ioe.2; Sat, 06 Jun 2020 00:52:02 -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=N9dAEJgmeMDDtpXo3naGhJHcPG3iCORG5xA/rL3DRCQ=; b=ac+MDfZn7M3UNaJhhfnm3vzceMCKa+K279El4i+Ji5KKSJcCcM+BkrbcGLiPKwm2Bf iTA/j6cX8Sn1XTzJuU67wjg64yQg8tpW8vahG5b7iMJHkO4uCSOsXBk0H9Fb2uuYggH/ pBdwvbYUKmnxg7Q45mYdQK4OxkJSKuewBvW9BiEK+q7faZCX//MdyVyl2aILaOp9n6e3 Ojcbb9pp6H5FdvS7T3eDnXABHtF14mLvC+yzhq5J1iiHD8nkMsyuTYA1LM84kYzxIBk9 MggEbLpemwlaDDJ+SZqflJkaI7WRUPVIBxGfYIjSgk2VlO6I8NdVHOR0MwSlTqiXK2IG rBBg==
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=N9dAEJgmeMDDtpXo3naGhJHcPG3iCORG5xA/rL3DRCQ=; b=jdgwDcj+g8hMpRMA0zHTxGayx8BT22uu6cE+Uy0SCKQkW6HZFqkW+Nq4ev507AN1Qn u7cuc1SnaOW8q2o3wEqChk1yWOqBQTmtslhzp5YTuzacaGUj7OyykTzXao/hU1pgBAUQ A0tfGH8hXU6QCTVQzGCG7jHi9LYkGJpReEk0FbiccVzxUzDHbCDwsa/V1L0pzpJcJ4bY 5baf4QSTV08kUdbcmuGDhw3WSs1hTPDLOUvRF97+V4pbkkJ1l4xmlI2tJM4C2Y2v7yCR Hp/xymGePP4zvyaQpGm4OD0vW/JGj9NsrWDwsGmrnJlwbDeQXk4Jine4kQ8YXnxqT/Gq CGcw==
X-Gm-Message-State: AOAM530ofF4qih1HIlk4Pn+ij38oxpmK0PAzIwA1ENQzieYE3gmZEbqM GAneXx4vkbdZziTfuDkgtN+8M5Y/tYbi3jlf0wc=
X-Google-Smtp-Source: ABdhPJyZfOYhyDiM01n47mmuCyNtWRlpnz87bPWqI8PbRnr9mCnJvduLxZJT1detbSNHGFrsiHxJx2EwHUdlh6Rcdw0=
X-Received: by 2002:a5e:8703:: with SMTP id y3mr408960ioj.61.1591429920669; Sat, 06 Jun 2020 00:52:00 -0700 (PDT)
MIME-Version: 1.0
References: <159125749726.19650.16749433552197061248@ietfa.amsl.com> <6AD5240B-F121-4005-9436-67FE5C87EA35@cisco.com>
In-Reply-To: <6AD5240B-F121-4005-9436-67FE5C87EA35@cisco.com>
From: "Ms. Li HUANG" <bleuoisou@gmail.com>
Date: Sat, 6 Jun 2020 15:51:48 +0800
Message-ID: <CAGGiuEYSWU5NH--nV=bFF_BYXOoG5-d77gAezmfkcRfXW6vXsg@mail.gmail.com>
To: "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>
Cc: Jaime Jimenez <jaime@iki.fi>, "iot-directorate@ietf.org" <iot-directorate@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-dhc-slap-quadrant.all@ietf.org" <draft-ietf-dhc-slap-quadrant.all@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001b411f05a765a721"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/VPz1CseJctLmufO1jBCj6rDHn9k>
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: Sat, 06 Jun 2020 07:52:05 -0000

15:45.hk S8 June 06 2020



There are yes so many such etc. I.sight dhcpv6, most time isp,  schemes
arounding yet positive for user under , earlier time published and looking
forward to ipv6 only whether over reckoning , or rush replying to ... ?


by the way ipv4 in May and Jun rather more addresses from each isp mac than
, when the  "*ipv6 only in may 2020 globally*" news  published from ietf.org
later on...


Sincerely
Li HUANG

On Fri, Jun 5, 2020, 22:45 Eric Vyncke (evyncke) <evyncke=
40cisco.com@dmarc.ietf.org> wrote:

> Thank you Jaime,
>
> I will make sure that my IESG ballot will refer to your review
>
> -éric
>
> -----Original Message-----
> From: Jaime Jimenez via Datatracker <noreply@ietf.org>
> Reply-To: Jaime Jimenez <jaime@iki.fi>
> Date: Thursday, 4 June 2020 at 09:58
> To: "iot-directorate@ietf.org" <iot-directorate@ietf.org>
> Cc: "last-call@ietf.org" <last-call@ietf.org>rg>, "
> draft-ietf-dhc-slap-quadrant.all@ietf.org" <
> draft-ietf-dhc-slap-quadrant.all@ietf.org>gt;, "dhcwg@ietf.org" <
> dhcwg@ietf.org>
> Subject: Iotdir last call review of draft-ietf-dhc-slap-quadrant-07
> Resent-From: <alias-bounces@ietf.org>
> Resent-To: <cjbc@it.uc3m.es>es>, <alain.mourad@interdigital.com>om>, <
> tomasz.mrugalski@gmail.com>gt;, <volz@cisco.com>om>, <ek.ietf@gmail.com>om>, Eric
> Vyncke <evyncke@cisco.com>om>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>om>,
> Ian Farrer <ianfarrer@gmx.com>om>, <ianfarrer@gmx.com>
> Resent-Date: Thursday, 4 June 2020 at 09:58
>
>     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."
>
>     Section 1:
>
>         s/specified regions/regions/ ?
>         "different assignment approaches in four specified regions of the"
>
>     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.
>
>     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?
>
>         "[...] 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)
>
>         "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.
>
>         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?
>
>         "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?
>
>         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.
>
>     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.
>
>     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.
>
>     References:
>
>         [IEEEStd802c-2017] does not provide a link to the document. It
> would be
>         useful to include that when available.
>
>
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>