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
pgpDT88AZiMuq.pgp
Description: PGP signature
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
