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

CARLOS JESUS BERNARDOS CANO <> Sun, 07 June 2020 09:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF93A3A0D05 for <>; Sun, 7 Jun 2020 02:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TgspsfZpFHxq for <>; Sun, 7 Jun 2020 02:45:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72F773A0CC3 for <>; Sun, 7 Jun 2020 02:45:27 -0700 (PDT)
Received: by with SMTP id k8so2975210iol.13 for <>; Sun, 07 Jun 2020 02:45:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pYBrWW7AogQN9UBDJnubMydU7pKAFXSaM5h2+Us8ynI=; b=LskFWV00CFNxgVprjinc9o61YGtqfDzR3LqfQQ5Ux9mLYE75BppIsEb29YS/7DHCHz Cb7Vok7TPPR8Q6uU6jysGEE6p9yHi/yRwprYaj0ZzYGvA88kpkjOXGAB6K+vndLEkg9r S93D0331LgmSN8ncZA5Ul02srbqPzvD9tQjPuPnaiefCnu4EWPizFfanDMzDAa7YQxOU iBJ4vIDlF2N6LEH9qo0Yl/g/N6k5GeMgHVXMepJdunfPm5ktUAnH5bdJrmLZl+c5aJOR Ar+SS3TS/qocMkB5m4EUfwgWURIo5UHRR36oCwK9lChRoXnkKJOYl6UOMjziVKlz7mfp 0hRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pYBrWW7AogQN9UBDJnubMydU7pKAFXSaM5h2+Us8ynI=; b=EMbeobccQueANaae7oJfIAHlh0W67LKqU7r0DCvA+yP5RXm3EVFyIFUV6Unek4eKAx jG9rEmtmIBqK7IKBWQvDn1YMHaMpejUQRDpAxRQ15/FnJ62+oRArepWqUYHytyP3MeN3 WL9IodhbKoQs/UUDikQgfxAKrKydIQKK4i42rF0dCYDbRGm0Yhe1iJHyu7T+dKtAVXAz Nif+QWBi91UwBapA23CooQRQRi0RxhXZqtf52QL32u/rggRRxOif4I6SqQPX3fJOZdQT 21BbkfmncGKVLhiyLyCetwNgQROgTj56vswtwrA8kdI975Ros7peIKPI5y/5ExZSEt68 QoAg==
X-Gm-Message-State: AOAM532YBg2qqAgRfIVojUitSDSdCTZlBJnjPcup6VzW4BbkHaRMQw/l Eyd4w9vqYa2FsAqBh4RjhIHaqIzWWb8u6M8jSaWBCA==
X-Google-Smtp-Source: ABdhPJzXJWkfOaWJfPYQ1yYN8DUWaEGviBfHvY85nFpe+yfDkDguY3+0zhBnjH5aCRWNTGsKAPOrYRxnfFJVL/cLy8c=
X-Received: by 2002:a02:6d0a:: with SMTP id m10mr16457921jac.133.1591523125276; Sun, 07 Jun 2020 02:45:25 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Date: Sun, 7 Jun 2020 11:45:07 +0200
Message-ID: <>
To: Jaime Jimenez <>
Cc:,,, dhcwg <>
Content-Type: multipart/alternative; boundary="00000000000088d9f505a77b5aa3"
Archived-At: <>
Subject: Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-slap-quadrant-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Jun 2020 09:45:44 -0000

Hi Jaime,

Thanks a lot for your review. Please see my comments and responses inline

On Thu, Jun 4, 2020 at 9:58 AM Jaime Jimenez via Datatracker <> 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).

> 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.

> 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.

> 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
>     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.

>     "[...] 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.

>     "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).

>     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.

>     "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).

>     A style suggestion, as "Advertise", "Renew", "Reply", etc are specific
>     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.

> 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.

> 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

> References:
>     [IEEEStd802c-2017] does not provide a link to the document. It would be
>     useful to include that when available.

[Carlos] OK, noted. Thanks.

Thanks a lot.