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

comments in-line

--Barr


> -----Original Message-----
> From: Bernie Volz
> Sent: Friday, 09 April 2004 09:29
>
> Perhaps a solution is that a server always has
> the option of not returning data it considers
> too sensitive - such as GEOPRIV information.
>
...I'd suggest that the option of which information to
return be specifically named as a "local policy" issue -- I
still carry the bruises from the discussion about
provisioning servers with client location information, so am
just a bit sensitive to this one in particular.  As I've
been repeatedly told, in some legal jurisdictions physical
location information is required, to be available to
emergency responders and others according to statute or
ordinance.  One method for obtaining this information might
be to use the DHCPLEASEQUERY mechanism, so we need to be
specific, I think, that the data to be returned ought to be
in the realm of local administrative decisions.  In some
jurisdictions, location information would be considered
private or privileged information, while in others it may be
mandated to be publicly available.  Let's stay away from the
policy questions and declared this a local administrative
matter.


> 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 like this wording....


> 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).
>
...you're almost suggesting that a more complete security
model be developed for DHCPv4, including Access Control
Lists for DHCPLEASEQUERY requests and responses.  While I
don't object, I think that we should keep in mind what we
might be calling for as a future requirement.


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