Subject: RE: [dhcwg] Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 19 Nov 2005 08:40:44 -0500

Henning:

Some comments below.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Friday, November 18, 2005 10:08 PM
> To: Bernie Volz (volz)
> Cc: Ted Hardie; Ralph Droms (rdroms); DHCP discussion list; 
> [email-masked]
> Subject: Re: [dhcwg] Re: I-D 
> ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
> 
> Let me try some text to  have something to beat up:
> 
> Generally, location information is transmitted from the DHCP server  
> to the DHCP client. Under limited special circumstances, a DHCP  
> client may want to inform the DHCP server of its current location,  
> e.g., to facilitate system management of wireless end systems  
> equipped with location measurement equipment such as GPS. Thus,  
> clients MAY implement the transmission of location 
> information to the  
> server. Unlike the server-to-client transmission, this poses unique  
> privacy concerns since the client has no way to express its detailed  
> privacy preferences to the server. For example, clients may not want  
> the server to use location information for anything but system  
> management and emergency calling purposes. To limit the privacy  

I'm fine with the above, but I think this potentially crosses the line
with what Ted was saying: "((Server here does not mean box; it means any
other function, even if it is within the same administrative domain or
resident in the same box)". I think Ted's definition is a bit extreme
and agree with your wording. I think there are valid uses of this
information by other "components" in special/restricted circumstances
(such as what you specify since DHCP has nothing to do with emergency
calling itself). And, if a client really doesn't want the information to
be used for anything, it just doesn't supply it!

Perhaps that's a better way to view this ... While the information
should not be distributed by the receiving server, it may be used for
functions within the server's administrative domain. A client that
doesn't agree to those rules of use by the server is always free NOT to
provide the information. Therefore, clients SHOULD NOT send this by
default.

> exposure, all client-provided location information has an implied  
> privacy policy that only allows usage by the receiving entity. It  
> cannot be forwarded to other entities. Old location information must  
> not be retained after the information has been updated by the client  
> or the lease expires.

Good to see lack of MUST NOT in the above sentence since the information
could be in logs or transaction records.

> 
> The DHCP client would use the [???] messages for this purpose.

> Old location information must  
> not be retained after the information has been updated by the client  
> or the lease expires.

How about:

Old location information should/must be discarded when updated by a
client in a subsequent transaction, when the lease is released by the
client, or the lease expires.

> 
> Implementations MUST allow clients to be configured so that they do  
> not send location information to the server and SHOULD/MUST operate  
> on an opt-in basis, i.e., in a default configuration, no location  
> information is transmitted to the server.
> 
> --- end text ---
> 
> DHCP experts should probably fix up my wording imprecision.
> 
> Henning
> 
> 
> On Nov 18, 2005, at 9:51 PM, Bernie Volz ((volz)) wrote:
> 
> > Ted:
> >
> > Propose some text? I think your summary is correct, but I'm not sure
> > exactly what your end proposal is. If it is essentially 
> Henning's with
> > more detail on why the server isn't allowed to distribute this
> > information (if received from the client), I'd be happy.
> >
> > - Bernie
> >
> >
> >> -----Original Message-----
> >> From: Ted Hardie [mailto:[email-masked]]
> >> Sent: Friday, November 18, 2005 6:36 PM
> >> To: Bernie Volz (volz); Henning Schulzrinne
> >> Cc: Ralph Droms (rdroms); DHCP discussion list; [email-masked]
> >> Subject: RE: [dhcwg] Re: I-D
> >> ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
> >>
> >> Because of a family medical issue, I've been unable to follow
> >> the list for the past
> >> week or so.  Sorry to revive the thread, but I want us to be
> >> clear about the
> >> proposals on the table.  I've tried to summarize them in a
> >> brief way below.
> >>
> >> From Andy:
> >>
> >> We treat DHCP server-to-client as a sighting function.  That
> >> makes the information
> >> sent  "location information" under GeoPriv terms, which is
> >> exempt from the
> >> GeoPriv privacy considerations because of the problems with
> >> application of
> >> the rules before it is possible to construct a location
> >> object.    We do not
> >> treat DHCP client-to-server as a sighting function (since the
> >> location is
> >> the client's, not the servers), and so the location passed is
> >> subject to
> >> GeoPriv privacy concerns.  Since DHCP is not carrying PIDF-LO,  it
> >> should not carry anything, and the client-to-server direction
> >> should be
> >> ruled out.
> >>
> >> From Bernie:
> >>
> >> The client-to-server direction should not be ruled out, but
> >> its use should
> >> be restricted by the Security Considerations set out in
> >> GeoPriv documents.
> >> He points in particular to RFC 3694 (I believe to the
> >> Protocol Attacks in 4.1).
> >>
> >> He believes that this puts the use of the information passed
> >> client-to-server
> >> under the administrative policy control of the server:
> >>
> >>
> >>> For (2), this depends on if and how the server uses the received
> >>> information. And, that is up to the administrative policies on the
> >>> server.
> >>>
> >>
> >> From Henning:
> >>
> >> Let's not make it a MUST NOT, but instead indicate that the
> >> default permission
> >> for anything sent from client-to-server is "do not
> >> distribute".   Since the client's
> >> sending it indicates permission for the server to have it,
> >> this restricts the
> >> communication from going anywhere else.  This is a compromise  
> >> position
> >> to accomplish the two perceived goals:  it should not be a
> >> protocol error,
> >> but the information should be restricted.
> >>
> >>
> >>
> >> I hope this captures, in brief, the basic positions.  If I
> >> have gotten any of
> >> these wrong, please correct me.
> >>
> >> In general, I support Henning's proposed compromise, but I am
> >> concerned that
> >> some supporting it may not recognize the full implications.
> >> Reading RFC 3694,
> >> as Bernie suggests, is important to digging those out.  My
> >> reading is that
> >> with a default of "do no distribute" and no other way within
> >> the client-to-server
> >> exchange to indicate a non-default set of rules, there is no
> >> way that the information
> >> can move beyond the DHC server to any other server  (Server
> >> here does not mean
> >> box; it means any other function, even if it is within the
> >> same administrative
> >> domain or resident in the same box).  According to RFC 
> 3694's model,
> >> changing that default is not within the policy control of the
> >> server--it is
> >> a function of the rule maker (see section 6).  The DHC client
> >> would be the
> >> rule maker here.    If I have misunderstood, and we agree
> >> that this is the
> >> case, then I believe a short of RFC Editor note can be added
> >> (or a quick
> >> respin done).
> >>             regards,
> >>                 Ted Hardie
> >>
> >>
> >>
> >>
> >>
> >>
> >> At 8:01 PM -0500 11/14/05, Bernie Volz \(volz\) wrote:
> >>
> >>> I'm find with this restriction.
> >>>
> >>> - Bernie
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Henning Schulzrinne [mailto:[email-masked]]
> >>>> Sent: Monday, November 14, 2005 7:52 PM
> >>>> To: Bernie Volz (volz)
> >>>> Cc: Ralph Droms (rdroms); DHCP discussion list; Ted Hardie;
> >>>> [email-masked]
> >>>> Subject: Re: [dhcwg] Re: I-D
> >>>> ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
> >>>>
> >>>>
> >>>>
> >>>> Bernie Volz (volz) wrote:
> >>>>
> >>>>> Henning:
> >>>>>
> >>>>> I assume this default "do not distribute" policy applies
> >>>>>
> >> for either
> >>
> >>>>> direction (client to server (server should not distribute)
> >>>>>
> >>>> and server to
> >>>>
> >>>>> client (client should not distribute)) or do you propose to
> >>>>>
> >>>> have this
> >>>>
> >>>>> apply only when the client sends it to the server?
> >>>>>
> >>>>
> >>>> There is a crucial difference, as John Schnitzlein pointed
> >>>> out: The DHCP
> >>>> server is telling the client where it is, which the client is
> >>>> presumably
> >>>> is free to share with whomever it likes. ("It's *my* location
> >>>> and I'll
> >>>> do what I want with it.") I'm ignoring the case here of
> >>>>
> >> the abductee
> >>
> >>>> case where the kidnap victim is told that if he reveals
> >>>>
> >> his location,
> >>
> >>>> he'll be shot. I don't think we need to support this
> >>>> particular kind of
> >>>> enforced location privacy and I doubt that RFC 
> injunctions would be
> >>>> particularly effective in this case.
> >>>>
> >>>> If the client tells the server where it is, the client 
> is telling a
> >>>> third party something that has potential privacy 
> implications. Just
> >>>> because I'm telling Verizon where my 802.16 wireless modem is
> >>>> located so
> >>>> that it can help with 911 calls or dispatch a repair truck
> >>>> doesn't mean
> >>>> that I'd like Verizon to sell or give this information to the
> >>>> world at
> >>>> large. In PIDF-LO, there is a basic privacy indicator that
> >>>> allows me to
> >>>> make a choice ("keep this to yourself"); this is not
> >>>>
> >> currently in the
> >>
> >>>> geo or civic DHCP options. Thus, the suggestion for a
> >>>> privacy-friendly
> >>>> default policy.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> If this policy doesn't apply when from server to client
> >>>>>
> >>>> (what the I-D
> >>>>
> >>>>> currently allows), what policy does apply to the
> >>>>>
> >>>> information the client
> >>>>
> >>>>> receives as this privacy information isn't communicated?
> >>>>>
> >>>> And, thus isn't
> >>>>
> >>>>> this be a flaw in the current document that should be addressed
> >>>>> (irrespective of the issue I raised below).
> >>>>>
> >>>>
> >>>>
> >>
> >
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 19 Nov 2005 18:06:57 -0500

> provide the information. Therefore, clients SHOULD NOT send this by

I agree that 'single server' is too narrow and pretty useless, plus it 
gets into trouble even with standard setups consisting of relay agents 
or a separate database backend server. 'Administrative domain' works for 
me, as it seems pretty well defined by common usage in lots of protocol 
documents.

>>The DHCP client would use the [???] messages for this purpose.

Addendum: I believe this should only be permissible in unicast 
DHCPINFORM, not in any broadcast requests, for obvious privacy reasons. 
(DHCPREQUEST seems to be commonly used in broadcast mode. If we allow 
DHCPREQUEST, it seems too likely that lazy implementors will include the 
information in broadcast requests.)

Text:

The DHCP MUST use the unicast DHCPINFORM request for this
purpose.  In general, the client MUST NOT broadcast or multicast
location information.

> client, or the lease expires.

Works for me.

As I said, I'd like to close this issue and move on. Please speak up 
soon if you disagree with this resolution or have text suggestions.

Henning