DHCP Server Identifier Override Suboption
RFC 5107

The claim is made that this brings DHCPv4 in line with DHCPv6:
   In short, this new suboption allows the DHCPv4 relay to function in
   the same fashion as the DHCPv6 relay currently does.
Reference?

I sent email to the IESG list about my abstention, forwarding a pretty
devastating comment on this draft, which had no followup that I could find:

I think the WG didn't do much about this document.
Issues about its problematic impact were raised by the
by the WG folks as well.

Nov.  It didn't go onto the Vancouver agenda.  AD's what was
up with the discussion of this document?

I can't find any WGLC discussion, but my personal archive may
not be complete.

IMO, IESG be generally supportive of duly chartered work and WG consenses.

But DHC auto-charters.  There is never review for the architectural
foundations of the new documents and extensions that they take up.
And if the WG consensus of a document is not great when
it comes to the IESG...we get here.

I don't want to leave a Discuss behind me.  What I'd propose  
for action items would be:

 - New review of the concerns by discussants in the working
   group; were they addressed? do they* think the document needs
   a revision before returning to the IESG?  In other words,
   a return to WGLC 
 - A re-charter of DHC should look at the way extensions grow, 
   particularly how new work is adopted.

Allison

------- Forwarded Message

Date:    Wed, 09 Nov 2005 00:22:31 +0000
From:    "David W. Hankins" <David_Hankins@isc.org>
To:      dhcwg@ietf.org
Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-03.txt

Since this isn't on the agenda this week, I wanted to comment on this
again before I forget.

[you can find the rest in the archive]

Section 6 seems not inline with the IPR words we require these days.
It is in fact redundant give the IPR text on page 10.

References are not split in normative and informative.

Sect 5. Last word "none" probably should be removed?

I am carrying forward Ted's abstain vote.  I have reviewed the document
in depth, including the changes between -03 and -04 and do not believe
a serious effort was made to address Ted's legitimate concerns.  Indeed
between -03 and -04 it appears only 4 paragraphs were added all largely
unrelated to Ted's concerns.

To elaborate on Ted's concerns in my own words, this is a profound
model change to the security of DHCP.  The relay agent gains the
ability to intercept all DHCP traffic even if network topology might
not otherwise permit that.  The server MUST include the relay agent's
server identifier instead of its own regardless of the security
consequences of doing so.  And the client loses the ability to
identify the server that is actually processing the request.

Such a profound change should be motivated and the consequences
discussed in more detail.  The document would also be improved by
discussing the additional logging/diagnostic requirements this
introduces above those of a previous DHCP relay agent deployment.

This document was reviewed by Allison and I am simply  taking over her position with little to no review. Mostly I have tried not to force documents though multiple reviews since each review only seem to uncover more problems. If you think I would come to a significantly different position than Allison and it turns out that my position is relevant to the disposition of this document, feel free to request that I review this.

I will abstain from this document for the following reason:

This option makes this relay-server interaction again more complicated,
while the motivation why we need this option is poorly documented (see Brian's comments).

I wonder whether it is in the interest of the DHCP users and operators that this protocol becomes more and more complicated while the perceived benefits are
unclear as they are insufficiently documented and motivated.

Is this feature in the interest of vendors to make it harder for competitors to
design fully standards compliant DHCP servers and relays ? Is there a real
need among operators to make their DHCP deployments even more complicated and
thus more prone to misconfiguration or security issues ?

I've chosen to abstain on this.  There are two basic reasons.  I believe this makes a fundamental change to the DHCPv4 security model with respect to relay agents, and I think the draft neither motivates this sufficiently nor handles the new role behavior particularly well.  I also believe the case where the relay agent sends this and it is not understood by the server is handled poorly, as it amounts to "make sure it doesn't happen."