Subject: [dhcwg] RFC4388: Revision or new option needed?

From: Niall O'Reilly <[email-masked]>
Date: Thu, 03 Jun 2010 11:53:15 +0100

Hello.

	I'ld like to understand what the WG's sense of the "right"
	joint reading of RFCs 4388 and 2131 is, with regard to a use
	case which seems to me to be unreasonably constrained.

	Depending on the outcome, I may be minded to propose
	either a revoision to RFC4388 or a new IPv4 DHCP option.

	In RFC4388, the following text appears.
	[Apologies for possible line-wrapping problems, passim]

5. Protocol Overview

    In the following discussion of the DHCPLEASEQUERY message, the
    client of the message is assumed to be an access concentrator.
    Note that access concentrators are not the only allowed (or
    required) consumers of the information provided by the
    DHCPLEASEQUERY message, but they do give readers a concrete
    feel for how the message might be used.

	This seems to suggest that not only in-path devices such
	as access concentrators and DHCP relays, but also
	out-of-path processes, might legitimately send a
	DHCPLEASEQUERY message.  An examples of such a process
	might be a persistent management application, or an
	ephemeral utility.

	Now, in RFC2131, the destination of a reply to a DHCP
	request is specified as follows.

    If the 'giaddr' field in a DHCP message from a client is non-zero,
    the server sends any return messages to the 'DHCP server' port on
    the BOOTP relay agent whose address appears in 'giaddr'.

	Unfortunately, although RFC4388 seems to admit the possibility
	of a variety of sources for the DHCPLEASEQUERY message, the
	lack of any text updating the above passage from RFC2131
	constrains this variety in the following ways.

	A "DHCPLEASEQUERY application" cannot usually run on the
	same host as a DHCP server, as the 'DHCP server' port
	typically needs to be reserved for the DHCP server process.

	A "DHCPLEASEQUERY application" must run with sufficient
	privilege to acquire access to the 'DHCP server' port.
	This is a small nuisance for a persistent application, as
	the usual technique is available of starting with elevated
	privileges and retaining these only for as long as is
	necessary to acquire the relevant system resources.
	For an ephemeral process, such as a worker script for a
	monitoring application, this approach is not available.

	I'ld appreciate an indication of both

    (a)	whether the WG feels that these constraints are intended
	in RFC4388,

	and

    (b)	whether the WG would welcome a draft proposing one or
	more remedies for these constraints.

	Thanks and best regards,

	Niall O'Reilly

---

From: Pavan Kurapati <[email-masked]>
Date: Thu, 3 Jun 2010 17:30:42 +0530

Hi Niall,
Please find replies inline

Thanks,
Pavan

On Thu, Jun 3, 2010 at 4:23 PM, Niall O'Reilly
<[email-masked]<[email-masked]>
> wrote:

> It may sound strange as to why an application running on DHCP server would
need a leasequery mechanism to retrieve the lease data. Couldnt it retrieve
just from the lease database?
Are you going to suggest removing the constraint of adding 'giaddr' in
leasequery message (Thus indicating there was no relay agent in between)? If
so, the same condition applies when L2RAs are used and is mentioned in
draft-ietf-dhc-l2ra-extensions which also covers leasequery.

> I believe this requirement is rather implementation/deployment specific.

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 03 Jun 2010 14:48:16 +0100

> just from the lease database?

	Not without reading the entire lease database from disk
	and parsing it all each time lease information is needed.
	Caching and high-watermark checking could mitigate this.

	The DHCP server already has this data in memory, and can
	return it 'instantly'.

> draft-ietf-dhc-l2ra-extensions which also covers leasequery.

	Thanks for that pointer.

	From a quick look, this mode (broadcast, source 0.0.0.0,
	destination 255.255.255.255) doesn't seem to be useful
	for my case.  I may need to read it again, more carefully.
	I need unicast, and possibly a number of routing hops
	greater than zero.

	I wasn't thinking of removing the constraint on how 'giaddr'
	is used in the query.

	What I had in mind was that, in sending its response to a
	DHCPLEASEQUERY request, the server should be required to be
	able to respect the UDP encapsulation, whether as standard
	behaviour, under control of a configuration option, or
	triggered by signalling using a new DHCP option (perhaps
	named 'lq-strict-layering').

	Best regards,
	Niall O'Reilly

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 03 Jun 2010 15:28:45 +0100

On 03/06/10 13:00, Pavan Kurapati wrote:
> On Thu, Jun 3, 2010 at 4:23 PM, Niall O'Reilly wrote:

	Sure, but ...

	Unix-like systems are hardly a niche deployment
	platform for monitoring applications.  8-)

	More seriously:	there doesn't seem to be a good reason
	to insist that the response to LEASEQUERY, sent from an
	L3-aware process, must be sent to a fixed port without
	regard to the originating UDP port.  This is in contrast
	to the case of the DORA dialogue, which has to take place
	in a pure L2 context, where the IP and UDP layers haven't
	been set up yet.

	Best regards,
	Niall O'Reilly

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 03 Jun 2010 11:10:31 -0400

Niall,

There wasn't any particular thought one way or the other
concerning the port when writing RFC 4388, at least on my part.
I can see why you might want to have a leasequery message
returned to the sender's port instead of using the "server port".

I suspect that when writing the draft that became RFC 4388, we'd
have been more sensitive to the port issue if our testing
environment (DHCP client simulator and DHCP server) didn't have a
mode where all packets are returned to the sender, to ease the
configuration when testing various features.  Thus, we routinely
run leasequery clients and servers on the same machine because
we've completely overridden the standard DHCP server's return
addressing.  We don't do this for all testing (obviously we don't
do that when testing the addressing), but for debugging and some
other kinds of testing it makes it more convenient.  Without
this capability, we'd have run into the port issue ourselves
when first implementing leasequery years ago and probably 
thought our way to a solution then.

I fully understand why you might want to run a leasequery client
on the same machine as the DHCP server.  Many server's don't
provide access to their internal database because to do so
typically impacts performance to at least some degree.

The challenge in writing a clarification draft would be to decide
how to change the DHCP server's behavior for the cases that you
care about without breaking people who depend on the current
behavior.

One thought that I've had for years but never acted upon would be
to write a general draft for a new option which would be a
"return to sender" option.  This option would override the normal
addressing for a return DHCP packet(and would work on any packet,
not just leasequery).  It would cause the return packet to be
sent to the IP and port of the sender regardless of the "normal"
RFC 2131/4388/etc.  mandated behavior.

This would be useful for a number of scenarios (including
testing).

I could also imagine such an option have a couple of flags, one
which said "send reply to incoming IP address", and another which
said "send reply to incoming port".  That way you could get just
the port behavior you want, but others could use it in general.

In any case, I would support a draft to fix up RFC4388 in some
way that doesn't break existing clients that depend on the
current behavior.

Regards - Kim

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 03 Jun 2010 16:42:03 +0100

Kim,

	Thanks for your thoughtful reply.

	In particular, I liked the following.

> the port behavior you want, but others could use it in general.

	Neat!

	Some reference to protection against indirect DoS attacks
	may need to be mentioned, along the lines of the "... SHOULD
	protect ..." matter in 4388.

> way that doesn't break existing clients that depend on the

	Great!

	Thanks again, and best regards.

	Niall O'Reilly

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 3 Jun 2010 13:58:01 -0500

Perhaps just making use of TCP based leasequery solves the problem too?
There is the bulk leasequery draft
(http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-bulk-leasequery/)
and it states:

   Bulk Leasequery supports queries by MAC address and by Client
   Identifier in a way similar to [RFC4388].

Seems to me that using TCP solves the problem nicely? Though of course
we have to get this draft to advance!

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Niall O'Reilly
Sent: Thursday, June 03, 2010 11:42 AM
To: DHC-WG WG
Subject: Re: [dhcwg] RFC4388: Revision or new option needed?

	Kim,

	Neat!

	Great!

	Niall O'Reilly