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

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

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

> 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
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg