Re: [dhcwg] DHC WG charter

[Ralph Droms <[e-mail]>]

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