RE: [dhcwg] Leasequery: should it be standardized?

Kim--

I agree that the proposed leasequery mechanism is of value for refreshing
stateless devices such as access concentrators, relay agents, and others.  I
further agree that using the existing BOOTP packet layout as the framework
for requesting and supplying information is appropriate.

I do have a few nits with the draft, however.  The position of the "R" bit
flag needs to be identified, or at least, proposed.

Selectively quoting from the -04 draft:

3.  Background

   The focus of this document is to enable access concentrators
   to send DHCPLEASEQUERY messages to DHCP servers, to obtain
   location information of broadband access network devices.

5.  Protocol Overview

   The access concentrator initiates all DHCPLEASEQUERY message
   conversations.

7.  Security Considerations

   Access concentrators SHOULD minimize potential denial of service
   attacks on the DHCP servers by minimizing the generation of
   DHCPLEASEQUERY messages.

These three excerpts suggest, but do not mandate, that a leasequery exchange
is solely between the access concentrator and server.  Two issues with this:

(1) I have a mild objection to using the term "access concentrator" solely
because that is not a component of the DHCP model environment, which
consists of clients, servers, and relay agents.  Since your proposed
definition states that an access concentrator must contain relay agent
functionality, why not just call it a relay agent?

(2) There is no language prohibiting forwarding of leasequery messages from
a downstream device, presumably because relay agents are often cascaded when
constructing large networks.  This suggests that dhcp clients or other
network hosts may originate leasequery messages:  a relay agent must forward
the messages because there is no mechanism defined to prevent this.  Hence,
a potential Denial of Service attack, initiated by a rogue client or other
rogue host.  Note that I don't have any suggestions short of the use of DHCP
Authentication to prevent this.

A more general question arises with respect to the "R" flag.  Why is it
important to know if the IP to MAC or IP to Client Identifier mappings
exist(ed) because of a reservation?  If a reservation exists, but the server
has not had a protocol exchange with the client, the server would respond
with DHCPLEASEKNOWN, and if queried for the IP Address Lease Time, the
server could respond with an all-ones entry (signifying infinite).  I also
contend that an unused reservation should not receive a DHCPLEASEACTIVE
reply as that somewhat misstates the circumstances.

For your information, Glenn and I will be submitting the -08 draft of the
DHCPv4 server MIB prior to the San Francisco meeting.  In the [hopefully
final] draft there is a table defined, the dhcpv4ServerClientTable, that
contains the IP address, last client request type and time of request, and
the last server response type, indexed by the 3-tuple, 'hlen,' 'htype,' and
'chaddr.'  There is a second table, the dhcpv4ServerAddressTable, that
contains the lease type (static, dynamic, expired, reserved, unusable),
allowed and served protocol, physical address, client identifier, host name,
and domain name, indexed by the IP address.  So, while this covers the same
information (and more) as the proposed leasequery option, it is much less
usable for lightweight inquiries.

--Barr

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg