Subject: [dhcwg] Unnecessary SSO Strictness on DHCPRELEASE?

From: Kevin Darcy <[email-masked]>
Date: Thu, 15 Nov 2012 17:32:28 -0500

(First time posting to this list, please bear with me on any etiquette 
faux pas).

Is the following text from Section 2 of RFC 3011 (Subnet Selection 
Option, aka "SSO") to be interpreted as a MUST NOT:

"This option does not require changes to operations or features of the 
DHCP server other than to select the subnet on which to allocate an 
address."

as in: "DHCP server implementations MUST NOT behave differently 
depending on the presence, absence or contents of an SSO, for DHCP 
transactions NOT involving allocation of an address"?

The reason I ask is because a popular DHCP server implementation 
performs a "subnet validity check" as a precondition to processing a 
DHCPRELEASE packet, and this "subnet validity check" will yield 
different results, depending on SSO in the DHCPRELEASE packet. Couple 
that with a client implementation that doesn't consistently send SSO on 
its DHCPRELEASEs, even when SSO was used for the initial address 
allocation. The end result is that DHCPRELEASEs fail, causing 
inefficient dynamic scope utilization. I could, of course, humor the 
"subnet validity check" code by defining dummy "internal" (in the SSO 
nomenclature) scopes, but it sticks in my craw that I would have to 
define unnecessary and unused DHCP scopes in order for DHCPRELEASEs to 
work as expected.

Rather than an ugly "dummy scope" workaround, I'd prefer to swing the 
standards-compliance cluebat in one of two directions:
1) at the client implementor, for not consistently including SSO on 
DHCPRELEASEs, i.e. failing to be "conservative in what it sends" 
(although absence of any mention of DHCPRELEASE in RFC 3011 makes this a 
somewhat weak argument), or
2) at the server implementor, for being overly strict (perhaps 
accidentally) with its "subnet validity check", i.e. failing to be 
"liberal in what it accepts"

Opinions?

- Kevin

P.S. I hope to replace the use of SSO with VSSO in our next refresh of 
client software, but RFC 6607 apparently doesn't discuss DHCPRELEASE 
either. If anyone is considering -bis versions of either SSO and/or 
VSSO, could we please clarify DHCPRELEASE behavior?

P.P.S. I did search the list archives with several search terms, but did 
not find any previous discussion on this topic.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2012 22:54:49 +0000

On Nov 15, 2012, at 5:32 PM, Kevin Darcy <[email-masked]>
 wrote:
> "This option does not require changes to operations or features of the DHCP server other than to select the subnet on which to allocate an address."
> 
> as in: "DHCP server implementations MUST NOT behave differently depending on the presence, absence or contents of an SSO, for DHCP transactions NOT involving allocation of an address"?

No, the first sentence would translate, in the way you have proposed, to this:

> as in: "DHCP server implementations MAY behave differently depending on the presence, absence or contents of an SSO, for DHCP transactions NOT involving allocation of an address"?

IOW, "does not require" is not synonymous with "requires that there be no."

In this case, I would say that the client is most broken—it should send an SSO consistently with every message, not just with initial messages.   The server is slightly broken—I'm pretty sure there's nothing in the RFC that allows it to disregard a DHCPRELEASE simply because it doesn't contain an SSO.

The document is fairly broken.   If you wanted to update it to explicitly require that the client send an SSO in every packet relating to the lease with which it first sent the SSO, I would support that effort.   

I think that would be a better fix than requiring that the server not behave the way your server does—the behavior you're seeing in the server is more like a non sequitur than a failure to accurately follow the spec.   But it's probably there because the server implementor either had to deal with or expected to have to deal with DoS attacks from off-network.

---

From: Stephen Jacob <[email-masked]>
Date: Thu, 15 Nov 2012 15:40:42 -0800

On Thu, Nov 15, 2012 at 10:54:49PM +0000, Ted Lemon wrote:
> > "This option does not require changes to operations or features of the DHCP
> > server other than to select the subnet on which to allocate an address."
> > 
> > as in: "DHCP server implementations MUST NOT behave differently depending
> > on the presence, absence or contents of an SSO, for DHCP transactions NOT
> > involving allocation of an address"?
> 
> > as in: "DHCP server implementations MAY behave differently depending on the
> > presence, absence or contents of an SSO, for DHCP transactions NOT
> > involving allocation of an address"?
> 

I agree.

> In this case, I would say that the client is most broken?it should send an
> SSO consistently with every message, not just with initial messages.   The
> server is slightly broken?I'm pretty sure there's nothing in the RFC that
> allows it to disregard a DHCPRELEASE simply because it doesn't contain an
> SSO.

I think I agree with this too.

When I first read Kevin's query, my initial thought was that it made
sense that one should always use the SSO, if present, to identify the
link the client is on, thus determining what addresses it might
be permitted to ... act upon in any way, but then when I thought about
it more and verified in our server code base, I realised that, no,
link does not in fact enter into consideration (in our interpretation)
when processing a release.

Link (as determined by giaddr, SSO, receiving interface if broadcast or
source IPv6 address if processing a DHCPv4-over-IPv6 transaction) matters
when deciding what addresses a client might be offered / is allowed to
request, but it doesn't change the contract implied by a lease.

Consider the following:

	1. Client X is on link A, and is given a lease on address P.
	2. Client X moves to link B.
	3. Client X sends a release from link B for address P.

If client X was on link A when they got a lease on address P, then
moves to link B, it *still owns the lease on address P*, so I think it
is perfectly reasonable that client X should be allowed to release its
lease on address P.

> The document is fairly broken.   If you wanted to update it to explicitly
> require that the client send an SSO in every packet relating to the lease
> with which it first sent the SSO, I would support that effort.   

The question would still remain of what a server should do in response
to a client not sending SSO. This would remain a problem server
implementors would need to concern themselves with regardless of how the
standard were changed.

As I indicated above, though, this is not specific to SSO. SSO is just
one of the factors in deciding link, and link is the attribute that an
implementor needs to determine the relevance of in processing a release.

> I think that would be a better fix than requiring that the server not behave
> the way your server does?the behavior you're seeing in the server is more
> like a non sequitur than a failure to accurately follow the spec.   But it's
> probably there because the server implementor either had to deal with or
> expected to have to deal with DoS attacks from off-network.

For this reason, I can imagine the current wording being better than
a more strict, clarified text that limits implementors' options. If we
do choose to clarify it, I think we need to be careful about not
eliminating valid options.

The one thing I would approve of, however, is saying that clients
SHOULD be consistent in sending SSO. Either SSO is used to say what
link they are on or it's not. I cannot think of any justification
for why it would be desirable to drop the SSO from some messages.

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: Stephen Jacob <[email-masked]>
Date: Thu, 15 Nov 2012 15:47:24 -0800

> expected to have to deal with DoS attacks from off-network.

Oh, and one more thought:

If one is concerned about DoS attacks from off-network, it seems more
appropriate to protect against DHCP traffic from ourside one's network
using firewalls than to impose a very weak constraint on DHCP messages.

I don't think making DHCP servers less accepting of RELEASEs missing
SSOs would improve security. About all it seems like it might do is
stop a client from being a good network citizen and freeing up its
no-longer-used lease early.

Regards,
Stephen