Re: [dhcwg] DHC WG charter

Ralph Droms <rdroms@cisco.com> Tue, 22 October 2002 13:21 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 JAA15934 for <dhcwg-archive@odin.ietf.org>; Tue, 22 Oct 2002 09:21:24 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MDNCV13423 for dhcwg-archive@odin.ietf.org; Tue, 22 Oct 2002 09:23:12 -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 g9MDNBv13420 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 22 Oct 2002 09:23:11 -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 JAA15917 for <dhcwg-web-archive@ietf.org>; Tue, 22 Oct 2002 09:20:52 -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 g9MDKfv13238; Tue, 22 Oct 2002 09:20:41 -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 g9MDIkv13098 for <dhcwg@optimus.ietf.org>; Tue, 22 Oct 2002 09:18:46 -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 JAA15715 for <dhcwg@ietf.org>; Tue, 22 Oct 2002 09:16:27 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (rtp-vpn2-145.cisco.com [10.82.240.145]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07138 for <dhcwg@ietf.org>; Tue, 22 Oct 2002 09:18:42 -0400 (EDT)
Message-Id: <4.3.2.7.2.20021022091558.03c28e58@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 22 Oct 2002 09:18:39 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] DHC WG charter
In-Reply-To: <200210212002.g9LK2Ck23663@rotala.raleigh.ibm.com>
References: <Message from Ralph Droms <rdroms@cisco.com> <4.3.2.7.2.20021015085610.00b5baa8@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>

WG members:

We *require* input from WG members regarding the revision of the WG 
charter.  This is *not* a task for just the WG chair and the AD.

Please review the current revised charter at 
http://www.dhcp.org/charter-update.html and contribute to the discussion 
thread.

- Ralph

At 04:02 PM 10/21/2002 -0400, Thomas Narten wrote:
>Hi Ralph.
>
> > > > * 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.
>
>The word "improved" implies to me not analyzing/understanding the
>current systems, but jumping to the next steps of what is
>needed. Seems like the threat model/analysis should be focused on
>understanding the limitations and threats of what we have specified
>today.
>
>Having said that, I don't doubt that improvements are needed. :-) So
>this is a wording issue I think.
>
> > > >    - 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.
>
>Maybe what is needed is a context paragraph before the specific
>tasks. It could say something like:
>
>    RFC 3118 defines current security mechanisms for DHCP.
>    Unfortunately, RFC 3118 has neither been implemented nor deployed
>    to date. There is widespread feeling that its current restriction
>    to manual keying of clients limits its deployability. It is the
>    goal of this WG to rectify this situation by defining extensions
>    that have better deployability properties. In order to achive this
>    goal, the WG will perform the following security-related tasks:
>
>    [and then list specific items]
>
>
> > > > * 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?
>
>I think it would be useful to have more specific text that describes
>how (and when) options will be reviewed by the WG, and when they will
>be taken on by the WG. I.e, something like:
>
>    This WG also is responsible for reviewing (and sometimes
>    developing) DHC options (for both IPv4 and IPv6). The WG is
>    expected to review all proposed DHC options to ensure that they are
>    consistent with the DHC protocol, other option formats, that they
>    do not duplicate existing options, etc.  The WG cannot (generally)
>    be responsible for evaluating the semantic content of proposed
>    options. Only subject matter experts for the technology the option
>    relates to can do so. The DHC WG will not adopt new DHC option
>    proposals as WG documents without first coordinating with other
>    relevant WGs and determining who has the responsibility for
>    reviewing the semantic content of an option.
>
>I don't have a strong feeling about which WG owns a DHC option
>document (when the option is needed by another WG). So long as the two
>WGs coordinate, things should work out. But in anycase, the WG should
>sign off on all DHC options no later than (and hopefully much sooner
>than) IETF LC. But this level of detail can probably be left out of
>the charter and dealt with on a case-by-case basis.
>
> > >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.
>
>The problem is that once the charter is out, there is no context for
>recalling which options were "in the pipeline" when the charter was
>written and which are new. Thus, it would probably be better to just
>list the IDs that the WG thinks it still has responsbility for.
>
>Thomas

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