Dynamic Host Configuration Protocol (DHCP) Leasequery
RFC 4388

Note: This ballot was opened for revision 09 and is now closed.

(Steven Bellovin) Discuss

Discuss (2004-03-26 for -)
(26 March 2004)
The Security Considerations section says this:

   DHCP servers SHOULD prevent exposure of location information
   (particularly the mapping of hardware address to IP address lease,
   which can be an invasion of broadband subscriber privacy) by
   employing some form of relay agent authentication between the
   DHCPLEASEQUERY client and the DHCP server.

   Clients of the DHCPLEASEQUERY message SHOULD ensure that their data
   path to the DHCP server is secure.  Clients SHOULD use Relay Agent
   Information security as a way to achieve this goal.

What is "some form of ... authentication"?  What is "Relay Agent Information security"?  Put another way, what is mandatory to implement?

(Thomas Narten) Discuss

Discuss (2004-04-06 for -)
I wonder if the following is a possible protocol issue:

Assume a client is connected to access concentrator A, and obtains a
lease. Client moves to concentrator B, and obtains a second lease. B
looses state, and issues lease query. Server will return two
addresses. How does B know which addresses (and location info) applies
to it (i.e, B) rather than A? Is there info in the protocol messages
that allows B to determine which address is its? E.g., does the
relay-agent info include such an identification in it?

Make it absolutely clear what a server must implement (in terms of the
options it must store), especially in the case of options that already
exist, but that a server may not be required to store. E.g, what is
required for this spec that is different from normal DHC. relay agent
option, client identifier (??).

Specific comments:

>       o Query by IP address:
> 
>         For this query, the requester supplies only an IP address in the
>         DHCPLEASEQUERY message.  The DHCP server will return any
>         information that it has on the most recent client to have been
>         assigned that IP address.

make clear what info must be echoed back, esp. relay agent option,
since there is no requirement in existing DHC that a server store
it...

>         For this query, the requester supplies only a MAC address in the
>         DHCPLEASEQUERY message.  The DHCP server will return any
>         information that it has on the IP address most recently accessed
>         by a client with that MAC address.  In addition, it may supply
>         addition IP addresses which have been associated with that MAC
>         address in different subnets.  Information about these bindings
>         can then be found using the Query by IP Address, described
>         above.
 
may or does above? (multiple occurances) Seems like this should be a
MUST (in order for good interoperability/correctness). I.e., if only
one address is returned (when there are several) it might be  the
wrong address and incorrect behavior may result. 

>    Any DHCP server which supports the DHCPLEASEQUERY message should save
>    the information from the most recent Relay Agent Information option
>    (option 82) [RFC 3046] associated with every IP address which it
>    serves. It is assumed that most clients which generate the

seems like should -> MUST.

>    A server which implements DHCPLEASEQUERY should also save the
>    information on the most recent Vendor class identifier, option 60,
>    associated with each IP address, since this option is also a likely
>    candidate to be requested by clients sending the DHCPLEASEQUERY
>    message.

Why? How is this info useful to the relay agent? Also, for
interoperabilty, SHOULD->MUST??

>          client-last-transaction-time

is this really critical? How is it used? Document doesn't say.

>                       8     DHCPINFORM
>                       TBD   DHCPLEASEQUERY
>                       TBD   DHCPLEASEUNASSIGNED
>                       TBD   DHCPLEASEUNKNOWN
>                       TBD   DHCPLEASEACTIVE
>                       TBD   DHCPUNIMPLEMENTED

To simplify IANA's task, use TBD1, TBD2, etc. so that when IANA
assigns them, it's clear which values go where.

>       o DHCPLEASEUNASSIGNED
> 
>         The server MUST respond with a DHCPLEASEUNASSIGNED message if
>         this server has information about the IP address, but there is
>         no active lease for the IP address.  The DHCPLEASEUNASSIGNED
>         message is only returned for a query by IP address, and
>         indicates that the server manages this IP address but there is
>         no currently active lease on this IP address.

Are any DHC options returned? I'd assume no, but it would be good to
say that explicitely. 

>    If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the
>    IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message
>    MUST be that of an IP address for which the client that most recently
>    used the IP address matches the Client-identifier or MAC address
>    specified in the DHCPLEASEQUERY message.

wording: not "must recently used" but the one who currently owns the
lease. Right?

>    In the case where more than one IP address has been accessed by the
>    client specified by the MAC address or Client-identifier option, then
>    the DHCP server MUST return the IP address returned to the client in
>    the most recent transaction with the client unless the DHCP server
>    has been configured by the server administrator to use some other
>    preference mechanism.

Shouldn't it return _all_ the addresses? Above reads like only one
address needs to be returned.

>    If the Client-identifier option (option 61) is specified in the
>    Parameter Request List option (option 55), then the Client-identifier
>    (if any) of the client associated with the IP address in the "ciaddr"
>    field SHOULD be returned in the DHCPLEASEACTIVE message.

Does a server already normally store the client identifier option?
I.e., is this required already?

>    In the case where more than one IP address has been involved in a
>    DHCP message exchange with the client specified by the MAC address
>    and/or Client-identifier option, then the list of all of the IP
>    addresses SHOULD be returned in the associated-ip option (option
>    TBD), if that option was requested as part of the Parameter Request
>    List option.

Seems potentially problematic for a client to ask for just one, and
get only one, if there are many.  It might get back the wrong one and
do the wrong thing.


Editorial:

>    DHCPLEASEACTIVE message.  The DHCP server MUST the Relay Agent
>    Information option that was received when from the relay agent
>    associated with this IP address.

omitted word.

>    When a DHCPUNIMPLEMENTED message is received by an access
>    concentrator, it means that DHCPLEASEQUERY processing is not
>    implemented in the responding server.  This information SHOULD be
>    cached may not be the case that other aspects of DHCPLEASEQUERY
>    processing are not implemented in that server.

parsing problem

(Margaret Cullen) Yes

(Harald Alvestrand) No Objection

Comment (2004-04-01 for -)
No email
send info
Reviewed by Lucy Lynch, Gen-ART

Summary of review:

This draft is very clearly written, and well organized. My only question
has to do with "other  processes and devices" (not a show stooper).
The abstract states that "Other  processes and devices, many that already
send and receive DHCP format packets, sometimes need to access this
information". Much of the draft is focused on "access concentrator"s
(see for example section 5), a list of those other potenial uses might be
helpful. I also notice a number of lower case shoulds & musts in this
section which may actually be 2119 keywords and should be reviewed in that
light.

(Brian Carpenter) No Objection

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

Comment (2005-10-19)
No email
send info
I've decided that this should be a comment rather than a discuss; here's the text, if the authors
wish to consider it, but I will not block on this:

The authors have made a lot of progress on the privacy issue.  I would like
to suggest one tweak on the approach.  The idea of returning the list
according to the client provided parameters will handle most things.  The
list of sensitive options to not return is also a good idea, but I wonder
if we can shift it to the same sort of mechanism but with the opposite
default (everything assumed sensitive until configured non-sensitive).  
That is, can we say "If you are returning something not requested
by the client, check the list to see if it has been configured as non-sensitive".
Would that work okay?

On the congestion control, I've asked Allison to check it and she's agreed.

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2004-03-30)
No email
send info
  Proposed Abstract:
  
    A DHCP server is the authoritative source of IP addresses that it has
    provided to to DHCP clients.  Other processes and devices that already
    make use of DHCP may need to access this information.  The leasequery
    protocol provides these processes and devices a lightweight way to
    access IP address information.

(David Kessens) No Objection

(Allison Mankin) No Objection

Comment (2004-04-02 for -)
No email
send info
Ted has captured all my concerns.  No further objection.

It would probably be a good idea for DHCP to have a guideline
draft added to its charter that includes principles:

retransmission MUST use exponential backoff

Options that leak location information MUST use privacy considerations: 
these were exemplified by the GEOCONF option design.

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) (was Discuss) No Objection

(Alex Zinin) No Objection