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

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

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 <[e-mail]> wrote:

> 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
>
> On Sun, Jun 07, 2020 at 11:45:07AM +0200, CARLOS JESUS BERNARDOS CANO
> wrote:
> > Hi Jaime,
> >
> > Thanks a lot for your review. Please see my comments and responses inline
> > below.
> >
> > On Thu, Jun 4, 2020 at 9:58 AM Jaime Jimenez via Datatracker <
> > [e-mail]> wrote:
> >
> > > 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."
> > >
> >
> > [Carlos] Done. Changes applied in -10 version (to be released after
> > collecting all comments from IESG review).
> >
>
> [Jaime] OK
>
> >
> > > Section 1:
> > >
> > >     s/specified regions/regions/ ?
> > >     "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.
> >
> >
>
> [Jaime] OK
>
> > >
> > > 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.
> > >
> >
> > [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.
> >
>
> [Jaime] Thanks, if you have some literature on the topic, I'd be happy to
> read
> it off-list.
>
> >
> > >
> > > 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?
> > >
> >
> > [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.
> >
> >
>
> [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.
>
> > >     "[...] 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)
> > >
> >
> > [Carlos] OK, we have added some examples in -10.
> >
> >
>
> [Jaime] I am unable to find -10 but I trust the changes are addressed.
>
> > >
> > >     "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.
> > >
> >
> > [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).
> >
> >
>
> [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).
>
> > >     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?
> > >
> >
> > [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.
>
> > >
> > >     "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?
> > >
> >
> > [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).
> >
> >
>
> [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?
>
> > >     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.
> > >
> >
> > [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.
> >
> >
>
> [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.
>
> > > 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.
> > >
> >
> > [Carlos] Please see if my responses to 4.1 are satisfactory.
> >
>
> [Jaime] I think the Relay behaviour is OK as described.
>
> >
> > >
> > > 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.
> > >
> >
> > [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.
> >
> >
>
> [Jaime] As I mentioned above, if the authors consider that new potential
> threats are covered and SECDIR is fine then it should be OK.
>
> > > References:
> > >
> > >     [IEEEStd802c-2017] does not provide a link to the document. It
> would be
> > >     useful to include that when available.
> > >
> >
> > [Carlos] OK, noted. Thanks.
> >
>
> [Jaime] Thanks!
>
> > Thanks a lot.
> >
> > Carlos
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>