Re: [dhcwg] [E] [Iot-directorate] Iotdir last call partial review of draft-ietf-dhc-mac-assign-06

"Chakrabarti, Samita" <> Thu, 28 May 2020 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDD6E3A0D19 for <>; Thu, 28 May 2020 09:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.b=sNlBJUWV; dkim=pass (2048-bit key) header.b=jEUBH6Yh
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rNnoNtUSVc0j for <>; Thu, 28 May 2020 09:42:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E09F43A0EE7 for <>; Thu, 28 May 2020 09:42:12 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 04SGdcZj117094 for <>; Thu, 28 May 2020 12:42:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=corp; bh=ouYShFs1VeBkmQFsEG6O5Vhd6qUK05D9AVYKVceNnDU=; b=sNlBJUWVu0LFolX+OjyZFuOcUJlk6pAHoGZOYHuwSHJEB4la/ToSg2R5xzMMyM5iJ2D4 xdtlKgMvgdmU9mODx+CnUxdUyAJvIKraZpXgtMATnHTYbUPGXiwACYQmwghNq1SwMYMM uEpknsGZxL3/NZv6g95zRPHuL4PoJVsQ6FA=
Received: from ( []) by with ESMTP id 316wyfq6ax-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <>; Thu, 28 May 2020 12:42:11 -0400
Received: by with SMTP id 187so15578218oor.18 for <>; Thu, 28 May 2020 09:42:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ouYShFs1VeBkmQFsEG6O5Vhd6qUK05D9AVYKVceNnDU=; b=jEUBH6Yh4TMfBfNMrTViLhcYhrCHmHIAfxu22WxtQq5irPSDQxKibAkUOusKZzGZbZ azfuTeI+8bbpRDnAqJdG0o55xgy7B3+oQMZxBdtzO2cP4o2/47XrISA9/n4U+03QZMR9 E9fBazsr+rggb51HbVtkGH+15Jkcp1wBsRu7iSlpNt883Hdn4KvkXC7DmML4yK/W+3ks Hpj4vHScBzOKMCNyWwESBgD/4I2ZGQVvCMYND+kyCFcRzNwcGRGspnj9LZC7X+XSNZjN C/YEq4CTf1ejoV7wVnDfmPtL2phUPaBGhajm7GabwAR/6HgRp5W2zQvrJirTjKSvMYPY CDSg==
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=ouYShFs1VeBkmQFsEG6O5Vhd6qUK05D9AVYKVceNnDU=; b=LFUlz9D6Yjn1Go85vdu+SvUOgK1/kKVreT4ko5yMMBBNj83iLFVjDpJDuK79YqCMa6 zqUsfG3zJuLGTKdmjXJBEod6EjEOxfH3ULTBduk3Q34rSV4zseQ9swvs2UZxB2BY4DPS +ArUbL3/QyzuH5KdVF+MIww+Ommh9xMFAhDvJjsLe8IPSwRoyuiJLsveM4wy8hQPgAE9 M6PHCixcKTK0TeI3596dMLsA8uT5BhnzQ40obfU4aobGenNwi7h48hCal64ctcjz9lrZ QYlcDYHt29HTFoTOwSGXh9QFo5LnFYIpFDtRvHUbt5Hv0zcZVtETzrrEqc8LS18bPdzJ BZbA==
X-Gm-Message-State: AOAM531gO17K/QBzrZLj0P+tdwOo6vph2IAq33VyORrDNZgLLY3f3f+X CnLJUCUJm/hUIjcbOtRiAKEtDsSPPVSRGQQu3h5uUgjiKLT+MJaVBUFrZeyoYgKrYkZLnCDVf19 mM2M5DoJTLQuK/dRTXhNXbA==
X-Received: by 2002:a05:6830:1afa:: with SMTP id c26mr2973135otd.328.1590684130369; Thu, 28 May 2020 09:42:10 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJy/2wfUSg7/NAfvjO+ImxSCpUfup51iN4Wu2FMG08+tDHt68ecNGboewPT48ufU2jZiOHOGVogevN1vbU5jWYQ=
X-Received: by 2002:a05:6830:1afa:: with SMTP id c26mr2973113otd.328.1590684129855; Thu, 28 May 2020 09:42:09 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Chakrabarti, Samita" <>
Date: Thu, 28 May 2020 12:41:58 -0400
Message-ID: <>
To: "Bernie Volz (volz)" <>
Cc: "Eric Vyncke (evyncke)" <>, Samita Chakrabarti <>, "" <>, "" <>, "" <>, Ian Farrer <>
Content-Type: multipart/alternative; boundary="00000000000082cf7705a6b802b4"
X-mailroute: internal
X-Proofpoint-Spam-Details: rule=out_spam_notspam policy=out_spam score=0 mlxscore=0 lowpriorityscore=0 suspectscore=0 phishscore=0 bulkscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 priorityscore=1501 spamscore=0 clxscore=1011 cotscore=-2147483648 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005280114
Archived-At: <>
Subject: Re: [dhcwg] [E] [Iot-directorate] Iotdir last call partial review of draft-ietf-dhc-mac-assign-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 May 2020 16:42:15 -0000

+ 6lo chairs

Hi Bernie,
Thanks for the response. I had done some quick partial review  while
waiting for the full review from Jaime (CC'ed).

Please see in-line below.

On Tue, May 26, 2020 at 4:47 PM Bernie Volz (volz) <> wrote:

> Hum ... I never seemed to have received the original email -
> .
> Some comments below (BV>).
> ---
> I took a quick glance at the draft from IoT point of view (only partial
> review ).
> Section 4.2 talks about the IoT use case as Direct Client Mode -- where
> they
> talk about cheap devices which may not have unique UUID associated with it.
> Note that a client that operates as above that does not have a
>    globally unique link-layer address on any of its interfaces MUST NOT
>    use a link-layer based DUID (DHCP Unique Identifier), i.e., DUID-LLT
>    or DUID-LL.  For more details, refer to Section 11 of [RFC8415].
> 1. However,  it is not clear what  source initial link-layer address
> should be
> used by these devices. should it point to section 6? will that suffice?
> BV> There are two different issues here. One is the DUID this device would
> use for DHCPv6 - we were just pointing out here that these devices must not
> use Link Layer based DUIDs (hence, they should use DUID-EN or DUID-UUID).
> In terms of the "initial link-layer address", I'm not sure that a reference
> to section 6 (I assume of the dhc-mac-assign draft) would be useful? In
> section 4.2, we already say "Upon first boot, the device uses a  temporary
> address, as described in [IEEE-802.11-02-109r0], to send initial DHCP
> packets to available DHCP server", so I'm not sure what is missing?
> Document author would be the best person to decide where to point back to.
If section 4.2 is where the reader should point to, please add a reference
to that section. That will really help with the readability. Section 6 was
a random suggestive question.

> 2. Moreover,  how safe the mechanism would be if the Security section says
> that
> mechanism defined in this draft may be used by a bad actor ?
> BV> I'm also not sure what would be needed here? I guess we could point
> out that randomly selecting an initial mac-address and trusting a DHCPv6
> server to assign an address is very insecure? But that's pretty much
> covered by
> . Perhaps more clarity on what should be added would help?
Yes, more clarity and some suggestion for the IoT devices would help. For
example, if there are suggestions that this solution could be used in a
restrictive environment only, that would be helpful. An IoT security expert
can help provide a suggestion or text here to mitigate possible threats for
IoT devices, in case of low power and low capacity IoT devices.

3. It appears to me the mechanisms are designed for VMs behind an hypervisor
> and then IoT usages are added. My concerns are two fold for challenged low
> capability IoT devices -- 1) will they be able to handle the complicated
> option
> processing described here? 2) How to mitigate the security vulnerability
> for
> IoT devices as direct clients?  (The security section does not talk about
> mitigation)
> Should there be a simpler option processing structure without TLV option
> processing ( i,e a fixed structure part + then TLV part for optional
> information]?
> BV> The TLV structure is what DHCPv6 is based on. I'm not really sure that
> this is that complicated and if it is ... this is OPTIONAL - a IOT device
> could consider using it; of course, if it really is low end perhaps it is
> not the best technique for it? The IEEE was also working on a specification
> for doing link-layer address assignment and theirs (when available) would
> most likely be at a much lower layer in the "stack" and may be better
> optimized for the IOT case (and may also cover the initial allocation issue
> that exists with DHCPv6). So the IOT case was indeed not the first
> priority, as that likely would be better accommodated by IEEE.
Understood.  Perhaps a few sentences (as explained above) may be fine, so
that implementors will be able to make appropriate choices. I agree
additional mechanism for IoT devices may not be worthwhile. Large things
(IoT devices) can certainly use the  DHCP mechanism and the additional
changes specified here. However, I would like 6lo chairs'  comments and
their advice on this.

> BV> I don't know if Carlos might have some more data on the IEEE work, as
> my contacts at IEEE seem to have dried up.

Best regards,


- Bernie
> -----Original Message-----
> From: Éric Vyncke via Datatracker <>
> Sent: Saturday, May 23, 2020 2:55 AM
> To: The IESG <>
> Cc:;;
>; Tomek Mrugalski <>om>; Ian Farrer <
> Subject: Éric Vyncke's Yes on draft-ietf-dhc-mac-assign-06: (with COMMENT)
> Éric Vyncke has entered the following ballot position for
> draft-ietf-dhc-mac-assign-06: Yes
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you for this useful and easy to read document.
> Please also address the IoT Directorate review by Samita Chakrabarti:
> Regards
> -éric