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

From: Jaime Jimenez via Datatracker <[email-masked]>
Date: Thu, 04 Jun 2020 00:58:17 -0700

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.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 5 Jun 2020 14:45:03 +0000

Thank you Jaime,

I will make sure that my IESG ballot will refer to your review

-éric

-----Original Message-----
From: Jaime Jimenez via Datatracker <[email-masked]>
Reply-To: Jaime Jimenez <[email-masked]>
Date: Thursday, 4 June 2020 at 09:58
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Iotdir last call review of draft-ietf-dhc-slap-quadrant-07
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Eric Vyncke <[email-masked]>, Tomek Mrugalski <[email-masked]>, Ian Farrer <[email-masked]>, <[email-masked]>
Resent-Date: Thursday, 4 June 2020 at 09:58

    Reviewer: Jaime Jimenez

    Abstract:

    Section 1:

    Section 3:

    Section 4.1:

    Section 4.2:

    Section 7:

    References:

---

From: "Ms. Li HUANG" <[email-masked]>
Date: Sat, 6 Jun 2020 15:51:48 +0800

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=
[email-masked]> wrote:

> Cc: "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> Resent-To: <[email-masked]>, <[email-masked]>, <
> [email-masked]>, <[email-masked]>, <[email-masked]>, Eric
> Vyncke <[email-masked]>, Tomek Mrugalski <[email-masked]>,
> Ian Farrer <[email-masked]>, <[email-masked]>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Sun, 7 Jun 2020 11:45:07 +0200

Hi Jaime,

Thanks a lot for your review. Please see my comments and responses inline
below.

> draft-ietf-dhc-slap-quadrant-07 iodir review

[Carlos] Done. Changes applied in -10 version (to be released after
collecting all comments from IESG review).

>     "different assignment approaches in four specified regions of the"

[Carlos] Since IEEE 802c also defines the regions, we believe it's better
to keep the original wording to make this more explicit.

>     I wonder if collisions are likely to occur in practice.

[Carlos] Collisions are always possible, since devices can always select
their own address without using a delegation mechanism, but not very
likely. draft-ietf-dhc-mac-assign has some security considerations about
 address collisions.

>     how are potential collisions or attacks preventable?

[Carlos] It is always possible that a device self-assigns a MAC address
from any quadrant, though for some quadrants it is not the expected use
(therefore, if a device does it, it would not be behaving as
specified). draft-ietf-dhc-mac-assign has some security considerations
about  address collisions that would apply here as well.

>     (i.e., by reducing the address block)

[Carlos] OK, we have added some examples in -10.

>      - to start on step 1 with the new QUAD if the block is no longer

[Carlos] Not sure I got it right, but Step 5 does not cause going back to
step 1. It basically includes the preferred SLAP quadrants again to
facilitate the server allocating _different_ addresses to the ones the
client got assigned, in case the server cannot extend the lifetime of these
ones (e.g., because of a renumbering policy).

>     in use in case the block is no longer available?

[Carlos] Please check if my response beforer clarifies this.

>     available? How is the REPLY format denying the addresses?

[Carlos] In this case the client would know by checking the allocated
address(es) (if they are different, that means that the addresses are no
longer available, and the client would know from which quadrant they belong
to, as this is implicit from the address itself).

>     "RENEW", "REPLY", etc to avoid potential confusion.

[Carlos] Here we've followed the same approach as
in draft-ietf-dhc-mac-assign. If we change it, we should do it in both.

>     Same as in section 4.1, steps 9 to 12 might need to be revised.

[Carlos] Please see if my responses to 4.1 are satisfactory.

>     mechanisms for DHCP would be handy.

[Carlos] We mainly refer to RFC 8415 and RFC 7227 for all the security
mechanisms of DHCP, and also to draft-ietf-dhc-mac-assign for some
additional considerations regarding link-layer address assignments using
DHCP.

>     useful to include that when available.

[Carlos] OK, noted. Thanks.

Thanks a lot.

Carlos

---

From: Jaime Jiménez <[email-masked]>
Date: Mon, 8 Jun 2020 14:14:17 +0300

Hi Carlos,

I believe this solves all of the issues I raised on my review. Thanks
for the prompt response, I wrote some comments below.

Ciao,

-- Jaime Jiménez

> collecting all comments from IESG review).

[Jaime] OK

> to keep the original wording to make this more explicit.

[Jaime] OK

> likely. draft-ietf-dhc-mac-assign has some security considerations about

[Jaime] Thanks, if you have some literature on the topic, I'd be happy to read
it off-list.

> about  address collisions that would apply here as well.

[Jaime] draft-ietf-dhc-mac-assign Security considerations where rather thin too,
mostly the references to RFC8415 and RFC8200 and the mention of link-layer 
address collision. If that is the only new issue then that's OK, I
assume the SECDIR had a look on it.

> [Carlos] OK, we have added some examples in -10.

[Jaime] I am unable to find -10 but I trust the changes are addressed. 

> ones (e.g., because of a renumbering policy).

[Jaime] When we say "preferred SLAP quadrants" are we to assume that they are
the same the client has already been using or is that an uncommon case?

I would maybe write a sentence or two including your explanation and
some normative text (e.g., that the client MAY try with the existing ones and 
that the server MAY assign different ones due to renumbering or other factors).

> [Carlos] Please check if my response beforer clarifies this.

[Jaime] From the previous response I understand that the client can choose to
request the same SLAP quadrant or another different one.

> to, as this is implicit from the address itself).

[Jaime] OK so the server will _always_ reply with some address
allocation. Could this mechanism not be abused by clients requesting
new blocks too frequently?

> in draft-ietf-dhc-mac-assign. If we change it, we should do it in both.

[Jaime] It was just a style suggestion, someone versed in the field will
probably know it right away. So, it's up to the authors.

> [Carlos] Please see if my responses to 4.1 are satisfactory.

[Jaime] I think the Relay behaviour is OK as described. 

> additional considerations regarding link-layer address assignments using

[Jaime] As I mentioned above, if the authors consider that new potential
threats are covered and SECDIR is fine then it should be OK. 

> [Carlos] OK, noted. Thanks.

[Jaime] Thanks!

---

From: "Ms. Li HUANG" <[email-masked]>
Date: Fri, 19 Jun 2020 13:51:47 +0800

the Terpedo after isp ipv6 offering later, function, quandary, and set at
sg3xx routes remaining:

    -    os such vista 2002:...via it got ipv6 first,
    -     found 2001:… prefix , added after, resulting no.e nothing ipv6
showing?

    -      isp claiming not their scope managing Teredo  , who set ipv4
1800 time on, to dhcpv4 server isp, as well Terredo servers to care off
these, when IPv6 Only is a dreaming yet reality completely ?

Sincerely
Li H

On Mon, Jun 8, 2020, 19:14 Jaime Jiménez <[email-masked]> wrote:

> > > 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.
> > >
> > > draft-ietf-dhc-mac-assign, and I regret not having paid more attention
> to
> > > it
> > > 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
> > >     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,
> > >     existing block- with _alternative_ SLAP quadrants different than
> the
> > > ones
> > >     A style suggestion, as "Advertise", "Renew", "Reply", etc are
> specific
> > > DHCP