Subject: [dhcwg] draft-pruss-dhcp-auth-dsl-03.txt

From: "David W. Hankins" <[email-masked]>
Date: Mon, 4 Aug 2008 16:05:01 -0700

I was not able to attend the DHC WG meeting in Ireland, and look
forward to redacting or extending my statements upon reviewing the
minutes.  I've included some talking points that I think may be
missing from this discussion, and omitted some that I presume were
well covered in the WG meeting.

On the subject of Authentication, Authorization, and Access...

This entire discussion has presumed, incorrectly I think, that DHCP
is an appropriate place to perform authorization or access control.

It has been pointed out several times that DHCP provides configuration
state, it can no more force a client to adopt its configuration than
it can keep a client from manually (or from snooping neighbors DHCP)
adopting a configuration.  I'll say simply what I mean; RFC3118 is
broken in design, and this proposed extension does nothing to address
the core requirements failures that have plagued 3118's adoption.

What we need truly is a way to prove that endpoints in DHCP exchanges
have not changed (what I will call authentication, any system that
verifies a message is authentic), but 3118 and this EAP proposal
provide it only by way of authorization (and in this EAP proposal's
case now explicitly for the purpose of access control).

On the subject of servers making 'queries' of its clients...

It is indeed true that DHCPFORCERENEW exists.  If you will suspend
your disbelief for a moment, imagine that it is also true that this
is very poorly deployed.  For my own part, it will not appear in
ISC dhclient until DHCPv4 servers can be casually authenticated, as
otherwise it presents only a fantastic new way to DOS clients.

But DHCPFORCERENEW is not used on unconfigured clients.  It is not
useful for clients in INIT state, it is unicast to clients that have
IPv4 addresess already - those that are BOUND-or-better along the
DHCPv4 state machine.

Foremost because INIT state clients, having no IPv4 address yet, would
have nothing to perform in a renew.  But more generally, because these
clients may potentially be unable to receive unicast packets (as
signaled by the BOOTP_BROADCAST flag) until after they have obtained
an IPv4 address.  The server or relay must instead transmit link
layer broadcasts, and MUST preserve the client's transaction-ID in
order for clients to differentiate replies intended for them.

So the stipulation that DHCPFORCERENEW is an existence proof for
server-made queries of INIT-state clients is false.  Rather, the
skepticism that these proposed changes are anything other than a
new protocol hiding in old work's clothing is entirely true.

On the subject of multiple servers...

In terms of "standard" definitions of DHCPv4 using multiple servers,
it is true that from existing documentation one can imagine a pair
of servers that are offering different, non-overlapping, address
ranges, providing a kind of fault tolerance (or just replying to
different kinds of clients, even using the standard LBA algorithm).

There has been for some time now a draft for DHCPv4 failover, which
describes two servers working in tandem, but this remains a draft.
This is a small distinction since mostly it just affords a single
pool of address space, an optimization that is useful due to the
distinct shortage of available IPv4 addresses (makes it very difficult
to always have twice as much as you need).

Given either of those two backgrounds, one can easily paint a picture
where at any given time one, both, or neither servers responds to a
given DHCPDISCOVER, and then only one server responds to all
DHCPREQUESTs from there on out (with one corner-case exception for
the failover draft and REBINDING clients).

But it is strange to suggest that within one DHCPv4 state machine,
one server would handle DHCPDISCOVER/DHCPOFFER, while a different
server would handle DHCPREQUEST/DHCPACK while in SELECTING and
a third server would then handle the same in RENEWING, and etc.

It is even stranger to suggest that a relay would sometimes act
like a server, but _even stranger still_ that a relay would
contain any kind of state in its message passing, even something as
trivial as retransmission counters.

Although one need only squint a little to suppose that "cluster"
deployments of DHCPv4 servers exist, we do not describe such low
layers explicitly in protocol documents.  We instead describe
what a DHCPv4 server is in its entirety, and it is up to the
implementer to decide where to draw the lines.

But blurring the abstract lines between DHCP speakers is the kind of
complication these protocols do not need.

On the subject of v4 and v6 Authorization being done twice...

I wish to note only that the authors have made a significant
presumption in that the v4 and v6 DHCP servers would be operated
within the same administrative domain, and that therefore the
same EAP keys could be reused.

Instead, I believe such a client will have to authorize separately,
and start back from scratch every time it cycles through INIT, and
possibly even REBINDING (but you could optimize here to only do so
when the server-id changes, excluding rfc1918 addressed servers).

On the subject of DHC WG bandwidth...

We have seen this document before.  It has changed little except in
the way in which it is presented, despite comments from DHCP's
practicioners.  We have been asked for consensus on making this a
WG item, which it failed to receive.

After all this, I have to wonder; why are we reviewing this document
as though it were a WG item anyway?

I don't pretend to speak for the entire WG, but I don't think we have
time for this.  I would prefer if the WG's donated manhours would be
spent on the real issues before us (especially if anyone can go back
to the drawing board on RFC3118) than to continue to watch these
wheels spin so tragically.

On the subject of Maintenance...

Perhaps I have an unusual point of view here, because I work on open
source software.  In my normal daily work, I have to evaluate patches
that are sent to us for incorporation in our software.  This is an
asymmetric cost/benefit situation; the contributor gets their work
published for little to no cost.  Our software package gets any
resulting bugs, which its users ultimately come to us to repair - not
the original author.  It's not their fault, a user just can't keep
track of the full matrix of contributors (and sometimes neither can
we; was it the original author's bug or a later patch supplied by a
third party?).

So one of the questions I must ask myself, and ask contributors to
work with me on, is improving the proposed contribution (sufficient
comments, lack of obtuse or unduly obfuscated code) to the point where
it can reasonably be maintained by ourselves.

Similarly, this proposal is essentially a contributory change to the
DHCP protocol which, if adopted, has an immense capacity for causing
bugs and problems not only within itself, but in various corner cases
of other parts of DHCP's normal operation which it seeks to alter.

Simply put, it is my opinion that the IETF as it currently is
organized today can not reasonably accept this contribution and expect
to be able to maintain the standard DHCP protocol on its own.  It has
a severe capacity to "domino effect" problems into other DHCP protocol
features.

For all of these reasons, and those I have omitted believing them
to be discussed in Ireland, I continue to assert my opinion that this
document should not be adopted as a DHC WG item.

Again, as we seem to be discussing it as though it were a WG item
anyway, and the author has gone ahead and implemented his desires
despite the caution that DHCP's practicioners have advised, it seems
to me that it is very likely these changes will be seen in
production DHCP networks despite any lack of standardization (in the
same way that so much work, like WPAD, is turned away from the IETF
but finds life on the network anyway).

One does not usually write code to throw it away.

So although I continue to recommend not moving forward at all with
these proposed changes, and in fact scrapping the written code, if
this is going to be released onto the network anyway it is still
preferrable to have a document - of any quality or level of detail -
describing it.

I suggest then that the authors link this work to Bernie's "vendor
messages" drafts as an informational document describing their
use of those proposed extensions, reducing the DHC WG's responsibility
from full protocol-rewrite-review, as has been requested, to
clarifications of meaning and intent.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Richard Pruss <[email-masked]>
Date: Tue, 5 Aug 2008 18:48:46 +1000

David,

Lots of issues raised by your mail, lets start with the top one.

The discussion of DHCP is appropriate for access control really comes  
down to a questions of if DHCP configures the network or just the  
host.  In current practice we do use DHCP to configure both as we want  
the network to enforce the configuration done to the client.

Authentication is for authorisation, which means that it simply boils  
down to network configuration in sync with the needs of the host.

If you accept that DHCP does network configuration as well as client  
configuration, then the next question to ask yourself is what  
information we need to make the best possible network and host  
configuration.  Currently for many networks, the subscribers line as  
marked in option 82 is enough but in a small subset of networks the  
access lines cannot be trusted.  Normally the access information  
cannot be trusted because of physical problems like in apartments  
where people can change what port they are plugged into.

The EAP over DHCP is simply an extension to the current configuration  
practice to carry information about the subscriber for those cases  
where the access line information carried in option 82 cannot be  
trusted, so some securely communicated attributes are required.

- Ric

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 5 Aug 2008 15:01:26 -0700

> the network to enforce the configuration done to the client.

I once met a man who wrote some software that implemented an IPv4
tunnel over, of all things, DNS.

I don't really think that observation is worth redefining our idea of
DNS' place in the network to include "layer 2 framing" and then embark
upon severe protocol alterations to improve upon it.

Maybe you wouldn't agree.

But for the same reason, I'm not really obliged to see a use of the
DHCP host configuration channel to configure relay agents - a function
that it was not designed to perform, and also that it happens to
perform fairly poorly - as being justification to redefine our idea of
DHCP's role in IP networks.  Just so we can then embark upon core
rewrites of client functionality to support it.

Sidehacks are great, I think it's wonderful that you've been able to
use a tool that was not designed for the purpose you've bent it to,
one that many others have used as well.

But sidehacks don't make the best standards.

---

From: Richard Pruss <[email-masked]>
Date: Wed, 6 Aug 2008 13:30:05 +1000

On 06/08/2008, at 8:01 AM, David W. Hankins wrote:

> I'm not really obliged to see a use of the

Possibly this is the core of the disagreement.  I see it as critical  
to the secure behaviour of an SP or Enterprise edge that the network  
verify/enforce that the client is using the configuration the network  
gave it.  I see it as DHCP's role to configure the host and the  
network at the boundary between layer 2 and layer 3.

Regards,
Ric

---

From: Richard Pruss <[email-masked]>
Date: Wed, 6 Aug 2008 13:36:39 +1000

> clarifications of meaning and intent.

I think this is a reasonable suggestion and very much inline with  
where we were going in the draft.  The one thing that keeps on  
dropping from the conversation is that this draft is only applicable  
in a very specialised set of deployments in the broadband edge.

Possibly a vendor message for the DSLForum would be a very neat way to  
handle this request, with appropriate review from the working group.

- Ric

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 13 Aug 2008 13:34:40 -0700

On Wed, Aug 06, 2008 at 01:30:05PM +1000, Richard Pruss wrote:
> Possibly this is the core of the disagreement.  I see it as critical to the 
> secure behaviour of an SP or Enterprise edge that the network 
> verify/enforce that the client is using the configuration the network gave 
> it.

I believe that is entirely true, and have been known to practice this
in my own networks with a zeal beyond that normally considered
practical or reasonable.

> I see it as DHCP's role to configure the host and the network at the 
> boundary between layer 2 and layer 3.

DHCP's role is to configure the host, yes, the network, no.

Unless the network elements were themselves DHCP clients.

The trouble with the relay's role in a DHCP host's exchange is that
it is not given a state.  This is wonderful, because it makes relays
very simple pieces of software, having no state to manage.  For folks
that are trying, as I said, to make DHCP do what it wasn't designed
for, it is an incomplete fit, and problems constantly arise with
out-of-order packet delivery, out-of-band packet delivery (where
there is a second relay), and inconsistent replies made to clients
(of which only one is accepted by the client) which are particularly
problematic when more than one server is involved.  To name just a
few.

Given time to sort it out, and neglecting pathological cases, a DHCP
server and DHCP client will converge on a single image of the desired
configuration.  A DHCP relay is left out of this convergence, so
you cannot reliably convey configuration.

I believe it simply was never a design criteria, and am more or less
at peace with that as the ultimate designs of both DHCP protocols
help them fit where I believe DHCP belongs.

Which doesn't include access control.

---

From: Richard Pruss <[email-masked]>
Date: Thu, 14 Aug 2008 08:30:50 +1000

Is this a repost?

- Ric

On 05/08/2008, at 9:05 AM, David W. Hankins wrote:

> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 13 Aug 2008 15:40:19 -0700

> Is this a repost?

I only sent it once, according to my records, but it was crossposted
to int-area.

My guess would be, as I am not subscribed to int-area, that it
just got approved by a moderator.