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

["Ms. Li HUANG" <[e-mail]>]

15:45.hk S8 June 06 2020



There are yes so many such etc. I.sight dhcpv6, most time isp,  schemes
arounding yet positive for user under , earlier time published and looking
forward to ipv6 only whether over reckoning , or rush replying to ... ?


by the way ipv4 in May and Jun rather more addresses from each isp mac than
, when the  "*ipv6 only in may 2020 globally*" news  published from ietf.org
later on...


Sincerely
Li HUANG

On Fri, Jun 5, 2020, 22:45 Eric Vyncke (evyncke) <evyncke=
[e-mail]> wrote:

> Thank you Jaime,
>
> I will make sure that my IESG ballot will refer to your review
>
> -éric
>
> -----Original Message-----
> From: Jaime Jimenez via Datatracker <[e-mail]>
> Reply-To: Jaime Jimenez <[e-mail]>
> Date: Thursday, 4 June 2020 at 09:58
> To: "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>
> Subject: Iotdir last call review of draft-ietf-dhc-slap-quadrant-07
> Resent-From: <[e-mail]>
> Resent-To: <[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, <[e-mail]>, Eric
> Vyncke <[e-mail]>, Tomek Mrugalski <[e-mail]>,
> Ian Farrer <[e-mail]>, <[e-mail]>
> Resent-Date: Thursday, 4 June 2020 at 09:58
>
>     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."
>
>     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.
>
>     References:
>
>         [IEEEStd802c-2017] does not provide a link to the document. It
> would be
>         useful to include that when available.
>
>
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>