RE: [dhcwg] DHC WG charter

Richard Barr Hibbs <> Fri, 14 June 2002 22:18 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id SAA17710 for <>; Fri, 14 Jun 2002 18:18:33 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id SAA11374 for; Fri, 14 Jun 2002 18:19:09 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id SAA11268; Fri, 14 Jun 2002 18:17:18 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id SAA11242 for <>; Fri, 14 Jun 2002 18:17:16 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA17617 for <>; Fri, 14 Jun 2002 18:16:39 -0400 (EDT)
Received: from BarrH63p601 ([]) by (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <> for; Fri, 14 Jun 2002 15:17:14 -0700 (PDT)
Date: Fri, 14 Jun 2002 15:16:57 -0700
From: Richard Barr Hibbs <>
Subject: RE: [dhcwg] DHC WG charter
In-reply-to: <>
Message-id: <>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7BIT
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>
Content-Transfer-Encoding: 7BIT

Thomas, Ralph, Jim, Bernie, et al.,

> > The working group has the following primary objectives:
> > * Develop additional authentication protocols within the framework
> >   defined in RFC3118, along with other mechanisms to mitigate the
> >   threat of attacks on DHCP clients and servers:
> >   - New RFC3118 protocols to address improved key management and
> >     improved scalability
> I think the charter should be more specific here. What new protocols
> are needed? What problems need to be solved? The above is just a blank
> check to do unspecified work (not good).
...I think the first question to ask is (1) what problems need to be solved?
While I agree with Ralph that the result of answering (1) will probably be
to identify additional application protocols required within the RFC3118
framework, I believe we need to proceed by conducting a threat analysis,
which I would suggest should be our second question:  (2) what threats to
secure, reliable network configuration are likely or possible to occur?  A
third question might be (3) how does any security or authentication proposal
fit with other work of the IETF?


> >   - Consider solutions for specific threats such as use of nonce
> >     identifier to defend against DoS attacks through FORCERENEW from
> >     off-path attackers
> This might be good, but it seems like a prerequisite is to have a
> documented threat analysis. What are the primary threats to DHCP?
> Which ones are the ones that are important to address? Only then does
> it make sense to think about specfic solutions.
...agreed, a threat analysis probably should be first

> > * Complete the specification of DHCP for IPv6 (DHCPv6):
> >   - Gain acceptance and publication of current Internet Draft as
> >     Proposed Standard
> >   - Develop and publish specifications for options and other
> >     extensions to DHCPv6, including those already published as
> >     Internet Drafts:
> >     + "DNS Configuration Options for DHCPv6"
> >     + "Time Configuration Options for DHCPv6"
> >     + "NIS Configuration Options for DHCPv6"
> >     + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6"
> >     + "Load Balancing for DHCPv6"
> >   - Encourage independent implementations and conduct interoperability
> >     testing
> I don't think this needs to be called out in the charter. WGs don't do
> interoperability testing per se. But interoperability reports are
> needed for advancing documents along the standards track.
...I disagree slightly, Thomas, in that I believe it is important for the
working groups to encourage multiple implementations and interoperability
testing precisely because that is the means to substantiate a call for

> >   - Revise specification and publish for acceptance as Draft Standard
> >     by 6/30/2002
> >   - Develop extensions to DHCPv6 for prefix delegation, DNS
> >     configuration, etc.
> I'm not sure I agree with this. I think the DHC needs to stick with
> its core expertise, which is the DHC core protocols, and reviewing
> options motivated from outside the WG from the perspective of being
> consistent with standard DHC operating practice.
...again, answering question (1) should provide the necessary clarification
to determine what extensions are needed.


> So, I think better charter wording would say that the WG will review
> options whose impetus comes from other WGs. A number of the specific
> options mentioned above are really motivated by other WGs.

> > * Revise and submit the DHCP specification for acceptance as a Full
> >   Standard
> I guess I'm a cynic. If there is no realistic plan for doing this, I'd
> say leave it out of the charter.
...what would constitute a realistic plan in your view?  A full-blown review
of all DHCPv4 options for currency and usefulness?  Sunsetting or
deprecation of unused options, features, and functions?   Time limits for
generating DHCPv6 extensions?  A freeze on new protocol development?  My
cynicism runs the other way:  if it isn't included in the charter, I'm not
convinced that either the -v4 or -v6 protocols would ever make it to Full

> The charter should not be a kitchen sink of all possible work
> items. It should capture the priority items the WG will work on over
> the next 12 months. One can easily recharter if something interesting
> pops up that should get attention.

> > * Complete the specification and publish work in progress as
> >   standards:
> >   - Failover protocol
> >   - DHCP/DDNS interaction
> >   - SNMP MIB
> What is the MIB item? Do we really need it?
...every time (at least 3 times) I asked the attendees at a WG meeting if
this work should continue towards adoption, the voice vote was affirmative.
I still get occasional mail from people who have begun implementation and
have questions or request clarifications -- that was the source of updates
to the last revision of the I-D.  On the other hand, the DNS extensions
working group just dropped the idea of ever defining a standard server or
resolver MIB as unwanted, even though I know of 5 different vendors who
provide a DNS server MIB.  I also am aware of at least 3 private DHCP server
MIBs, so somebody out there wants it!  However, if we can't get this to
working group last call before the December meeting, I intend to withdraw
the draft from the I-D editor.


dhcwg mailing list