Subject: RE: [dhcwg] DHC WG charter

From: "Bound, Jim" <[email-masked]>
Date: Fri, 11 Oct 2002 14:36:51 -0400

OK with your update and replaces.

> - Develop extensions to DHCPv6 for prefix delegation, DNS
>    configuration, etc.
> - Determine the requirements for DHC to support the dynamic
>    renumbering of networks using fast path delegation as CPE
>    front end between ISP and Private Networks.
> 
> Please reply with comments...
> 

Both topics above have charateristics that will require the IETF to develop protocol operations or extensions to make them happen.  They also both have market needs so we have a customer.  As they will be using dhc to perform these functions and that the necessary routing, application, dhc, and IP stack expertise exists in the dhc working group and that is a clear effort by the dhc group these should be part of our charter.

If there are any backroom statements about the expertise in this group to solve this problem let them have integrity and state so on this list or do not use it to prevent this charter ammendment.

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

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 14 Oct 2002 10:51:09 -0500

Ralph:

Some comments:

Regarding:
* Develop requirements for any new protocols to address threats or
   other enhancement identified by the threat model and analysis of
   3118

Can we better qualify "new protocols"? This sounds rather open ended and we don't
mean to impose on things outside of DHCP. Would this be "new DHCP authentication
protocols"?

Regarding:

I don't have any issues with including the first - these extensions are very
important. I'm less certain of the second and not exactly sure if this is part
of the Prefix Delegation issue or something else.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Friday, October 11, 2002 1:05 PM
To: [email-masked]
Subject: Re: [dhcwg] DHC WG charter

Here's a revised draft WG charter, with edits based on feedback from 
mailing list discussion.  The primary changes in this revision are:

* Rewrote the authentication charter item to require
   require development of a threat model and analysis
   of RFC3118, with suggestions about specific issues
   to consider in the analysis.  Added separate charter
   item to develop mechanisms to address issues identified
   by threat model and analysis.
* Deleted references to specific options to be published
   as part of DHCPv6; deleted reference to prefix delegation,
   DNS configuration (see below for more details)
* Replaced charter item on acceptance of DHCP as Standard
   with analysis of problems with current spec that impede
   development of interoperable implementations.

We need consensus on whether the following charter items should be included 
in the charter:

- Ralph

=====

		   Dynamic Host Configuration (dhc)

The working group has the following primary objectives:

* Develop a threat model and analysis of the authentication
   protection provided by RFC3118; specific issues to be addressed
   include:
   - Improved key management and scalability
   - 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

* 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
   - Encourage independent implementations and report on
     interoperability testing
   - Revise specification and publish for acceptance as Draft Standard
     by 10/18/2002

* 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.

* Complete the specification and publish work in progress as
   standards:
   - Failover protocol
   - DHCP/DDNS interaction
   - SNMP MIB
   - Host name options
   - Leasequery
   - Other client and relay agent options

* Review new options for DHCP, as deemed appropriate by the working
   group and/or the Internet area directors

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 14 Oct 2002 22:59:54 -0400

that was a good answer and I am glad your doing that.  more clear now.
thanks
/jim

> From: Thomas Narten [mailto:[email-masked]]
> Sent: Monday, October 14, 2002 10:34 PM
> To: Bound, Jim
> Cc: Ralph Droms; [email-masked]
> > And who defines who a subject matter expert is?
> 
> I would hope that this will generally be obvious. The folks who
> understand/develop the technology that the DHC option is to be used
> for. That could the SIP, IPS, LDAP, Kerberos, and SLP folk, etc. In
> general, the DHC WG won't know much about how such options will be
> used, so they can't really evaluate whether the option (other than its
> encoding) makes sense. What I'm trying to avoid is having the charter
> imply (or seem to imply) that the WG will take on any/all options
> someone brings to the WG. I think it is fine for the WG to review any
> option from the perspective of DHC, but it should be clear that
> approval of all DHC options is a two step process. Acceptance from the
> DHC community and the actual users of the option.
> 
> Thomas
>

---

From: Ralph Droms <[email-masked]>
Date: Tue, 15 Oct 2002 08:55:55 -0400

>mean to impose on things outside of DHCP. Would this be "new DHCP 

Yes - "new DHPC authentication protocols" is what was intended.  At the 
risk of verbosity, some hint about "using the existing DHCP authentication 
framework (RFC3118) and other existing security protocols (IPsec, etc.)" 
might be appropriate.

>From: Ralph Droms [<mailto:[email-masked]>mailto:[email-masked]]
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 22 Oct 2002 09:48:55 -0500

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
   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]]
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 and contribute to the discussion 
thread.

- Ralph

At 04:02 PM 10/21/2002 -0400, Thomas Narten wrote:
>Hi Ralph.
> > >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.
>
> > >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]
>
>
> > >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

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 22 Oct 2002 21:12:04 -0400

I am not sure either.  But it is important.  If we state the problem we
are trying to solve, the ways dhc could solve it, and then ?????  Would
that work.  We can always get IPv6 people as subject matter experts too.
There is something more to do above for the charter but not sure what
else.

Thanks
/jim

> Sent: Tuesday, October 22, 2002 3:24 PM
> To: Bound, Jim
> > 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.
> 
> I agree that it is important work.
> 
> In practice it needs to be joint between IPv6 and DHC. I 
> don't have strong opinions on whether it is more appropriate 
> to list it as a DHC item vs. one in the IPv6 WG. I believe 
> *they* believe they should own it. :-)
> 
> Thomas

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 23 Oct 2002 14:37:09 -0500

Ralph:

This looks OK!

One minor nit ... "The working group now has four main objectives:",
actually there are 6 listed. Perhaps best just to change this to:
"The working group now has the following main objectives:"?

And, in the list of DHCPv6 documents, what about your draft
draft-droms-dhcpv6-stateless-guide-00.txt?

Do we need to also do a new Goals & Milestones section?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Wednesday, October 23, 2002 2:26 PM
To: [email-masked]
Subject: Re: [dhcwg] DHC WG charter 

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...

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.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Oct 2002 15:46:33 -0400

Thanks, Bernie...

I agree about the change to "following main objectives"...

I'll add draft-droms-dhcpv6-stateless-guide-00.txt to the list of DHCPv6 docs.

Once we agree on the charter, we can draft a new list of "Goals and 
Milestones"...

- Ralph

At 02:37 PM 10/23/2002 -0500, Bernie Volz (EUD) wrote:

>charter also available at 
><http://www.dhcp.org/charter-update.html);>http://www.dhcp.org/charter-update.html); 
>
><http://www.dhcp.org/rfcs.html>http://www.dhcp.org/rfcs.html).  The 
>working group now has four main
>objectives:
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 24 Oct 2002 09:06:09 -0400

Looks good to me.  If the prefix option in v6 covers us for prefix
delegation that is fine otherwise a no or yeah on that would be good on
the list.  I vote yeah.

/jim

> 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 
> identifies

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 24 Oct 2002 14:03:49 -0500

Why don't we just then change this part to read "Complete work on ..." (remove "or terminate"). I don't believe we want to terminate anything on the list yet.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Thursday, October 24, 2002 2:35 PM
To: Ralph Droms
Cc: [email-masked]
Subject: Re: [dhcwg] DHC WG charter 

> The posted charter has been revised based on Bernie's input...

Looks pretty good overall.

But one thing seems odd:

> Complete or terminate work on DHCP ...

And then lists all the relevant WG drafts.

I think everyone will agree that the majority of the listed IDs stay
as WG items. Maybe a small number should be terminated?

We should have the discussion now about which documents are in and
which are no longer needed/appropriate. After all, the (re)chartering
process is about aligning the charter with the work being done.

There may be cases where there is a specific document that we don't
really know today what to do with it, that's OK, so long as it is
clear in the milestone (or charter) that the first order of business
is to figure out what to do with it (i.e., before additional work is
done on it).

But I don't think the charter should leave it so open ended as to
which IDs may or may not be kept.

Thomas