Subject: [Geopriv] [geopriv] #22: Resolution does not define Geographic Privacy policy ?

From: "geopriv issue tracker" <[email-masked]>
Date: Thu, 17 Sep 2009 04:48:14 -0000

#22: Resolution does not define Geographic Privacy policy ?
---------------------------------------+------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]          
     Type:  task                       |      Status:  new                       
 Priority:  minor                      |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |     Version:                            
 Severity:  Active WG Document         |    Keywords:  policy                    
---------------------------------------+------------------------------------
 What is this statement intended to mean:

 >Resolution does not define Geographic Privacy policy ?

 RFC3825 makes a great point of this, but it's meaning has never been
 clear.  Can we either clarify this, or remove the statement entirely.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/22>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Thu, 17 Sep 2009 07:09:08 -0000

Severity:  Active WG Document         |   Resolution:                            
 Keywords:  policy                     |  

Comment(by [email-masked]):

 Currently, the document does not discuss privacy policy, so that there
 isn't much context provided. I interpret the statement to imply that
 neither resolution (nor uncertainty) metrics relate to privacy policy.  If
 we are to say anything, more explanation is probably required.

 Martin's 3825bis document did contain the following paragraph in Section
 1:

    This document only defines the delivery of location information from
    the DHCP server to the client, due to security concerns related to
    using DHCP to update the database.  Within the GEOPRIV architecture
    as defined by RFC 3693 [RFC3693], the defined mechanism in this
    document for conveying initial location information is known as a
    "sighting" function.  Sighting functions are not required to have
    security capabilities and are only intended to be configured in
    trusted and controlled environments.  (A classic example of the
    sighting function is a Global Positioning System wired directly to a
    network node.)  Further discussion of the protections that must be
    provided according to RFC 3694 [RFC3694] are in the Security
    Considerations section of this document (Section 4).

-- 
Ticket URL: <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/22#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Sep 2009 10:23:20 -0500

>#22: Resolution does not define Geographic Privacy policy ?

this paragraph is sloppy.

"...as defined by RFC 3693 [RFC3693], the defined mechanism in this 
document..." talking about two different documents is clumsy.

The above paragraph is also inaccurate. DHCP servers are not sighting 
(or are sighters for) anything.  Another application residing on the 
same entity as the DHCP server can do this sighting function, but has 
zero to do with the DHCP server other than the API between the 
functions. The DHCP server is further separated from sighting when 
the server relies on a backend (i.e., separate) server for location 
information for a specific client's request.  This communication 
would *not* be DHCP at all, which isn't clear from the above paragraph.

This paragraph is also missing the point recently raised that the 
security properties of LI delivery of an LCP is based on the protocol 
itself, not a function of the server needing to do anything (i.e., 
there is no authorization step or encryption necessary).

In the case of DHCP, the server receives a broadcast message with a 
circuit-ID identifier and merely responds with a unicast with the LI. 
There is nothing else done.

James

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 17 Sep 2009 08:58:53 -0700

> there is no authorization step or encryption necessary).

Should this be the central point made with respect to privacy policy? 
Or is there something else to say with respect to resolution/uncertainty
as well?

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 17 Sep 2009 17:31:19 -0500

The paragraph in question comes directly from RFC 4776.  I figured that if it was good enough there, then it is good enough here.  

However, I tend to agree with James.  It doesn’t really say what needs to be said.

So…what do we need to say with respect to policy?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Friday, 18 September 2009 1:59 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] [geopriv] #22: Resolution does not define Geographic Privacy policy ?

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Sep 2009 17:56:51 -0500

At 05:31 PM 9/17/2009, Thomson, Martin wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01CA37E6.8B58EBD7"
>
>The paragraph in question comes directly from 
>RFC 4776.Â  I figured that if it was good enough 
>there, then it is good enough here.Â
>
>However, I tend to agree with James.Â  It 
>doesnâ€™t really say what needs to be said.
>
>So…what do we need to say with respect to policy?<
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Bernard Aboba
>Subject: Re: [Geopriv] [geopriv] #22: Resolution 
>does not define Geographic Privacy policy ?
>

I'm thinking so wrt LCPs, but probably only wrt LCPs.

Much of time, DHCP servers will push - 
unsolicited - Options 123 and/or 99 towards 
clients. Meaning there is no RFC 3118 preshared 
key exchange, or anything else to verify who is 
asking for the information; mostly because no one 
asked for anything, yet it was still sent.

If this sounds horrible, it is - were this 10 
years ago where Ethernet hubs were still in use 
(outside of 4 port residential homes). Nearly all 
Ethernet connections are today are dedicated, 
with dot1x and such already running, therefore 
this is really not a concern (as far as 
eavesdropping or overhearing is 
concerned).  Cable systems send this information 
in the clear - as far as IP is concerned - but 
all Cable systems use 56bit DES encryption within 
the Cable plant, therefore no one hears anything 
(unless someone is stupid enough to have a dot11 
AP attached to the CM that is available to anyone 
who wants to listen).  We can't help the clueless sometimes... ;-)

>Or is there something else to say with respect to resolution/uncertainty

One of the main concerns I have is that we'll get 
through all this work and someone will put this 
Arch doc against the DHCP RFCs and say "hey, 
these RFCs seem to be inconsistent (or violate) what the Arch doc says".

I do not believe that is a goal, but we need to 
reverse engineer Arch to the point that 3825 (and 
its bis) and 4776 end up matching what the Arch 
doc says - so implementers and ID writers in the 
future aren't totally confused.

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 17 Sep 2009 18:27:10 -0500

Hi James,

I don't think that what you're talking about gets us much further with respect to privacy policy.

There are two aspects we need to address here:

 1. policy relating to access control (authorizing the requester)
   
 2. what information the protocol conveys about privacy policy (the geopriv usage rules)

I think that to some extent, what you are saying contributes to answering the first question.  This also requires that we rely on the LCP policy (or Marc's new label).

What I infer from the text: "resolution does not define Geographic Privacy policy" is that this is an attempt to say that the information is not intended to convey geopriv usage rules.  Of course, this is just inference - I'm not a mind reader.

If we want to address the second point, maybe we need to establish what the _implied_ geopriv usage rules are associated with the location information.  For instance, is the DHCP client permitted to retransmit the information?  In this case, I think that any answer other than 'yes' would be silly, but it might help to explicitly make this point.

--Martin

> asked for anything, yet it was still sent.

3825 recommends against sending option 123 without first receiving a request for it.  The same is said in 4776 about option 99.  Do implementers ignore SHOULD-strength recommendations in RFCs so consistently?