Re: [dhcwg] DHC WG charter

[Thomas Narten <[e-mail]>]

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