Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/dhc/dhc-minutes-97aug.txt

Text File | 1997-10-10 | 16KB | 336 lines

               DHC WG Minutes - DHCPv4

The DHCPv4 meeting was attended by approximately 45 persons.  Thanks
to Glenn Waters for taking notes.  These minutes were prepared by the
WG chair, Ralph Droms.

The chair opened the meeting with discussion of some administrative
matters.  Because of increased emphasis on security issues within the
IETF standards process, future standards from the DHC WG must include
a "Security Considerations" section.  The document should reference
the "Security Considerations" section in the latest DHCP specification
RFC (currently RFC2131), as well as describing any additional security
exposures and/or solutions specific to the particular document.

The WG expressed consensus for issuing a WG last call for the
following Internet Drafts, prior to submitting these drafts to the
IESG for acceptance as Proposed Standards:

   An Extension to the DHCP Option Codes
      (draft-ietf-dhc-options-opt127-03.txt)
   An option for FQDNs in DHCP options
      (draft-ietf-dhc-fqdn-opt-03.txt)
   DHCP Options for Novell Directory Services
      (draft-provan-dhcp-options-dir-serv-01.txt)
   Netware/IP Domain Name and Information
      (draft-ietf-dhc-netware-options-00.txt)

Mike Carney raised the issue of adding a new option to track the
version of the DHCP, so that clients and servers can indicate which
features they support (and don't support).  An alternative mechanism
using a bit-mask to indicate supported features was suggested.  There
was a comment about the need for versioning relay agents, too.  Mike
volunteered to summarize the issue and kick off a discussion on the
dhcp-v4 mailing list.

Baiju Patel gave a presentation about multicast address allocation, as
described in draft-ietf-dhc-mdhcp-01.txt and
draft-ietf-dhc-multopt-01.txt.  This proposal describes extensions to
DHCP that will support distribution of multicast addresses from
servers to clients.  The proposal is based on the reuse of DHCP for
address requests and distribution, while some other mechanism employed
by the MDHCP servers coordinates the selection and announcement of
newly allocated multicast addresses.  There is some buy-in from other
IETF WGs to use MDHCP for handling multicast addresses.  Some issues
were raised in the ensuing discussion:

* "About 75%" of DHCP is not needed for MDHCP; is there enough
  commonality to warrant reuse?
* The DHCP model of "one address per interface" will no longer work.
* Leases on multicast addresses must be transferable, as the host to
  which the lease was originally issued may leave the multicast group
  before the end of the lease on the multicast address.
* What options should be used in the DISCOVER phase?  How will the
  client describe its request to the server?
* What port number should be used - e.g., how will using the
  BOOTP/DHCP port number affect interoperability?
* Authentication?

Baiju will summarize the issues and continue the discussion on the
dhcp-v4 mailing list.

Mark Stapp gave a presentation about the inter-server protocol, as
described in draft-ietf-dhc-interserver-02.txt.  Requirements for the
inter-server protocol include:

* Must work with existing clients
* Must ensure cooperating servers don't offer same address to two
  different clients

The design goals for the inter-server protocol include:

* DHCP servers are administered as "groups"
* DHCP server groups can auto-configure themselves through the
  inter-server protocol
* Once a client has been given an address, it can perform subsequent
  DHCP functions 9e.g., lease extension) through any server in the
  group
* "Lazy update" is supported, so that updates to all servers in the
  group need not be completed before a server responds to a client
* Servers can continue to function in the event of partial network
  failure (e.g., network partition)

Mark posed some questions to the WG:

* Does the WG want a protocol that meets these goals?
* Does the protocol, as described in
  draft-ietf-dhc-interserver-02.txt, work?
* Is layering on SCSP appropriate?questions about SCSP running on UDP and
* Are there alternatives; e.g., SNMP?

Following up on the question about layering on SCSP, there were
concerns raised about SCSP running on UDP and about the lack of any
existing SCSP implementations.  The chair suggested that the questions
raised in the discussion need to be broken out for further discussion
on the dhcp-serve mailing list.

The WG next undertook a discussion about authentication and security in DHCP.
Olafur Gudmundsson began with a review of the issues.  As a bit of history,
Olafur recalled the original proposal by Schiller, Huitema and Droms
(draft-ietf-dhc-authentication-04.txt) and the analysis that this proposal
was unacceptable because the mechanism would not scale well.  He went on to
review briefly WG discussion about subsequent proposals.  Several
additional requirements - over and above those currently listed in
draft-ietf-dhc-security-arch-01.txt - were endorsed by the WG:

* authentication/authorization should be a REQUIRED component of DHCP;
  should include:
  - client authentication
  - data integrity
  - server/relay agent authentication
* mechanism must scale to multiple servers and administrative domains
* mechanism must incur low administrative costs

Continuing the discussion of authentication for DHCP, Baiju Patel
described his proposal for secure DHCP using temporary addresses.
The key idea is to use an unsecured temporary network address to
bootstrap a security association and an authenticated DHCP message
exchange, in a three-step process:

* bring up minimal networking without authentication - a "temporary"
  address
* establish a security association
* extend the lease on the temporary address or request a new address

One issue raised by the WG is that this mechanism does not prevent a
denial of service attack through the exhaustion of temporary
addresses.

Olafur Gudmundsson next gave a presentation about his latest security
architecture.  In this architecture, both client and server provide
enough information initially for full authentication.  It requires a
public key distribution mechanism; currently, the proposal specifies
DNSSEC.

In response to a question from Olafur, the WG expressed consensus that
the DHCP security mechanism need not be applicable to DHCP for IPv6.
Olafur and Baiju agreed to collaborate on a mutual review of their two
proposals; the review will be forwarded to the WG to guide further
evaluation of the security proposals.

Ralph Droms gave a short description of changes included in Michael
Patrick's revised "Agent Options" Internet Draft
(draft-ietf-dhc-agent-options-02.txt):

* security requirements section added
* several options consolidated into one option

In the ensuing discussion, three issues were raised:

* are these options really required?
* is there overlap with related work?
* are these options too specific to Motorola?

The WG expressed consensus that the "Agent Options" Internet Draft
needs further discussion and revision before consideration as a
Proposed Standard.

Next, Yakov Rekhter gave a presentation about the latest revision to
the DNS/DHCP interaction Internet Draft
(draft-ietf-dhc-dhcp-dns-04.txt).  This latest revision includes a
change in the way PTR RRs are handled: the previous draft specified
that the PTR RR would first be deleted and then added to the RRset;
the new revision specifies that the PTR RR is simply added to the
RRset.

The WG discussed the problem of multiple clients using the same FQDN -
how can clients and servers use DNS correctly to detect and avoid
using an FQDN already in use by another client; while allowing clients
to change FQDNs (and PTR RRs) when appropriate.  Mark Stapp proposed
two solutions, based on using either the TXT RR or a new (TBD) RR.
Mark will write up and publish the two solutions for review by the WG,
and discussion will continue on the dhcp-dns mailing list.

Mark Townsley concluded the meeting with a presentation about the
subnet selection option (draft-ietf-dhc-subsel-00.txt).  The idea is
for the client to give the server additional information about which
subnet the client would like an address from.  The WG asked about
sites in which the server should retain control of address allocation;
Mark responded that, in such cases, the server would ignore the option
and allocate an address according to server policy.  There was also a
question about the need for this option given that 'giaddr' and server
configuration (with topology information about multiple IP subnets on
a wire) can perform a similar function.  The WG agreed to continue
discussion of the issues on the WG mailing list.


               DHC WG Minutes - DHCPv6

The DHCPv6 meeting was attended by approximately 50 people.  Thanks to
Dan Harrington for taking notes.  These minutes were prepared by the
WG chair, Ralph Droms.

The chair opened the meeting with a review of the "last call" process
for the DHCPv6 Internet Drafts.  Because of the limited response to
the WG last call, in which the chair explicitly asked for positive
responses from anyone who had read the documents, the chair, with the
consent of Jim Bound and Charlie Perkins (authors of the DHCPv6
Internet Drafts) requested external reviews of the documents.  Matt
Crawford and Erik Nordmark graciously agreed to review and report on
the documents; many thanks to Matt and Erik for the time and energy
they invested in their careful reviews and thorough reports.  Both
reports raised issues that need to be resolved prior to submitting the
DHCPv6 specifications for Proposed Standard status.

Prior to the WG meeting in Munich, the external review reports had
been posted to the [e-mail] mailing list and the authors
had responded to the points raised in the reviews.  The latest
revisions of the DHCPv6 specifications (draft-ietf-dhc-dhcpv6-10.txt
and draft-ietf-dhc-v6exts-07.txt; about 75% of those present at the
meeting reported having read these or the immediately previous drafts)
include changes by the authors in response to most of the issues
raised in the external review reports. Jim Bound started off the WG
discussion of the current drafts with a short list of issues that can
be resolved quickly:

* consistency of wording/terms/phrases
* bindings require relay agent prefix, not host link-local address
* "silently discard" should be replaced by "system error" (as per RFC
  2119)

There was some discussion about the relay agent prefix issue, as there
may be multiple relay agents on a link; those agents might use
addresses with different prefixes, which the servers would have to
sort out to establish equivalences among binding identifiers.

Jim listed issues that require WG discussion for technical
resolution:

* Multicast REQUEST/SOLICIT messages (scalability)
* Reconfigure processing
* Transaction ID on reboot and sequence number wrap-around protection
* ICMP messages through relay agents, especially for PMTU discovery
* DDNS updates
* DDNS error code processing
* API for IPv6 - excess baggage in packets

Jim led off with a discussion of dynDNS-DHCP interaction issues.  WG
had feedback with editorial changes - some SHOULDs need to be MUSTs.
Jim and Charlie will make modifications in their next draft.

Next, Jim discussed RFC 2136 error codes and DHCPv6.  At present, the
dynDNS error codes are mapped into DHCPv6 extension error codes.  This
mapping may, in some circumstances, mask some information from the
client and adds complexity to the server and to the protocol spec
(which must track any changes to the dynDNS error codes) itself.  On
the other hand, some dynDNS error messages may not make sense to the
client.  Jim and Charlie will review the current mechanism before
issuing the next revision of the Internet Drafts.

The next issue arises from a client that reboots and loses its last
transaction ID.  The server will have a cache of recent transactions
from that client; that transaction cache must be able to differentiate
between a restarted client and transaction ID wrap-around.  WG
consensus was to reserve small integer transaction IDs (e.g., 0-31)
for rebooting clients and skip those transaction IDs in the event of
wraparound.

Jim raised the issue of "excess baggage" in the DHCPv6 messages - some
information, e.g., IPv6 source address, is duplicated in the IPv6
header and the DHCPv6 messages.  Jim suggested that the IPv6 API makes
access to the IPv6 header information simple, and the redundant fields
should be elided from DHCP messages.  Jim and Charlie will revise the
packet formats to eliminate redundant information and add words to the
drafts describing exactly where to find all the necessary information
(either IPv6 header or DHCPv6 message) for DHCPv6 processing.  The
results will be included in the next revision for WG consideration.

The multicast issue was raised by Erik Nordmark in his review of the
DHCPv6 specifications.  In an environment with multiple relay agents
on a link and multiple DHCP servers in an organization, use of
multicast forwarding by relay agents would cause one copy of each
client SOLICIT message to be delivered to each server from each relay
agent.  In turn, the client might receive multiple responses from each
server (potentially number_of_relay_agents * number_of_servers
messages).  Such behavior would not scale well in an environment with
many relay agents on each link and many DHCP servers.

In the ensuing discussion, Ralph Droms suggested that an election
process among relay agents, in which the collection of relay agents on
a link would elect a single relay agent to forward client messages,
would reduce the number of messages delivered to DHCP servers.  Erik
suggested in his review an expanding ring mechanism through which the
multicast scope would initially be limited and subsequently expanded
as necessary to locate a DHCP server.  There was some disagreement
about whether an expanding ring search will find the appropriate
server; the *closest* server might not necessarily be the *best*
server.  The WG generally agreed that clients should be simple and
that relay agents and servers should be administered to limit the
transmission of DHCP messages; however, experience with DHCPv4
indicates that there is room for complexity on the client side - some
clients may need to participate in the decision about which server to
choose.  The WG strongly recommended that the DHCPv4 "server
selection" option, in which server choices are prioritized by a simple
mechanism (currently, an integer indicating the "preference" or
"priority" for a server; client simply chooses highest preference
server) be used as a model for client-side selection.

The discussion concluded with the recommendation that the multicast
mechanism be retained, with additional mechanisms so that relay agents
can reduce the number of forwarded messages (presumably, reduce to
one) and servers can minimize and prioritize their responses.  The
authors were asked to consider an applicability statement to provide
guidance to DHCP system administrators in configuring DHCP clients and
servers to minimize DHCP network traffic.

The last major issue was processing of reconfigure messages.  the
first question was in the description of the semantics of the
reconfigure message - in particular, is the server responsible for
ensuring that all clients have responded to the reconfigure message?
Does the server need to continue attempting to contact clients until
any outstanding leases have expired?  Discussion of this question will
continue on the WG mailing list.  Another issued is the interaction
between DHCP reconfigure and stateless autoconfiguration - can action
from DHCP invalidate an address obtained through stateless
autoconfiguration and vice versa?

Some additional issues:

* The extensions draft is missing the vendor class identifier - Jim
  and Charlie will add the appropriate definition.

* Are FQDNs appropriate for client identification of an IP address?  Is
  there a latency issue in dynDNS updates?

* Should a server issue an explicit response if it has no available
  addresses?  Consensus was that current behavior - no response - is
  appropriate.

* A representative from the Year2000 WG asked that the DHC WG review
  the DHCPv6 specification for date issues.