Last Call Review of draft-ietf-dhc-slap-quadrant-07

Request Review of draft-ietf-dhc-slap-quadrant
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Internet of Things Directorate (iotdir)
Deadline 2020-05-27
Requested 2020-05-13
Requested by Éric Vyncke
Authors Carlos Bernardos, Alain Mourad
Draft last updated 2020-06-04
Completed reviews Iotdir Last Call review of -07 by Jaime Jimenez (diff)
Intdir Last Call review of -08 by Tatuya Jinmei (diff)
Secdir Last Call review of -07 by Carl Wallace (diff)
Genart Last Call review of -09 by Ines Robles (diff)
Please have a review from the IoT point of view. I also suggest to have the same reviewer as draft-ietf-dhc-mac-assign as the I-D are linked together.

Thank you

Assignment Reviewer Jaime Jimenez 
State Completed
Review review-ietf-dhc-slap-quadrant-07-iotdir-lc-jimenez-2020-06-04
Posted at
Reviewed rev. 07 (document currently at 12)
Review result Ready with Nits
Review completed: 2020-06-04


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:


   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.

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