RE: [dhcwg] Restrictions of information flow in leasequery messages

["Bernie Volz" <[e-mail]>]

Kim:

I agree with you - this information is generally available.

Perhaps a solution is that a server always has the option of not
returning data it considers too sensitive - such as GEOPRIV information.
Perhaps something like the following should be added to the Security
Considerations:

   In some environments it may be appropriate to configure a DHCP server
   with option numbers that MUST not be returned in response to
   DHCPLEASEQUERY messages because these options are considered to
contain
   sensitive information.

I do think that once security options exists for relay to server
communication, if this was a concern at a site, the site should use
those options (and restrict who the server responds to for a
DHCPLEASEQUERY).

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Kim Kinnear
Sent: Thursday, April 08, 2004 4:52 PM
To: Ralph Droms; [e-mail]
Cc: [e-mail]
Subject: Re: [dhcwg] Restrictions of information flow in leasequery
messages


At 08:16 PM 4/6/2004, Ralph Droms wrote:
>Ted Hardie:
>
>Discuss:
>This whole method has "invitation to mischief" printed in large, block 
>letters across its shirt.  After being told repeatedly that there is no

>restriction on the use cases for this mechanism, this text:
>
>        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.
>
>sets off lots of alarm bells.  If I read this right, *any information* 
>associated with that IP address is returned?  If information used to 
>construct a location object is present (as in the geopriv dhcp-li 
>draft), that would get returned? That seems kind of excessive for an 
>access concentrator, but very, very nice for a black hat.  This whole 
>section on Parameter Request List options:
>
>        The Parameter Request List option (option 55) SHOULD be set to
>        the options of interest to the requester.  The interesting
>        options are likely to include the IP Address Lease Time option
>        (option 51), the Relay Agent Information option (option 82) and
>        possibly the Vendor class identifier option (option 60).  In
the
>        absence of a Parameter Request List option, the server SHOULD
>        return the same options it would return for a DHCPREQUEST
>        message which didn't contain a DHCPLEASEQUERY message, which
>        includes those mandated by [RFC 2131, Section 4.3.1] as well as
>        any options which the server was configured to always return to
>        a client.
>
>has no restrictions of any type on the return of any data.  Why is all 
>of this data being made available via this method?

        I suppose because all of this data is already available on
        the wire (and sometimes broadcast) if you just watch it 
        go by.  Of course, you have to *be* on the wire to see it
        that way.

        What do the rest of you think about this issue?

        Cheers -- Kim


>It's too bad that SNMP is off the table here, as that would give you a 
>realistic way to limit data to specific queries and queriers.
>
>Limiting the protocol to a very specific use that fits the demonstrated

>need seems like it would make getting the security mechanisms right 
>easier; if this is meant to be truly general purpose, it needs a 
>general purpose mechanism that would give it the same level of security

>as SNMP would for this same purpose.
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg


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


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