RE: [dhcwg] DHC WG charter

[Ralph Droms <[e-mail]>]

WG members - while I appreciate Bernie's encouragement, we *need* more 
diversity of opinion to form a healthy, effective charter.  *Please* speak up.

Bernie - I hadn't updated the charter, waiting (hoping) for additional WG 
input to minimize editing thrash.  I will upload your text into the web 
site when I get a chance (some time today).

- Ralph

At 09:48 AM 10/22/2002 -0500, Bernie Volz (EUD) wrote:

>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>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]>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>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>https://www1.ietf.org/mailman/listinfo/dhcwg 
>

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg