Subject: RE: [dhcwg] DHC WG charter

From: Ralph Droms <[email-masked]>
Date: Tue, 22 Oct 2002 11:08:26 -0400

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:[email-masked]>mailto:[email-masked]]
>Sent: Tuesday, October 22, 2002 9:19 AM
>To: [email-masked]
>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
>[email-masked]
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2002 19:42:54 -0700

I think the tasks before us are:

- Advance DHCPv6
- Define a deployable DHCP security protocol.
- Get the DNS drafts finished
- Advance the other drafts that are currently under consideration, or 
drop them.

I.e., I don't have any real argument with your suggestions.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Oct 2002 14:25:35 -0400

Here's a revised charter, based on input from mailing list discussion (this 
charter also available at http://www.dhcp.org/charter-update.html); 
comments or acknowledgments (this looks OK) strongly encouraged...

		   Dynamic Host Configuration (dhc)

The dhc working group (DHCWG) has developed DHCP for automated
allocation, configuration and management of IP addresses and TCP/IP
protocol stack parameters. DHCP is currently a "Draft Standard".  The
base protocol is document in RFC2131 and RFC2132.  Additional options
are documented in a series of RFCs (see
http://www.dhcp.org/rfcs.html).  The working group now has four main
objectives:

* RFC 3118 defines current security mechanisms for DHCPv4.
   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
   DHCWG to rectify this situation by defining extensions that have
   better deployability properties. In order to achive this goal, DHCWG
   will develop a threat model and analysis of the authentication
   protection provided by RFC3118; specific issues to be addressed
   might include:
   - Improved key management and scalability
   - Security for messages passed between relay agents and servers
   - Threats of DoS attacks through FORCERENEW

* Complete the specification of DHCP for IPv6 (DHCPv6):
   - Gain acceptance and publication of current Internet Draft as
     Proposed Standard
   - Complete or terminate work on published DHCPv6 options:
       IPv6 Prefix Options for DHCPv6
         <draft-troan-dhcpv6-opt-prefix-delegation-01.txt>
       DSTM Options for DHCP
         <draft-ietf-dhc-dhcpv6-opt-dstm-01.txt>
       DSTM Ports Option for DHCPv6
         <draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt>
       DNS Configuration options for DHCPv6
         <draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt>
       Load Balancing for DHCPv6
         <draft-ietf-dhc-dhcpv6-loadb-02.txt>
       NIS Configuration Options for DHCPv6
         <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>
       Time Configuration Options for DHCPv6
         <draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt>
       Client Preferred Prefix option for DHCPv6
         <draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt>
   - Encourage independent implementations and report on
     interoperability testing

* Complete or terminate work on DHCP extensions and new options that
   are currently work in progress:
   - Failover protocol
   - DHCP/DDNS interaction
     <draft-ietf-dhc-fqdn-option-04.txt>
     <draft-ietf-dhc-ddns-resolution-04.txt>
   - DHCP Server MIB
     <draft-ietf-dhc-server-mib-07.txtDHCP MIB>
   - Host name options (Smith/Lemon?)
   - DHCP Leasequery
   - DHCP Option for CableLabs Client Configuration
     <draft-ietf-dhc-packetcable-03.txt>
   - KDC Server Address Sub-option
     <draft-ietf-dhc-suboptions-kdc-serveraddress-00.txt>
   - DHCP Options for Internet Storage name Service
     <draft-ietf-dhc-isnsoption-03.txt>
   - The Authentication Suboption for the DHCP Relay Agent Option
     <draft-ietf-dhc-auth-suboption-00.txt>
   - Link Selection sub-option for the Relay Agent Information Option
     <draft-ietf-dhc-agent-subnet-selection-03.txt>
   - DHCP VPN Information Option
   - VPN Identifier sub-option for the Relay Agent Information Option
   - RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option

* DHCWG is responsible for reviewing (and sometimes developing) DHCP
   options or other extensions (for both IPv4 and IPv6). DHCWG is
   expected to review all proposed extensions to DHCP to ensure that
   they are consistent with the DHCP specification and other option
   formats, that they do not duplicate existing mechanisms, etc.  DHCWG
   will not (generally) be responsible for evaluating the semantic
   content of proposed options. DHCWG will not adopt new proposals for
   extensions to DHCP as working group documents without first
   coordinating with other relevant working groups and determining who
   has the responsibility for reviewing the semantic content of an
   option.

* Write an analysis of the DHCP specification, including RFC2131,
   RFC2132 and other RFCs defining additional options, which identifies
   ambiguities, contradictory specifications and other obstacles to
   development of interoperable implementations.  Recommend a process
   for resolving identified problems and incorporating the resolutions
   into the DHCP specification.