Last Call Review of draft-ietf-dhc-mac-assign-06
review-ietf-dhc-mac-assign-06-iotdir-lc-jimenez-2020-06-03-00

Request Review of draft-ietf-dhc-mac-assign
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Internet of Things Directorate (iotdir)
Deadline 2020-05-19
Requested 2020-05-05
Requested by √Čric Vyncke
Authors Bernie Volz, Tomek Mrugalski, Carlos Bernardos
Draft last updated 2020-06-03
Completed reviews Intdir Last Call review of -06 by Tatuya Jinmei (diff)
Iotdir Last Call review of -06 by Jaime Jimenez (diff)
Iotdir Last Call review of -06 by Samita Chakrabarti (diff)
Secdir Last Call review of -07 by Sean Turner (diff)
Genart Last Call review of -06 by Roni Even (diff)
Opsdir Last Call review of -06 by Tianran Zhou (diff)
Assignment Reviewer Jaime Jimenez 
State Completed Snapshot
Review review-ietf-dhc-mac-assign-06-iotdir-lc-jimenez-2020-06-03
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/AlkuS7PgeTwQStM9eFsf4gbOhSw
Reviewed rev. 06 (document currently at 09)
Review result Ready with Nits
Review completed: 2020-05-11

Review
review-ietf-dhc-mac-assign-06-iotdir-lc-jimenez-2020-06-03

Jaime Jimenez review input: 


draft-ietf-dhc-mac-assign-06 iodir review
==========================================

In general, I am not convinced about the concept presented in the draft of assigning MAC addresses to IoT devices using DHCP. IoT devices normally already arrive with that information from the factory. An IoT device thus would not use a temporary MAC address but the one assigned by the manufacturer instead. On top of my head, I cannot envision a scenario in which the device would need to change its MAC address to the one provided by the DHCP server, maybe other "IoT-people" can pitch in more info on this.

Abstract: It's unclear what "devices" refers to. Might be better to say virtual machines, virtualized processes, network endpoints, etc.

Section 1: Would be useful to add a reference to the "birthday paradox" or a short paragraph describing the problem. I am not qualified to judge but I would think that the sheer number of potential identifiers guarantees that there won't be collisions. Moreover if collisions would occur and are detected, the recovery situation is a simple as assigning a new address.

Section 1: "The huge number of such devices would likely exhaust a vendor's OUI global address space". Pardon the question but aren't OUI's identifying vendors? Is it due to a huge number of IoT vendors then that the address space may be exhausted?

Section 3: The definition of address indicates it is of 6 bytes of length (3 bytes OUI + 3 bytes NIC). It also says that "some network architectures may use different lengths", would it not be better to be precise here as to which are the address formats this document allows?
Which is the structure and length of the address block? Is it 6 bytes for the address + 4 bytes for the number? How is it serialized in the DHCP communication?

Section 4.2: It is a bit odd to have an informative reference which is a short bullet point Power Point presentation. Aren't there other references to [IEEE-802.11-02-109r0]? It is good that there is a description within the paragraph.
typo: "assigns a address" / an
notes: "(e.g. medical) / could be a more exhaustive list; medical, environmental, presence...

Section 5: what does "IA container" stand for?

Section 6: This section could provide one or two examples, also an example of a serialized address block.

Section 13: I think there are probably new security threads when using this mechanism for IoT. I'd guess the mechanism can be abused by, for example, requesting multiple address blocks to the DHCP server.


Ciao!
-- Jaime
(jaime@iki.fi)

Review is partially done. Another assignment may be needed to complete it.

Reviewer: Samita Chakrabarti
Review result: Almost Ready

 I took a quick glance at the draft from IoT point of view (only partial review
 ).

Section 4.2 talks about the IoT usecase 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?

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 ?

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]?