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

["Bernie Volz (volz)" <[e-mail]>]

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



On Mon, Jan 22, 2018 at 5:07 PM, Tomek Mrugalski <[e-mail]<mailto:[e-mail]>> wrote:
On 01/23/18 01:25, Eric Rescorla wrote:
> On Mon, Jan 22, 2018 at 4:14 PM, Tomek Mrugalski
> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>
>     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
>     >

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

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


>     > 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."
> This seems like it scales badly as you need to keep an infinite replay
> 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.

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

-Ekr



> 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