RE: [dhcwg] DHC WG charter

"Bound, Jim" <Jim.Bound@hp.com> Tue, 22 October 2002 15:12 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 LAA21264 for <dhcwg-archive@odin.ietf.org>; Tue, 22 Oct 2002 11:12:35 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MFEOM19784 for dhcwg-archive@odin.ietf.org; Tue, 22 Oct 2002 11:14:24 -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 g9MFEOv19781 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 22 Oct 2002 11:14:24 -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 LAA21248 for <dhcwg-web-archive@ietf.org>; Tue, 22 Oct 2002 11:12:04 -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 g9MFC2v19687; Tue, 22 Oct 2002 11:12:02 -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 g9MFB9v19635 for <dhcwg@optimus.ietf.org>; Tue, 22 Oct 2002 11:11:09 -0400
Received: from zmamail04.zma.compaq.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21079 for <dhcwg@ietf.org>; Tue, 22 Oct 2002 11:08:48 -0400 (EDT)
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 17FBF4255; Tue, 22 Oct 2002 11:11:04 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 22 Oct 2002 11:11:03 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [dhcwg] DHC WG charter
Date: Tue, 22 Oct 2002 11:11:00 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE962E@tayexc13.americas.cpqcorp.net>
Thread-Topic: [dhcwg] DHC WG charter
Thread-Index: AcJ50GiYMxsiBcajR3eNZG7No2f68wADKjZQ
From: "Bound, Jim" <Jim.Bound@hp.com>
To: "Ralph Droms" <rdroms@cisco.com>, <dhcwg@ietf.org>
X-OriginalArrivalTime: 22 Oct 2002 15:11:03.0714 (UTC) FILETIME=[3CF3D020:01C279DD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9MFB9v19636
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>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Ralph,

This looks good.  I must have missed it but I don't see prefix
delegation?  Is that within the options?   Or do we move that to IPv6
WG?   This is very important work required.

Thanks
/jim

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com] 
> Sent: Tuesday, October 22, 2002 9:19 AM
> To: dhcwg@ietf.org
> Subject: Re: [dhcwg] DHC WG charter 
> 
> 
> 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
> 
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg