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

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Nov 2005 16:55:13 -0500

Thanks for your comments. I thought this issue had been resolved, but 
let me try to introduce a compromise position. One of the issues raised 
in the past is that the location information does not have a privacy 
section (unlike PIDF-LO). However, this can be resolved by declaring a 
default "do not distribute" policy for this application.

[I personally don't have a strong opinion on this subject and just want 
to get this draft done, after almost three years.]

Henning

Bernie Volz (volz) wrote:
> Having looked over this draft, I object to the language (MUST NOT) that
> prohibits the client from sending this option (with data) to the server.
> 
> While I understand that there are security implications of doing so,
> pointing out those security issues (such as referencing RFC 3694,
> "Threat Analysis of the Geopriv Protocol") and encouraging use only on
> secured networks or under special circumstances makes much more sense
> than a blanket MUST NOT.
> 
> There are two core security threats in allowing this information to be
> sent from client to server:
> 1) Leakage of location information to other devices on the network
> 2) Alternation or faking of location information to the server
> 
> For (1), many of the devices could obtain this information in the
> response from the server. Admittedly it is a bit easier to capture the
> client's transmission (as it is broadcast in IP4 or multicast in IPv6).
> But, the difference here is fairly minor in most networks.
> 
> There are networks that are secured (perhaps physically) and there are
> also times when sending this information to a server is extremely
> desirable and not a security threat, such as during build-out of the
> cable plant.
> 
> 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.
> 
> For example, a server might allow a client to communicate one of <n>
> possible locations at which it may be located or allow a client to
> augment the information a server has. If and how a server USES this
> information and what of the received information it sends to the client
> is up to the administrative policies in the server.
> 
> Allowing the client to send in information also may be useful to the
> server -- it may keep both the client's reported and the server's
> configured location for the client.
> 
> This is no different in what the client may do when receiving data from
> the server -- it can ignore this information, use all, or use portions
> of it.
> 
> 
> There's also
> http://www.ietf.org/internet-drafts/draft-polk-geopriv-dhc-geo-lci-upstr
> eam-00.txt which is attempting to update RFC 3825 to allow use of that
> DHCP option in either direction (server to client and client to server).
> 
> Changing the language in this draft now avoids the need for further work
> on this subject. And, it isn't like you need to write an extensive
> security considerations sections -- you have RFC 3694 to reference as
> the GEOPRIV WG has already done that work.
> 
> - Bernie Volz
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] 
>>On Behalf Of Ralph Droms (rdroms)
>>Sent: Thursday, November 10, 2005 2:16 PM
>>To: DHCP discussion list
>>Subject: [dhcwg] Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
>>
>>dhc WG members: Please review and comment on draft-ietf-geopriv-dhcp-
>>civil-07.txt.
>>
>>Back in September, I sent a message to the dhcwg mailing list 
>>asking for
>>WG review of draft-ietf-geopriv-dhcp-civil-07.txt (original e-mail is
>>appended to this message).  Shortly after I sent that message, Ted
>>Hardie sent e-mail to the effect that there was another outstanding
>>Discuss on draft-ietf-geopriv-dhcp-civil: 
>>
>>On Mon, 2005-09-19 at 10:16 -0700, Ted Hardie wrote:
>>
>>>Thanks to Ralph for forwarding this to the group.  There 
>>
>>may be a further revision,
>>
>>>however, as David Kessens still has an outstanding discuss 
>>
>>which is not yet
>>
>>>resolved.  David has agreed to update the discuss text to 
>>
>>indicate more clearly
>>
>>>the points of discussion but has not yet done so.  Until 
>>
>>that is complete, it is
>>
>>>not clear whether further changes to this aspect of the 
>>
>>document will be requested.
>>
>>>Your review of this draft is, of course, appreciated, but 
>>
>>please be aware that there may
>>
>>>be a second request.
>>
>>Just to be clear, it is not definitely the case that a -08 
>>revision will
>>be published.  dhc WG members should review the -07 revision and reply
>>with comments to the [email-masked] mailing list by Friday, 
>>2005-11-18.
>>
>>- Ralph
>>
>>=====
>>
>>Following up on the announcement of the publication of draft-ietf-
>>geopriv-dhcp-civil-07.txt, which John Schnizlein forwarded to the
>>mailing list, the -04 revision of this draft was reviewed by 
>>the dhc WG
>>several months ago, in a joint last call with the geopriv WG. 
>> The draft
>>was then submitted to the IESG.  draft-ietf-geopriv-dhcp-civil-07.txt
>>includes changes in response to comments received during the IESG
>>review.  Because this specification involves DHCP, the dhc WG has an
>>opportunity for a final review of the draft.  Accordingly, if you have
>>any comments about the draft, please respond by 1700EDT on 
>>Thu, 9/22.  I
>>will forward any responses to the IESG and the geopriv WG chairs.
>>
>>I prepared a diff of the -04 and -07 versions, but haven't 
>>sent it with
>>this announcement because it's about 200KB (using side-by-side rfcdiff
>>tool).  Let me know if you'd like me to send you an individual copy.
>>
>>- Ralph
>>
>>
>>_______________________________________________
>>dhcwg mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/dhcwg
>>

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

---

From: John Schnizlein <[email-masked]>
Date: Mon, 14 Nov 2005 14:56:16 -0800

I think a statement that there is an implied policy that the DHCP 
server should not distribute location information without explicit 
policy statements authorizing it would be fine.  We might even state 
the general case that no host should distribute location information 
without authorization.  The DHCP client that gets location information 
is under the implicit authorization of its user.   It is the special 
prohibition for (just one direction of) DHCP transfer that is 
objectionable.

John

On Nov 14, 2005, at 1:55 PM, Henning Schulzrinne wrote:

> let me try to introduce a compromise position. One of the issues 
> raised in the past is that the location information does not have a 
> privacy section (unlike PIDF-LO). However, this can be resolved by 
> declaring a default "do not distribute" policy for this application.