Re: [dhcwg] DHC WG charter

Ralph Droms <rdroms@cisco.com> Tue, 15 October 2002 13:13 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00408 for <dhcwg-archive@odin.ietf.org>; Tue, 15 Oct 2002 09:13:13 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FDEtl14248 for dhcwg-archive@odin.ietf.org; Tue, 15 Oct 2002 09:14:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDEtv14245 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 15 Oct 2002 09:14:55 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00390 for <dhcwg-web-archive@ietf.org>; Tue, 15 Oct 2002 09:12:42 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDCIv14129; Tue, 15 Oct 2002 09:12:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FD6sv13401 for <dhcwg@optimus.ietf.org>; Tue, 15 Oct 2002 09:06:54 -0400
Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29891 for <dhcwg@ietf.org>; Tue, 15 Oct 2002 09:04:41 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (rtp-vpn2-814.cisco.com [10.82.243.46]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00657; Tue, 15 Oct 2002 09:06:50 -0400 (EDT)
Message-Id: <4.3.2.7.2.20021015085610.00b5baa8@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 15 Oct 2002 09:06:44 -0400
To: Thomas Narten <narten@us.ibm.com>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] DHC WG charter
Cc: dhcwg@ietf.org
In-Reply-To: <200210141816.g9EIGhP04091@cichlid.adsl.duke.edu>
References: <Message from Ralph Droms <rdroms@cisco.com> <4.3.2.7.2.20021011125559.03a78560@funnel.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

At 02:16 PM 10/14/2002 -0400, Thomas Narten wrote:
>some comments on the charter:
>
>Nits:
>
>Would be good to have a short intro sentence at the start something
>like:
>
>The base DHC protocol is documented in RFCs 2131 and 2132 as well as a
>number of related extensions and options (e.g., RFC 3118). The working
>group has the following primary objectives ...

OK.


> > * Develop a threat model and analysis of the authentication
> >    protection provided by RFC3118; specific issues to be addressed
> >    include:
> >    - Improved key management and scalability
>
>Sounds here like your already jumping ahead to the requirements for
>new protocols. I.e., shouldn't this phase be focused on undertstanding
>limiations of the current mechanisms? Is this just a wording issue?

Perhaps it is a wording issue?  s/include/might include/ ??  The intended 
purpose for the bullet list is to capture current "common knowledge" about 
the threat model and RFC3118.


> >    - Security for messages passed between relay agents and servers
> >    - Threats of DoS attacks through FORCERENEW
>
> > * Develop requirements for any new protocols to address threats or
> >    other enhancement identified by the threat model and analysis of
> >    3118
>
>What's missing above is a clear statement that this WG will develop
>new authentication mechanisms that address the deployability problems
>with the current schemes (whether through an extension to 3118 or
>something else). Or that it will address the relay-agent to DHC server
>path.

Can you explain this comment in a different way, as it seems to be at 
cross-purposes with your previous comment about "jumping ahead to the 
requirements".  I think we're in having a violent agreement that we want to 
(a) get some DHCP authentication out to the client deployed and common 
wisdom is that the best path is through new mechanisms in the RFC3118 
framework; and (b) secure communication between the DHCP relay agents and 
servers.


> > * 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
>
>General comment on options (both IPv4 and IPv6). I'd like the charter
>to clearly indicate that the DHC WG will be reviewing options to make
>sure they are  consistent with the protocol, other option usages, etc.

The charter has a separate bullet item for review of options.  Are you 
suggesting that the bullet item be extended to include "consistent with the 
protocol, other option usages, etc." as specific types of review?


>In terms of reviewing  options for their semantic contents, that
>will be done by subject matter experts, which may well not be in this
>WG. This WG is not to take on options as WG documents until such an
>outside expert has been identified and, e.g., the relevant  WG has
>agreed on the need for such an option. What I'd like to avoid is
>having the DHC WG spend time on options for which there isn't a clear
>customer.
>
> >    - Encourage independent implementations and report on
> >      interoperability testing
> >    - Revise specification and publish for acceptance as Draft Standard
> >      by 10/18/2002
>
> > * Write an analysis of the DHCP specification, including RFC2131,
> >    RFC2132 and other RFCs defining additional options, which identifies
> >    ambiguities, contradictory specifications and other obstacles to
> >    development of interoperable implementations.  Recommend a process
> >    for resolving identified problems and incorporating the resolutions
> >    into the DHCP specification.
>
>The way its written above, sounds like one big fat hard-to-write
>document. :-) Can't we do something simpler,  such as just have folks
>write IDs that take on specific  issues and advance  them as
>standalone RFCs (as appropriate), incorporating them into the base
>spec when the base spec is republished? I'm worried that the above
>reads like a lot of work that no one will be foolish enough to sign up for.
>
> > * Complete the specification and publish work in progress as
> >    standards:
> >    - Failover protocol
> >    - DHCP/DDNS interaction
> >    - SNMP MIB
> >    - Host name options
> >    - Leasequery
> >    - Other client and relay agent options
>
>Are there IDs for all of the above? If so, citing them would be good.

OK.


>Also, I don't like the "other client and relay agent options" as it is
>too open ended. I think the WG needs a way of vetting potential
>options before the WG takes them on officially.

There are other options currently in the pipeline; this "other ... options" 
bullet is intended to refer to those options that are "work in 
progress".  New work is intended to fall under the following bullet item.


> > * Review new options for DHCP, as deemed appropriate by the working
> >    group and/or the Internet area directors
>
>See above.
>
>Thomas

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