Dynamic Host Configuration Protocol (DHCP) Leasequery
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 -)
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
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
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 -)
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.