RE: [dhcwg] DHC WG charter

["Bound, Jim" <[e-mail]>]

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:[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
> 
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg