Subject: [Dhcpv6bis] Comments on Ted's 3315bis Comments

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 14 Sep 2016 16:36:35 +0000

Ted, at al:

I haven't yet reviewed the suggested replacement text, but I did have some comments on your other issues before this text. As a reminder, see https://docs.google.com/document/d/1khTnbBIhvNwFTvbrs4uJ_mm1sjw16MpXQJXpeIeEDT8.

Regarding the server-unicast issue, it is a good one to raise. We should address this (at a minimum) in the security considerations section. My basic assumption is that a network operator shouldn't allow DHCPv6 traffic in from outside and so this would not be a very successful attack. The Security Considerations does already state:

   The threat to DHCP is inherently an insider threat (assuming a
   properly configured network where DHCP ports are blocked on the
   perimeter gateways of the enterprise).  Regardless of the gateway
   configuration, however, the potential attacks by insiders and
   outsiders are the same.

Perhaps we should say a bit more (such as use of server-unicast and its consequences)?

Regarding the Information-Request & a selection process, yes this seems like a good idea. Should we open a ticket for this and discuss more widely in the WG to gain consensus for this change?

Regarding the preference option ... this one seems best to leave alone as there is RFC 6853 (DHCPv6 redundancy without failover) that makes use of it and seems like a good usage model (it was and is used by many of our customers). I think it generally has worked very well. Yes, it can be misused, but if it was dropped (or both the good and bad DHCP servers both use 255), the end result is random. So, I'm not sure there's much risk in it (without other security measures). Again, DHCPv6 shield (rfc7610) can prevent this issue pretty well since it prevents rogue servers (at least in switched environments).

BTW: For the 255 case, I wonder whether we should allow an exception to NOT use the Advertise if it doesn't meet all of the clients requirements (i.e., only immediately use it if it is sufficient to address the client's needs - otherwise, client should be allowed to use a lower preference one that does meet its needs)?

-          Bernie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Sep 2016 16:21:36 -0400

On Wed, Sep 14, 2016 at 12:36 PM, Bernie Volz (volz) <[email-masked]> wrote:

> I haven’t yet reviewed the suggested replacement text, but I did have some
> comments on your other issues before this text. As a reminder, see
> https://docs.google.com/document/d/1khTnbBIhvNwFTvbrs4uJ_
> mm1sjw16MpXQJXpeIeEDT8.
>

Saw those, they looked good, will address in a bit.

>  Regarding the server-unicast issue, it is a good one to raise. We should
> address this (at a minimum) in the security considerations section. My
> basic assumption is that a network operator shouldn’t allow DHCPv6 traffic
> in from outside and so this would not be a very successful attack. The
> Security Considerations does already state:
>
>
>

I think this text is actually wrong.   We should be _advising_ people to
block DHCP traffic both at the edge and at layer 2.   But we can't assume
that it's blocked, or even that it's blockable in all cases, so what we set
up has to work regardless.   This is why I think we need to be careful.

> Perhaps we should say a bit more (such as use of server-unicast and its

Yes.   I suppose I should send text. :)

> Regarding the Information-Request & a selection process, yes this seems
> like a good idea. Should we open a ticket for this and discuss more widely
> in the WG to gain consensus for this change?
>

Yes.

> Regarding the preference option … this one seems best to leave alone as
> there is RFC 6853 (DHCPv6 redundancy without failover) that makes use of it
> and seems like a good usage model (it was and is used by many of our
> customers). I think it generally has worked very well. Yes, it can be
> misused, but if it was dropped (or both the good and bad DHCP servers both
> use 255), the end result is random. So, I’m not sure there’s much risk in
> it (without other security measures). Again, DHCPv6 shield (rfc7610) can
> prevent this issue pretty well since it prevents rogue servers (at least in
> switched environments).
>

The end result is likely deterministic, actually: whichever server is
faster will always win.

What does the 255 trump card get you that you couldn't get with one server
sending 254 and one sending 253?

BTW, I don't know if I mentioned it, but this same problem exists with
rapid commit.

> BTW: For the 255 case, I wonder whether we should allow an exception to
> NOT use the Advertise if it doesn’t meet all of the clients requirements
> (i.e., only immediately use it if it is sufficient to address the client’s
> needs – otherwise, client should be allowed to use a lower preference one
> that does meet its needs)?
>

I think the much longed-for/dreaded DHCP security spec offers a bit of an
answer to this, by making it harder for a fake DHCP server to assert its
primacy.   But I think that this is pretty clearly a security
vulnerability; the question is whether we think it's enough of one to
change the recommended behavior for 255.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 23 Sep 2016 01:37:43 +0000

So, I think you are proposing to just not treat 255 special - client should continue collecting Advertises.

Regard Rapid Commit - yes similar issue but there is no preference & assumption is that there is only one server.

Bottom line is to use https://tools.ietf.org/html/rfc7610 to prevent rogue servers.

- Bernie (from iPad)

On Sep 22, 2016, at 4:22 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

The end result is likely deterministic, actually: whichever server is faster will always win.

What does the 255 trump card get you that you couldn't get with one server sending 254 and one sending 253?

BTW, I don't know if I mentioned it, but this same problem exists with rapid commit.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Sep 2016 21:57:03 -0400

The problem with the assumption that there is only one server is that
there's no basis for making the assumption.   But as long as it's not the
default behavior on clients, it's not a big problem, and the mitigation is
pretty obvious: don't enable rapid commit unless you know the client is
always going to be in an environment that is well controlled, e.g. using
7610.

On Thu, Sep 22, 2016 at 9:37 PM, Bernie Volz (volz) <[email-masked]> wrote:

> Regard Rapid Commit - yes similar issue but there is no preference &
> assumption is that there is only one server.
>
> On Sep 22, 2016, at 4:22 PM, Ted Lemon <[email-masked]> wrote:
>
> <#m_103161891350559378_>