Re: [dhcwg] Eric Rescorla's No Objection on draft-ietf-dhc-rfc3315bis-10: (with COMMENT)

[Tomek Mrugalski <[e-mail]>]

On 01/21/18 20:26, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-dhc-rfc3315bis-10: No Objection
Hi Eric,

Thank you for your review and your favourable ballot. See my answers below.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Document: draft-ietf-dhc-rfc3315bis-10.txt
> 
> This document was quite clear and well written. A few small comments
> below.
> 
> It would have been easier for me to have a bit of intro about why
> both the 4-message and 2-message rapid commit exchanges exist
> and maybe some guidance about when to use each one.
How about this text being added early to Section 5.1:
  "It is sometimes desired to expedite the configuration process from
  typical four messages down to two. This may be desired for couple
  reasons. The first one is when there is only one server available
  on link and there is no expectation that a second server would become
  available. The second is when completing of the configuration process
  as quickly as possible is a priority."

> I am finding the guidance on DUIDs a bit confusing. Rather than
> having a bunch of constructions that produce variable length
> things that are intended to be unique, why not just take all
> those values and feed them into a hash function and then you
> could just have UUIDs?
I was not participating in the original discussion that led to this
decision back around 2002, but I can imagine there was a need to
generate unique identifiers by devices with various capabilities (thus
with/without timestamp variants). This concept predates usage of UUIDs
in IETF, which as far as I can tell was first mentioned in RFC4122.

Anyway, this part of the spec hasn't changed in bis. It would be
extremely difficult to make any changes as there are millions of devices
that already use those DUID types.

> I'm a little sad that the transaction ID is so short. This doesn't
> seem like really enough to provide uniqueness against guessing
> attacks.
This was never meant as protection, simply as a way to differentiate
between separate transactions that could be happening at the same time.
Even if the transaction was much larger, it is sent by the client to a
multicast address.

> We're trying to discourage HMAC-MD5. Do you have any way to
> transition to something stronger?
Am afraid not at this time. The whole WG seriously tried very hard, but
the draft-ietf-dhc-sedhcpv6 was abandoned at revision -21.

> The description of how to actually do replay detection seems pretty
> thin. Do you think more detail would be helpful here.
It would. How about this text added to the end of Section 20.3:

"The client that receives a message with RDM field set to 0x00 MUST
compare its replay detection field with the previous value sent by
the same server. If this is the first time a client sees Authentication
option sent by the server, it MUST record the replay detection value,
but otherwise skip the replay detection check.

The servers that support reconfigure mechanism MUST ensure the replay
detection value is retained after restarts. Failing to do that will
cause the clients to refuse reconfigure messages sent by the server,
effectively rendering the reconfigure mechanism useless."

> S 1.
>    DHCPv6 can also provide only other configuration options (i.e., no
>    addresses or prefixes).  That implies that the server does not have
> 
> Perhaps "DHCP can also be used just to provide..."
Sounds good.

> S 2.
> Nit: do you want to cite 8174.
Yes.

> S 4.2.
> When acronyms are used ahead of their definition, it would be good to
> expand them.
Ok, will do that.

> S 21.22.
> What is the part of the IPv6-prefix after prefix-length filled with?
> Does it matter?
Should be filled with zeros by sender and ignored by the receiver. Will
add a text that clarifies that.

Tomek