[dhcwg] My comments on draft-yiu-dhc-dhcpv6-sa-00

[Tomek Mrugalski <[e-mail]>]

I read draft-yiu-dhc-dhcpv6-sa-00 and I like the concept. I'm afraid I
have a number of concerns regarding the details, though. As defined, in
my opinion the mechanism will not work in the typical case (relays). As
currently defined, it wouldn't provide any significant protection over
classic DHCPv6. Having said that, I got the impression that it's an
early version with significant (e.g. encryption) pieces still missing. I
encourage authors to continue improving it. Once the draft matures a
bit, I'll possibly revise my opinion.

My concerns:
1. This mechanism seeks to turn DHCPv6 into unicast service. DHCPv6 was
intended as multicast service on purpose and many mechanisms require
multicast to function properly. Rebind, Confirm or failover are 3 examples.

2. Unicast will not work with relays. Booting client typically has only
link-local address and is unable to perform off-link communication. That
will break two things you intend to use: contacting PKI and contacting
the server over unicast.

3. Even when the client would be able to send unicast solicit, the
server would drop it. Bernie pointed out to the specific text where it
is mandated. See second paragraph in Section 15 of RFC3315:

   A server MUST discard any Solicit, Confirm, Rebind or
   Information-request messages it receives with a unicast destination
   address.

4. This mechanism assumes that the server's identity is verified using
its certificate. The text does not specify whether any following
transmissions (solicit, request, renew, ...) are protected or not. They
must be protected, or the whole
solution is useless.

5. This mechanism turns the DHCPv6 server into 6-messages exchange (or
4-messages with rapid-commit). It a non-trivial overhead. It may be
acceptable, but there should be a significant benefit for that price.

Detailed comments about the text:

The text in section 4 says that the client validates received server
certificate through PKI. There's a fundamental problem with this. As
mentioned before, in a typical case where the client just booted, it
only contains link-local address and is simply unable to reach PKI
infrastructure yet.

Does the Authenticate-reply contain server-id option? So far, every
defined message that reached a client always contains server-id option.
I presume that many client implementations may have a check that
discard received messages that do not have server-id.

How is the unicast option used? In a typical deployment there are relay
agents and the client is not on the same link as the server. The client
also initially doesn't have off-link communication capability
(link-local address only), so it can't reach the server that is
off-link. Therefore the Solicit and first Request are always sent over
relays. After the client gets its global address (or other address with
a scope larger than link-local), it then can use unicast to transmit
subsequent messages, e.g. renew, release or additional requests.

How does this mechanism is supposed to work? My understanding of the
text is that the certificates are included in Authenticate/
Authenticate-reply only. If you meant to include them in other messages,
can you point to specific text that codifies that? I seem to have missed it.

Section 5 specifies that the client sends Authenticate messages to
multicast address. Please be specific which multicast address you have
in mind. I presume you have All_DHCP_Relay_Agents_and_Servers in mind,
but this should be specified explicitly.

Section 6.1 mentions that the client should implement a timer. That's
not how timers are handled in DHCPv6. See Section 14 of RFC3315 for
definitions and section 17.1.2 for an example of how those timers are used.

Section 7.1 claims "If the client could unicast message to the server,
the privacy could be improved effectively.". Can you elaborate on that?
In particular, is there really any difference in complexity of
eavesdropping unicast and multicast traffic?

There's also the question whether Solicit, Advertise, Request, Reply and
following are protected or not. If not, please consider the following:
After that verification is done, the client will
blindly trust everything that seems to be coming from the server's
address. An attacker can disable the legitimate server and start an
impostor and it would not be detected. The same is true for a variety of
redirection attacks. And race condition attacks (attacker can wait for
the client to send a message and then rapidly send response in hope it
will reach the client before the legitimate server's actual
response). How would such attacks be detected?

Finally, I think you don't need new message types. Instead of using
Authenticate / Authenticate-reply, you could use inf-request/reply
exchange. You can do that even in an existing implementations that
support custom option definitions. Note that client-id is usually
included in inf-request, but it's not mandatory. It's possible and
perfectly conformant to send anonymous inf-request.

It is unclear whether you want to define encryption in this draft or
seek to define it in the future as a follow-up draft. In any case, you
should add some clarifying text about it.

Hope that helps. I'm sorry I was unable to provide more positive feedback.

Tomek