Subject: Minutes from Minneapolis WG meeting

From: Ralph Droms <[email-masked]>
Date: Tue, 6 Apr 1999 23:00:31 -0400 (EDT)

Included below are the minutes from the afternoon (DHCPv4) meeting of the
DHC WG.  Please review and reply with comments by noon, Thursday (4/8) so I
can submit the minutes Thursday afternoon (the minutes are due 4/7 (sic)).

- Ralph

=====

Thanks to Kim Kinnear for compiling these minutes.

DHCP-DNS -- Mark Stapp (Cisco)
============================

Mark will submit a new draft that will include a new section 3.4 for
handling name collisions:

    o DHCP servers and clients should be able to detect and resolve host
    name collisions.

    o Use a "KEY" RR to associate client with a DNS name.

    o Method describes use of "KEY" RR in prerequisites.

Open issues: Is this an adequate solution?  Is use of KEY RR
correct?

Olafur Gudmundsson (TIS) suggested that we might need to define some
unique protocol id when we get to using public keys in the KEY
record. Mark pointed out that Stuart Kwan (Microsoft) has suggested
putting some sort of ACL information in the record as well, but that
Mark hasn't moved forward on that.

DHCP Authentication Status -- Bill Arbaugh (University of Pennsylvania)
========================================================================

Bill discussed open issues with the current draft:

1. Over specified key usage.

    Will be taken care of by changing SHOULD's to MUST's.

2. PKI Usage.  

    Olafur volunteered to give some examples.  He will do so.
    Examples demonstrating the use of shared secret HMAC are already
    in the draft.  Kerberos could use this too according to Ted Lemon (ISC).

3. Securing relay agent interaction.

    This will be easy to fix by examining a few fields and will be
    addressed in the next draft.

4. Global replay protection.

    Adequate protection can be obtained by moving some fields up to the
    front of the packet and will be addressed in the next draft.

5. Client-id -- how to identify the client.

    This is a more difficult problem.  Mike Henry's (Intel) UUID (option 61)
    could solve the problem if made mandatory in DISCOVER's when
    requesting authentication. 

    GUID (Leach/Salz draft) has expired, but there is an open group
    standard that Mike referenced.

6. Kiosk Problem

    The "kiosk problem" arises when a previously unregistered computer
    tries to use DHCP authentication in a network where it doesn't
    know what key to use.  Solving the kiosk problem is not practical
    without changes to the protocol state machine.  The WG concluded
    that the kiosk problem is not easy to solve at the interim
    authentication meeting in Redmond last year.  Trying to do this
    without livelock or deadlock is hard.
    
    The kisok problem is solvable outside of the protocol if there is
    a truly unique global UID, because client can register out of band
    ahead of time.
    
    Another possibility would be to leverage EAP if we changed the
    protocol to send ACK/NAK after DISCOVERs (for instance).

    If solving the kiosk problem requires changes to the DHCP
    protocol, then the problem won't be solved soon.  WG came to
    consensus not to support a solution to the kiosk problem and not

    to change the DHCP protocol.

7. EAP (authentication used in PPP).

   (See above for reference to EAP authentication)

New issues in DHCP Authentication:

*  Mark Stapp asked "What about RELEASE, INFORM, etc?  These messages
   don't seem to be mentioned in the draft".  Bill said that he would
   add text to specify authenticated RELEASE and INFORM in the next draft.

*  Someone asked "What is the basic idea behind the "key-id""?  Bill
   answered that this was put in before some other part of the
   protocol was designed.  There may not be a 1-1 mapping from keys
   to clients.  This allows multiple clients to share keys -- which
   some people think is a bad thing, but the real answer is that it is
   useful sometimes and not useful sometimes.  The secret-id field is
   type dependent, and exists only for the hmac today.

   When a client sends a request, the client gets back a key-id from the
   server, and then the client knows what key to send to the server.  Bill
   said that he would clarify that in the next draft.

Bill said that he would update the draft in the next month, send it to
the list, and allow the list to respond.  Bill doesn't see any further
outstanding issues.  The draft will go to WG last call after Bill
completes the next revision of the draft.

DHCP Schema Meeting Report -- Bernie Volz (Process Software)
============================================================

Bernie listed the attendees.  Andy Bennett will update the draft and
send it out to the attendee list. 

A couple of issues:

    1. Is this the right group to develop a DHCP schema?  The people
    at the schema meeting felt that keeping this in the DHC WG group
    was a good idea.  Bernie Volz and Ralph Droms (Bucknell
    University) will talk offline about how to 
    extend the DHC group charter to include the DHCP schema.

    2. Andrea from Microsoft helped bring the CIM model and the network
    working group inside of the DMTF into perspective for the DHCP Schema
    task force.  

    3.  There was significant discussion about whether or not to store
    leases in the schema.  WG expressed consensus to do so, because
    they are sometimes used for other tools.  Decision was to allow
    but not require this update, and certainly not to require it to be
    used as an authoritative store. 

The group working on the DHCP LDAP schema has made good progress;
there is lots of work left to do.

DHCP Failover Meeting Report -- Kim Kinnear (Cisco)
===================================================

There was an interim meeting on the failover protocol February 10th
and 11, 1999.  The minutes from the meeting were distributed on the
[email-masked] mailing list and are available at

http://www.dhcp.org.  There will be a new draft published to
accommodate the changes resulting from the interim meeting work.

Summary of changes discussed at interim meeting:

* Load balancing based on hash of link-layer addresses
* TCP to be used for data transmission, UDP for polling
* Time synchronization to be suggested but not required; poll messages
  will transmit current time to allow determination of drift

* A straw-person security mechanism based on a shared secret, message
  digests and sequence numbers.

Suggestions:

1.  Try for dynamic load balancing.

2.  Bernie Volz asked "What about when we have TCP and UDP w/different
    transmission speeds -- and we send state in the messages.".  Kim
    Kinnear responded that we should just not put state in the TCP
    messages. 

3.  Servers should not assume that clients only send INIT-REBOOTs when
    they have time remaining on their lease.  The DHCP RFC must be
    edited to clarify that a client MUST NOT send an INIT-REBOOT to a
    server unless it believes that it has time left to run on its
    lease for the IP address. 

Ralph Droms (Bucknell University) noted as an aside that the DHCP RFC
2131 could go to the next step of the standards process anytime
someone volunteered to edit in the considerable number of changes that
Ralph has collected since the last publication.

Subnet Selection Option Status -- Glenn Waters (Nortel)
=======================================================

This option allows the for a DHCP proxy service, especially in cases
where the DHCP server cannot route at all to a network for which it is
supplying IP addresses.

Mark Stapp asked why not do an option to change to whom to send the
packet and use giaddr to select the subnet.  This entirely equivalent to
the proposed option, but might generalize differently.

Kim Kinnear pointed out that giaddr is used for two different things
today, to select the subnet and to decide to whom to send the reply
packet.  Glenn's approach is to use a separate option to override the
subnet selection aspect of the giaddr, but leave the "to whom to send
the reply" part of it the same.  One could, as Mark suggests, use an
option to alter the "to whom to send the reply" part of the giaddr
instead.  The concensus of the group was to leave it way it was.

Glenn said that he would update the draft to make it not "subnet
specific" but network segment specific.

Relay Agent Options Report from IESG -- Harald Alvestrand
=========================================================

IESG sent the relay agent options draft back to the working group.
Harald spoke to the WG to discuss the objections that came up at IESG.

Having read the scenario at the beginning of the relay agent options
draft, Harald has some global concerns with the scenario described (not
with the specifics of the relay agent options themselves).  His two
primary concerns are:

    1.  What happens if a bunch of devices in, say, a house get
    addresses from a DHCP server across the network, and then the
    network goes down?  What happens to the devices in the house that
    would like to talk to each other over the still, intact, network
    that is running inside the house?

    2.  What about when a DHCP client sends a DISCOVER and that is
    broadcast, and the kid-next-door gets the broadcast and responds
    with an bogus address?
    
Harald will accept the relay-agent-options draft if it discusses the
above problems that can occur when using the scenario outlined in the
draft.  Hopefully the draft will do more than warn people about these

problems, and will also suggest some solutions.  He would be satisfied
with two sentences, but really would prefer two paragraphs.

Kim suggested that there are solutions to at least some of these
problems in the DOCSIS documents.  Kim Kinnear volunteered to inform
Mike Patrick of Motorola about these issues and let him know what he
needs to do to move the draft forward.

DHCP Options For Host System Characteristics -- Mike Henry (Intel)
==================================================================

The DHCP Options for Host System Characteristcis draft ,
draft-dittert-host-sys-char-03.txt, has been revised.  Options 93, 94
and 97 will be replaced with options 60 and 61, with a six year grace
period for the transition.  The document will go to WG last call and
publication as an informational RFC.

Connectathon Report -- Mike Carney
==================================

Lots of people went.  Two issues came up around the draft:

1.  How is parameter request list used?  Must it be the same each time?
Mike is suggesting that it not be required, and that servers move more
and more into sending only what clients ask for.

2.  Issues around asking for very long addresses.  Some clients always
ask for a permanent address just to see if they can get one, and expect
the server to limit them.  This caused problems for some server
limitations, and Mike noted that people may want to test this sometimes.

Mike suggested ways to convince vendors to participate in connectathon,
since the more servers and clients that participate the better the whole
event works for all concerned.  He suggested that Ralph put up some
information (like who attended) on the dhcp.org web site.  He also
suggested that we might try to get some cable modem clients to connectathon
next year.