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

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 24 Mar 2015 16:01:36 -0500

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

---

From: Linhui Sun <[email-masked]>
Date: Wed, 25 Mar 2015 17:00:30 +0800

Hi, Tomek

I'm pretty grateful for your careful review of this draft. First I have to
say that I'm really sorry for submitting such an immature document. And
it's my mistake that failing to explain the general idea and some key
points clearly in the document. I wish I could make difference this time.

The main idea of this design is to provide a trusted relationship between
client and server before the typical 4-message exchange (or 2-message
exchange with Rapid Commit). Compared with existed authentication
mechanism, our design focused more on the privacy which requires none
important client info (e.g. client info in SOLICIT) will be leaked. This is
the reason why we added two extra messages before the typical process. Only
the trusted relationship has been set up, could the client and server
encrypt their following messages to mitigate the privacy issue.

We are not aimed at changing DHCPv6 service into a unicast service. Unicast
was just considered as a potential further protection when we first wrote
this document which seems not to be a wise proposal now (with the help of
your detailed explanation). It's actually my fault that could not evaluate
the possible errors caused by unicast, I'm very willing to delete the
unicast part since it may lead to several unexpected results and could not
make a difference in privacy mitigation.

As for the encryption, we are not very sure whether the WG has a
requirement or a consensus to do it. Personally, I'm very willing to add
this part to make the design more completed. Since without the
confidentiality, the pre-authentication is meaningless. I'm sorry that
current version does not clarify it clearly and we will add the encryption
as a mandatory part of this draft in next version.

Thanks again for your useful comments and suggestions, please also see some
comments inline.

>    Information-request messages it receives with a unicast destination

[Linhui] Thanks for letting me know the risk of using unicast, we will not
propose to use unicast in the following version.

> acceptable, but there should be a significant benefit for that price.

[Linhui] We will propose to make the following transmission protected by
encryption, do you think such a protection is appropriate? If so, do you
think it is significant enough to support the overhead?

> only contains link-local address and is simply unable to reach PKI

[Linhui] The client could validate the server cert signed by a CA locally
(with the help of locally stored root certificate).

> discard received messages that do not have server-id.

[Linhui] In the current version the server-id option is only optional, we
will make it mandatory in the next version.

> subsequent messages, e.g. renew, release or additional requests.

[Linhui] In the context of this document, the only purpose of the unicast
option is to carry the server's address. It is not an indication for client
to use unicast to transmit following message. However I'm not sure whether
it is suitable to change the original purpose of this unicast option.

> but this should be specified explicitly.

[Linhui] Yes, and we will declare it explicitly.

> definitions and section 17.1.2 for an example of how those timers are used.

[Linhui] Sorry for not being familiar with the 3315, we would modify this
part in the next version.

> response). How would such attacks be detected?

[Linhui] As I mentioned before, we will make the encryption mandatory, do
you think it is enough? Is there any other potential protection methods?

> perfectly conformant to send anonymous inf-request.

[Linhui] What I need in this document is just two extra messages, I'm OK
with using inf-request/reply. But I'm just wondering could it work properly
under the scenario "client-server exchanges involving two messages"?

> should add some clarifying text about it.

[Linhui] I think it is clear now that we will define encryption in this
draft. It seems we also need to make some changes in the first two-message
exchange. There should be public keys to be carried in the interaction to
support the further encryption.

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

Best Regards,
Linhui