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

["Bernie Volz (volz)" <[e-mail]>]

Hum ... I never seemed to have received the original email - https://mailarchive.ietf.org/arch/msg/iot-directorate/AlkuS7PgeTwQStM9eFsf4gbOhSw.

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?

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 https://tools.ietf.org/html/rfc8415#section-22. Perhaps more clarity on what should be added would help?

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.

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.

- Bernie


-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]> 
Sent: Saturday, May 23, 2020 2:55 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Tomek Mrugalski <[e-mail]>; Ian Farrer <[e-mail]>; [e-mail]; [e-mail]
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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this useful and easy to read document.

Please also address the IoT Directorate review by Samita Chakrabarti:
https://datatracker.ietf.org/doc/review-ietf-dhc-mac-assign-06-iotdir-lc-chakrabarti-2020-05-11/

Regards

-éric