Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D

From: Bernie Volz <[email-masked]>
Date: Wed, 2 Feb 2000 15:47:55 -0400

Ted:

Thanks for sending (some) of your concerns.

I'm afraid I can't refrain from at least discussing these issues some.

>I will mention a few places where I see problems with this suboption,
>but again, the purpose of this discussion is to pull the suboption out
>into its own draft and *then* nail it down properly, *not* to nail it
>down properly right now, so please do not argue the points I present
>below with me right now - just take them as examples of why the subnet
>mask suboption ought to be discussed further.
>
>First, what *else* is in the packet the router sends that interacts
>with this suboption?  The giaddr comes to mind.   What should the
>giaddr be?   Should it be specified?   Should the giaddr be one
>greater than the subnet number for the subnet, for example?   Are any
>IP addresses on one of these subnets reserved?   Is the .0 reserved?
>Is the .all-ones reserved?   What about .0+1 and .all-ones-1?   What
>does the server do if the router sends a subnet mask of /30, /31 or
>/32?

Re-read the draft. It says giaddr is required. How else could the
network address be determined (giaddr is ANDed with the Agent Subnet
Mask).

Regarding which addresses are reserved (for broadcasts, for routers,
etc), that was exactly my point as well. BUT, these are CONFIGURATION
issues. Even for failover protocol, we assume both servers have the same
configuration. And, that is why we added an option in the failover
protocol to allow sending client options to the peer - if one server
receives a client request and "creates a scope", by sending the BNDUPD
to the peer, that peer would obviously need to do the same (and it is
assumed that the peer would have the same configuration information).

>What is the purpose of this suboption?   Is it so that routers can
>dynamically add subnets, or just so that routers can inform the DHCP
>server as to their configuration, so that the DHCP server can confirm
>that it's configured correctly?   Or so that the DHCP server can
>implicitly be configured by configuring the router - i.e., to push
>configuration information away from the server and out to the router?

Again, draft says:

"Servers MAY use this mask field to automatically create scopes of
assignable IP addreses. Use of this field avoids the need to have
identical configuration of the logical IP subnets on which clients
reside in both the relaying routers and the DHCP server. In this case,
the router configuration defines the LISs (Logical IP Subnets), and the
DHCP servers automatically discover the LISs from the relay agent
options forwarded client DHCP requests."

I would assume that there is an assumption that the server has SOME
configuration information the (a) enables creation of scopes, and
(b) provides rules for how to create the scopes (reserved addresses,
etc).

>What are the implications if there are two DHCP servers doing
>failover?   Both DHCP servers had better make the same assumptions,
>right?   Do the servers do failover on the new subnet?   What if there
>are two DHCP servers that *aren't* doing failover?

Yes, but we're already assuming that anyway. And see above for how
we've allowed for that to be communicated.

>What happens if somebody sends the DHCP server a forged packet with a
>giaddr of, say, 16.0 and a subnet mask of, say, 255.0?   The ISC DHCP
>server currently preallocates memory for leases, assuming that it's
>better to crash on startup due to a lack of memory than to crash
>later.   So it's going to allocate ~2^24 leases when it receives this
>packet.   This is an instant denial of service attack.   Should I go
>to lazy allocation of leases?   Should there be a recommendation in
>the draft about this?   A security considerations notice?

I would again assume that configuration information would tell the
server when it is allowed to create scopes and for what address ranges
and subnet configurations - at least in the broad sense.

As far as how you do lease allocation, etc, that is a server
implementation issue.

>What happens if there are redundant routers serving the subnet?   What
>routers option does the DHCP server send?   Does it track the IP
>addresses of routers from which it's received this option, and notice
>if two have IP addresses on the same subnet?   What if it's already
>given one of these addresses out?

Again, configuration issues. I'd assume if you're automatically creating
subnets, you'd have details that say the first <n> addresses are used
for routers, etc. See my example "ISC-like" configuration template in my
previous message. That was supposed to communicate this kind of
configuration information.

>What happens if two routers send conflicting information - one saying,
>for example, that 10.0.0.0 is a /24, while the other says it's a /16?

You've got problems. But that's no different than if I configure my
DHCP server with different information from what I configure my
routers. In fact, the whole idea here was to reduce configuration
issues because the routers (relay agents) would know the details.

>How are dynamically-allocated subnets garbage collected?   Are they?

Who are any addresses garbage collected? I think this would require
manual intervention (such as by removing the subnet declarations that
were dynamically created from the configuration file or whereever you're
going to keep them between server reboots).

>Yes, many of these points are operational concerns, but operations is
>part of the protocol.   If the protocol specification doesn't address
>these issues, I can see that for many of these issues, there is the
>potential that one implementor will address the issue one way, and
>another implementor will address the issue another, and that the ways
>in which these issues are addressed will be sufficiently different
>that they will create interoperability problems.

I don't see that much of the above would cause interoperability
problems unless the configuration information produced different
results. But, that's true of what goes on today.

>This is why I want to see a seperate draft for this option.   I'd like
>to see these points addressed in the draft, or at least have a
>discussion about them before the suboption becomes a standard.

OK - we're discussing them.

I don't know why noone else has chimed in one way or the other.

This will be my last communication for a while on this issue as I do
have other issues to address and this isn't exactly on my hot list of
issues.

- Bernie Volz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Feb 2000 16:07:17 -0500

> network address be determined (giaddr is ANDed with the Agent Subnet

No, you missed my point.   My point is this: what *value* should
giaddr have?   Should what the server does depend on the value?   To
make it easy, consider that the router is relaying a request from
following /24: 10.250.127.0.   What should giaddr be?   Must it be
10.250.127.1?   Must it be 10.250.127.254?   Can it have any value in
the range [10.250.127.1,10.250.127.254]?

> BUT, these are CONFIGURATION issues.

Are they?   Where does it say that?

> Even for failover protocol, we assume both servers have the same
> configuration.

The failover protocol states this assertion directly, and discusses
its implications.

> options forwarded client DHCP requests."

What's a scope?   What problem does this solve?   I.e., why is it good
to avoid the need to have identical configuration of the logical IP
subnets on which clients reside in both the relaying routers and the
DHCP server?   Why is this the right way to solve the problem (e.g.,
as opposed to the multicast relay protocol that Eric Hall was working
on)?

> (b) provides rules for how to create the scopes (reserved addresses,

You shouldn't have to assume.   It should be specifically stated.

> we've allowed for that to be communicated.

Argh!   There's that "assume" word again!

> and subnet configurations - at least in the broad sense.

And again!

> As far as how you do lease allocation, etc, that is a server

So there's no need to discuss the possibility of a DOS attack here?
Why not?   Drafts are supposed to have security considerations
sections.   This is one of the kinds of things that are discussed in
such sections.

> configuration information.

The idea is to avoid unexpected results.   It is possible, I think, to
describe what the server should do in this case, or to say "the server
MUST be configurable as to what addresses on a dynamically-created
subnet are reserved for routers."   And you didn't address the
failover case, which I think is rather important.

> routers.

This is true.

> In fact, the whole idea here was to reduce configuration

That's a reason to have a subnet mask suboption and check to make sure
the server's idea of the subnet mask is the same as the relay
agent's.   It's not a reason to have the server allocate subnets on
the fly.

> going to keep them between server reboots).

So this increases the administrative burden, because subnets can now
be created by random errors, and someone has to go look for them to
get rid of them in that case, right?

			       _MelloN_