RE: [dhcwg] DHC WG charter

["Bernie Volz (EUD)" <[e-mail]>]

Ralph:

You guys appear to be doing rather well on your own!

The current revised charter at the web site doesn't include any
recent changes. Using the discussion between Thomas and you, the
charter now looks more like the following?

o  Complete the specification of DHCP for IPv6 (DHCPv6): 
   - Gain acceptance and publication of the specification as a 
     Proposed Standard by [12/31/2002?]
   - Encourage independent implementations and report on
     interoperability testing
   - Revise the specification and publish for acceptance as Draft
     Standard by [9/30/2003?]
o  RFC 3118 defines current security mechanisms for DHCP[v4?].
   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:
   - Develop a threat model and analysis of the authentication
     protection provided by RFC 3118
   - Improve key management and scalability
   - Develop a means to secure messages passed between relay agents
     and servers
   - Develop a means to reduce the threats of DoS attacks through
     FORCERENEW messages
o  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.
o  Complete the specification and publish the following work in progress
   as standards:
   (We need to include a list of the specific drafts, such as
   - Failover protocol (draft-ietf-dhc-failover-*.txt)
   - DHCP/DDNS interaction (draft-ietf-dhc-ddns-resolution-*.txt)
   - Client FQDN option (draft-ietf-dhc-fqdn-option-*.txt)
   ...
   Do we want to include all of those at http://www.dhcp.org/dhcp-ids.html
   or just a subset? Should we perhaps not even add this item into
   the list of tasks as the previous item (reviewing DHC options)
   covers much of this work. We could instead include some of the
   documents in the Milestones section with planned completion
   dates. We may need to address non-option related documents
   separately - such as Failover, SNMP MIB.)
o  Write an analysis of the DHCP specification, including RFC213,
   RFC2132 and other RFCs defining additional options, which
   identifies ambiguities, contradictory specifications and other
   obstacles to development of interoperable implementations.
   Develop a process for resolving identified problems and
   incorporating the resolutions into the DHCP specification,
   perhaps by publishing an updated DHCP specification or a
   clarifying document.

- Bernie


-----Original Message-----
From: Ralph Droms [mailto:[e-mail]]
Sent: Tuesday, October 22, 2002 9:19 AM
To: [e-mail]
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg