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

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Jan 2018 11:26:32 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-dhc-rfc3315bis-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/

----------------------------------------------------------------------
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.

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'm a little sad that the transaction ID is so short. This doesn't
seem like really enough to provide uniqueness against guessing
attacks.

We're trying to discourage HMAC-MD5. Do you have any way to
transition to something stronger?

The description of how to actually do replay detection seems pretty
thin. Do you think more detail would be helpful here.

Editorial:

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..."

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

S 4.2.
When acronyms are used ahead of their definition, it would be good to
expand them.

S 21.22.
What is the part of the IPv6-prefix after prefix-length filled with?
Does it matter?

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 23 Jan 2018 01:14:08 +0100

> draft-ietf-dhc-rfc3315bis-10: No Objection
Hi Eric,

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

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."

> those values and feed them into a hash function and then you
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.

> seem like really enough to provide uniqueness against guessing
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.

> 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.

> 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."

> Perhaps "DHCP can also be used just to provide..."
Sounds good.

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

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

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

Tomek

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Jan 2018 16:25:15 -0800

On Mon, Jan 22, 2018 at 4:14 PM, Tomek Mrugalski <[email-masked]
> wrote:

>   as quickly as possible is a priority."

Yes, that helps.

> that already use those DUID types.

Well, we could encourage people to move to a UUID type for sending, no?

> Even if the transaction was much larger, it is sent by the client to a

Fair enough.

> the draft-ietf-dhc-sedhcpv6 was abandoned at revision -21.

Yeah, that's what I expected.

> effectively rendering the reconfigure mechanism useless."

This seems like it scales badly as you need to keep an infinite replay
list. What happens if you falsely declare something a replay?

> add a text that clarifies that.

thanks
-Ekr

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 23 Jan 2018 02:07:32 +0100

On 01/23/18 01:25, Eric Rescorla wrote:
> On Mon, Jan 22, 2018 at 4:14 PM, Tomek Mrugalski
> <[email-masked] <mailto:[email-masked]>> wrote:
> 

> Well, we could encourage people to move to a UUID type for sending, no?
In many environments there is no standard way of getting the UUID. As an
implementor of DHCPv6 client I have no idea how to check whether the
hardware provides access to its UUID. Also, sysadmins like usage of LLT
and LL, because it has MAC address in it. This is something they know
and can read from the box or from the device itself. It's reasonable to
ask a user "what's your mac address?" but it's much more tricky to ask
"what's your uuid?" and expect to get a coherent answer.

There may be privacy concerns, too. Once your phone discloses its UUID,
it's much easier to track it and changing MAC address wouldn't help you
at all. Devices using anonymity profile (RFC7844) must use LL type.

I'm not saying that UUID is a bad type of DUID, just pointing out that
it has its own issues. But does it matter that much? DUID is just a blob
that must be unique and the server uses it to identify a client. If the
DUID is of certain type, additional information about the client can be
printed and that's about it.

> list. 
Not at all, unless your client interacted with infinite number of
servers and intends to visit them again. The server stores a single 64
bit integer. Every time a packet is sent, that value is incremented. The
client stores one value for every server it wants to continue
communicating with. For great majority of cases this would be one
server. For mobile clients that visited multiple locations and have the
capability to retain the information to possibly resume operation in
previous locations that would be a handful of servers at most.

> What happens if you falsely declare something a replay?
If you falsely declare something a replay (why would you do that?), the
reconfigure packet is dropped by the client. The server will retransmit
its reconfigure message with a higher value which hopefully be accepted
by the client. If you somehow sabotage the client or trick it to believe
that a very high value of replay detection was sent previously, it will
continue to reject reconfigure messages. So you effectively disabled the
reconfigure mechanism on that client, but it continues to operate and
can still renew its configure, just after t1 timer, not immediately.

Note that the replay detection is intended to be used with RKAP. So in
principle you could perform an attack by sending a packet with high
replay detection to confuse the client, but to do that you'd have to
also put the correct HMAC-MD5 digest. Otherwise the client will discard
your packet. If you have that ability, then you can do worse things than
confuse client's notion of a replay value.

There is a text about possibility of exploiting the reconfigure key
mechanism to attack a client. Do you think we should extend it to also
mention the replay attack?

Tomek

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Jan 2018 18:10:40 -0800

On Mon, Jan 22, 2018 at 5:07 PM, Tomek Mrugalski <[email-masked]

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

I think you're misunderstanding me. What I am proposing is that you take the
DUID input values, hash them, and use them as input to a name-based
UUID: https://tools.ietf.org/rfcmarkup?doc=4122#section-4.3

> previous locations that would be a handful of servers at most.

It seems like you're assuming that the client can only have one outstanding
transaction with the server. Is that correct?

-Ekr

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 23 Jan 2018 02:53:03 +0000

Hi:

I don’t see need to change DUID practices that have been used for a long number of years (as originally specified in 3315). There are a lot of things one could do, but what’s the benefit? And, if you’d really like the WG to develop a new format, that doesn’t seem something to do in a bis document?

Regarding Replay Protection, as this is for Reconfigure (server to client), there should only be a need for a single Reconfigure per client. Even if multiple are sent by server for a single client, that only causes some to fail replay checks if out of order delivery or processing and means maybe some are dropped, which isn’t an issue (especially as now Reconfigure no longer communicates what may need reconfiguration).

- Bernie (from iPad)

On Jan 22, 2018, at 9:11 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Jan 22, 2018 at 5:07 PM, Tomek Mrugalski <[email-masked]<mailto:[email-masked]>> wrote:
On 01/23/18 01:25, Eric Rescorla wrote:
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>

-Ekr

Tomek

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Jan 2018 18:56:34 -0800

On Mon, Jan 22, 2018 at 6:53 PM, Bernie Volz (volz) <[email-masked]> wrote:

> Hi:
>
> I don’t see need to change DUID practices that have been used for a long
> number of years (as originally specified in 3315). There are a lot of
> things one could do, but what’s the benefit?
>

The benefit is that you have a pile of different mechanisms which are
redundant. This would simplkify that.

And, if you’d really like the WG to develop a new format, that doesn’t seem
> something to do in a bis document?
>

I'm not suggesting a new format. You already support UUIDs. I'm suggesting
that you recommend that people use UUIDs and generate them using the same
inputs they already use for generating the other DUIDs.

Regarding Replay Protection, as this is for Reconfigure (server to client),
> there should only be a need for a single Reconfigure per client. Even if
> multiple are sent by server for a single client, that only causes some to
> fail replay checks if out of order delivery or processing and means maybe
> some are dropped, which isn’t an issue (especially as now Reconfigure no
> longer communicates what may need reconfiguration).
>

All right

-Ekr

>
> - Bernie (from iPad)
>
> On Jan 22, 2018, at 9:11 PM, Eric Rescorla <[email-masked]> wrote:
>
>
>
> On Mon, Jan 22, 2018 at 5:07 PM, Tomek Mrugalski <
> [email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Jan 2018 22:43:55 -0500

On Jan 22, 2018, at 9:56 PM, Eric Rescorla <[email-masked]> wrote:
> The benefit is that you have a pile of different mechanisms which are redundant. This would simplkify that.

Except that this is a -bis document, so the mechanisms don't go away with this optimization, and the optimization itself is actually more work than doing what the document currently specifies, since the server doesn't care which option you pick, and the client is going to pick exactly one.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Jan 2018 19:49:14 -0800

On Mon, Jan 22, 2018 at 7:43 PM, Ted Lemon <[email-masked]> wrote:

> Except that this is a -bis document, so the mechanisms don't go away with
> this optimization, and the optimization itself is actually more work than
> doing what the document currently specifies, since the server doesn't care
> which option you pick, and the client is going to pick exactly one.
>

Well, maybe. It allows you to encode something fixed-length, even if you
derive it from something variable length.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Jan 2018 22:54:30 -0500

On Jan 22, 2018, at 10:49 PM, Eric Rescorla <[email-masked]> wrote:
> Well, maybe. It allows you to encode something fixed-length, even if you derive it from something variable length.

Why does that matter?   Sad to say, we are not encrypting any of this, so padding isn't needed.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Jan 2018 19:59:32 -0800

On Mon, Jan 22, 2018 at 7:54 PM, Ted Lemon <[email-masked]> wrote:

> Why does that matter?

Fixed-length encodings are easier to work with -- including to generate --
than non-fixed length.

In any case, this is a comment, so you guys should feel free to ignore it.

-Ekr

  Sad to say, we are not encrypting any of this, so padding isn't needed.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Jan 2018 23:05:31 -0500

On Jan 22, 2018, at 10:59 PM, Eric Rescorla <[email-masked]> wrote:
> Fixed-length encodings are easier to work with -- including to generate -- than non-fixed length.

For better or for worse, that ship sank when we chose to use TLVs.

> In any case, this is a comment, so you guys should feel free to ignore it.

Yup, thanks.   I think we should probably leave well enough alone in this case.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jan 2018 08:49:00 -0500

ekr>    The benefit is that you have a pile of different mechanisms which
    ekr> are redundant. This would simplkify that.

    ted>    Except that this is a -bis document, so the mechanisms don't go away
    ted> with this optimization, and the optimization itself is actually more
    ted> work than doing what the document currently specifies, since the server
    ted> doesn't care which option you pick, and the client is going to pick
    ted> exactly one.

What Ted said (at most we can deprecate features, but not unify some features
into a new feature.  There is an xkcd for that...)... but also: the DUID
generation is essentially a local client matter, so this multiplicity of
formats does not really affect the protocol or require any extra code.

Servers can and do treat all DUIDs as opaque blobs of bytes, and that's it.
(Mine does this.)

Some DUID formats can elucidate more info for the servers and operators that
care, but as the trend on clients (dnsmasq, I think) is towards feeding
some stuff into a hash function and saving the result for later on.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-