RE: [dhcwg] DHC WG charter

Richard Barr Hibbs <rbhibbs@pacbell.net> Fri, 14 June 2002 22:18 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17710 for <dhcwg-archive@odin.ietf.org>; Fri, 14 Jun 2002 18:18:33 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA11374 for dhcwg-archive@odin.ietf.org; Fri, 14 Jun 2002 18:19:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11268; Fri, 14 Jun 2002 18:17:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11242 for <dhcwg@optimus.ietf.org>; Fri, 14 Jun 2002 18:17:16 -0400 (EDT)
Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17617 for <dhcwg@ietf.org>; Fri, 14 Jun 2002 18:16:39 -0400 (EDT)
Received: from BarrH63p601 ([64.169.90.244]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GXP0086SV8PDD@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Fri, 14 Jun 2002 15:17:14 -0700 (PDT)
Date: Fri, 14 Jun 2002 15:16:57 -0700
From: Richard Barr Hibbs <rbhibbs@pacbell.net>
Subject: RE: [dhcwg] DHC WG charter
In-reply-to: <200206141458.g5EEwlk15942@rotala.raleigh.ibm.com>
To: dhcwg@ietf.org
Reply-to: rbhibbs@pacbell.net
Message-id: <JCELKJCFMDGAKJCIGGPNOEOIDNAA.rbhibbs@pacbell.net>
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
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
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?


*Snip!*

> >   - 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
advancement.


> >   - 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.


*Snip!*

> 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.
>
...agreed


> > * 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
Standard.


> 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.
>
...agreed


> > * 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.

--Barr


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