Subject: [dhcwg] DHC WG charter

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Jun 2002 08:27:24 -0400 (EDT)

The Internet ADs have suggested it is time (likely
*way* past time) to revisit the DHC WG charter.  Here's a first pass at
what I see as the issues currently in front of the WG.  The objectives are
not presented in any particular order.

Please review and send your comments to the mailing list.  The goal is
to have consensus on a list of objectives for final review at the WG
meeting in Yokohama.

- Ralph

=====

The working group has the following primary objectives:

* Develop additional authentication protocols within the framework
  defined in RFC3118, along with other mechanisms to mitigate the
  threat of attacks on DHCP clients and servers:
  - New RFC3118 protocols to address improved key management and
    improved scalability
  - Provide security for messages passed between relay agents and
    servers
  - Consider solutions for specific threats such as use of nonce
    identifier to defend against DoS attacks through FORCERENEW from
    off-path attackers

* 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:
    + "DNS Configuration Options for DHCPv6"
    + "Time Configuration Options for DHCPv6"
    + "NIS Configuration Options for DHCPv6"
    + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6"
    + "Load Balancing for DHCPv6"
  - Encourage independent implementations and conduct interoperability
    testing
  - Revise specification and publish for acceptance as Draft Standard
    by 6/30/2002
  - Develop extensions to DHCPv6 for prefix delegation, DNS
    configuration, etc.

* Revise and submit the DHCP specification for acceptance as a Full
  Standard

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

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

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

---

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Jun 2002 10:58:47 -0400

Ralph,

Thanks for getting this discussion started.

>   - New RFC3118 protocols to address improved key management and

I think the charter should be more specific here. What new protocols
are needed? What problems need to be solved? The above is just a blank
check to do unspecified work (not good).

>   - Provide security for messages passed between relay agents and

A good deliverable.

>     identifier to defend against DoS attacks through FORCERENEW from

This might be good, but it seems like a prerequisite is to have a
documented threat analysis. What are the primary threats to DHCP?
Which ones are the ones that are important to address? Only then does
it make sense to think about specfic solutions. 

>   - Encourage independent implementations and conduct interoperability

I don't think this needs to be called out in the charter. WGs don't do
interoperability testing per se. But interoperability reports are
needed for advancing documents along the standards track.

>   - Develop extensions to DHCPv6 for prefix delegation, DNS

I'm not sure I agree with this. I think the DHC needs to stick with
its core expertise, which is the DHC core protocols, and reviewing
options motivated from outside the WG from the perspective of being
consistent with standard DHC operating practice.

But in terms of actually defining new options, I think that requires
significant input AND MOTIVATION from the customers of the option. In
the case of Prefix delegation, that seems like a broader problem,
where a DHC solution might well be appropriate. But I don't think this
should be driven by the DHC WG, since the problem is not inherently a
DHC problem.

Does the DHC WG really have the expertise to do the prefix delegation
work? I wouldn't immediately think so. They do have  expertise to
review any options once it is determined what the prefix delegation
solution requires.

So, I think better charter wording would say that the WG will review
options whose impetus comes from other WGs. A number of the specific
options mentioned above are really motivated by other WGs.

> * Revise and submit the DHCP specification for acceptance as a Full

I guess I'm a cynic. If there is no realistic plan for doing this, I'd
say leave it out of the charter.

The charter should not be a kitchen sink of all possible work
items. It should capture the priority items the WG will work on over
the next 12 months. One can easily recharter if something interesting
pops up that should get attention.

> * Complete the specification and publish work in progress as

What is the MIB item? Do we really need it?

>   group and/or the Internet area directors

Thomas

---

From: Richard Barr Hibbs <[email-masked]>
Date: Fri, 14 Jun 2002 15:16:57 -0700

Thomas, Ralph, Jim, Bernie, et al.,

> check to do unspecified work (not good).
...I think the first question to ask is (1) what problems need to be solved?
While I agree with Ralph that the result of answering (1) will probably be
to identify additional application protocols required within the RFC3118
framework, I believe we need to proceed by conducting a threat analysis,
which I would suggest should be our second question:  (2) what threats to
secure, reliable network configuration are likely or possible to occur?  A
third question might be (3) how does any security or authentication proposal
fit with other work of the IETF?

*Snip!*

> it make sense to think about specfic solutions.
...agreed, a threat analysis probably should be first

> needed for advancing documents along the standards track.
...I disagree slightly, Thomas, in that I believe it is important for the
working groups to encourage multiple implementations and interoperability
testing precisely because that is the means to substantiate a call for
advancement.

> consistent with standard DHC operating practice.
...again, answering question (1) should provide the necessary clarification
to determine what extensions are needed.

*Snip!*

> options mentioned above are really motivated by other WGs.
...agreed

> say leave it out of the charter.
...what would constitute a realistic plan in your view?  A full-blown review
of all DHCPv4 options for currency and usefulness?  Sunsetting or
deprecation of unused options, features, and functions?   Time limits for
generating DHCPv6 extensions?  A freeze on new protocol development?  My
cynicism runs the other way:  if it isn't included in the charter, I'm not
convinced that either the -v4 or -v6 protocols would ever make it to Full
Standard.

> pops up that should get attention.
...agreed

> What is the MIB item? Do we really need it?
...every time (at least 3 times) I asked the attendees at a WG meeting if
this work should continue towards adoption, the voice vote was affirmative.
I still get occasional mail from people who have begun implementation and
have questions or request clarifications -- that was the source of updates
to the last revision of the I-D.  On the other hand, the DNS extensions
working group just dropped the idea of ever defining a standard server or
resolver MIB as unwanted, even though I know of 5 different vendors who
provide a DNS server MIB.  I also am aware of at least 3 private DHCP server
MIBs, so somebody out there wants it!  However, if we can't get this to
working group last call before the December meeting, I intend to withdraw
the draft from the I-D editor.

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2002 17:25:28 -0500

> testing precisely because that is the means to substantiate a call for

If it is necessary for the wg to encourage multiple interoperable 
implementations and interoperability testing, then perhaps that's a signal 
that the protocol spec isn't ready to advance.   My experience is that if 
people want the protocol, they will implement it and do interoperability 
testing with no outside encouragement.   "They" is often members of the wg,
  but that doesn't mean it needs to be official wg business.

---

From: Richard Barr Hibbs <[email-masked]>
Date: Fri, 14 Jun 2002 17:27:32 -0700

> implementations and interoperability testing, then perhaps that's
> a signal that the protocol spec isn't ready to advance.   My
> experience is that if people want the protocol, they will implement
> it and do interoperability testing with no outside encouragement.
>
...now my biases are showing....  after my experience with "stealth"
implementations of private MIBs for DHCP and DNS servers, I'm not so sure
that a bit of encouragement isn't needed....  although I agree that if a
protocol spec is thought to be useful, implementations and interoperability
testing will occur.

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2002 22:58:38 -0500

> protocol spec is thought to be useful, implementations and interoperability

If the stealth implementations make their customers happy, where's the 
problem?   Many a fine protocol has emerged out of a stealth implementation.
    People seem to be willing to implement good standards, so if you see a 
lot of stealth implementations, it's probably because nobody proposed a 
standard, or nobody could agree on one.   In a situation like this, 
experimentation is good (as long as the experimenters don't patent their 
solution, anyway...)