Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt

From: "Kostur, Andre" <[email-masked]>
Date: Mon, 27 Oct 2003 10:29:24 -0800

> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Dynamic Host Configuration 
> Working Group of the IETF.
> 
> 	Title		: DHCP Lease Query
> 	Author(s)	: R. Woundy, K. Kinnear
> 	Filename	: draft-ietf-dhc-leasequery-06.txt
> 	Pages		: 25
> 	Date		: 2003-10-24

A question/clarification on section 6.3.  At the end of this section it
states:

   The giaddr is used only for the destination address of any generated
   response and, while required, is not otherwise used in generating the
   response to the DHCPLEASEQUERY message.  It MUST NOT be used to
   restrict the processing of the query in any way, and MUST NOT be used
   locate a subnet to which the ciaddr (if any) must belong.

What is this staement defending against when it says "It MUST NOT be used to
restrict the processing of the query in any way"?  Does this mean that a
DHCP server implementation may not use the giaddr to determine whether or
not to answer the query?  Does this conflict with the statement later on in
section 7:

   In some environments it may be appropriate to configure a DHCP server
   with the IP addresses of the relay agents for which it may respond to
   DHCPLEASEQUERY messages, thereby allowing it to respond only to to
   requests from only a handful of relay agents.  This does not provide
   any true security, but may be useful to thwart unsophisticated
   attacks of various sorts.

Or is section 7 expecting the service to look at the source IP of the
incoming packet vs. the reported giaddr?

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 27 Oct 2003 15:07:53 -0500

At 01:29 PM 10/27/2003, Kostur, Andre wrote:

>A question/clarification on section 6.3.  At the end of this section it states: 
>
>What is this staement defending against when it says "It MUST NOT be used to restrict the processing of the query in any way"?  Does this mean that a DHCP server implementation may not use the giaddr to determine whether or not to answer the query? 

        This statement was placed in the draft to clarify the use
        of the giaddr as *only* the return address of the
        leasequery message.

        Note that in standard DHCP packet, the giaddr is *both*
        the return address as well as the determiner of the
        network segment on which an IP address should be appear
        (or be allocated).  FOr instance, in a
        DHCPREQUEST/INIT-REBOOT, the giaddr and the requested-ip
        are compared to see if they are compatible, and if they
        aren't, then the DHCPREQUEST/INIT-REBOOT will be NAKed.
        A DHCPREQUEST/REBINDING has much the same processing 
        with the giaddr and the ciaddr.

        The idea is that a DHCPLEASEQUERY with an IP address in
        the ciaddr and the return address for the packet in the
        giaddr should not be rejected because the IP address in
        the ciaddr isn't on the network segment pointed to by the
        giaddr.

        Given that the giaddr is the return address of the
        packet, if the DHCP server doesn't want to send a
        response to that IP address, then it is perfectly free to
        not send it to that IP address.  It just shouldn't try to
        compare the ciaddr and giaddr in the "normal" way, and
        get upset if the don't appear compatible.

        I'll note this as a last call comment, since I could
        certainly clean that paragraph up with another sentence
        or two.

> Does this conflict with the statement later on in section 7:
>
>Or is section 7 expecting the service to look at the source IP of the incoming packet vs. the reported giaddr? 

        Doesn't really matter.  I'd think the giaddr would
        be fine, since this is where you are going to send
        the packet.  

        Cheers -- Kim

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