Subject: Re: [Geopriv] Geopriv Digest, Vol 75, Issue 1

From: Geoff Thompson <[email-masked]>
Date: Tue, 03 Aug 2010 06:47:12 -0700

Marc-
There are some areas in Ethernet where some of the shared medium 
behavior persists.
A couple of examples:
     - An 802.1 bridge/switch before the learning table is complete 
(e.g. after reset)
     - The downstream path of an EPON which is broadcast.
       All of the data appears at each subscribers premises on the 
network side of the subscriber's network termination unit.
Geoff

On 2/8/10 12:00 PM, [email-masked] wrote:
> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/geopriv
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send Geopriv mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/geopriv
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Geopriv digest..."
>
>
> Today's Topics:
>
>     1. Re: policy-uri (Marc Linsner)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 02 Aug 2010 11:06:21 -0400
> From: Marc Linsner<[email-masked]>
> Subject: Re: [Geopriv] policy-uri
> To: Hannes Tschofenig<[email-masked]>
> Cc: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain;	charset="US-ASCII"
>
> Hannes,
>
> Shared medium networks are the place DHCP security (confidentiality) is
> weak.  In today's world, this is 802.11 networks as shared Ethernet is now
> considered historical.  Switched Ethernet does not have this problem.
>
> IEEE802 has a mechanism for 802.11 clients to discover their location.
>
> DHCP does not force every client to have the same location, in either a
> shared or non-shared mediums.
>
> -Marc-
>
> On 7/30/10 3:17 PM, "Hannes Tschofenig"<[email-masked]>  wrote:
>
>    
>> As you see, the DHCP story is very weak.
>> I am wonder who wants to deploy it.
>>
>> On 30.07.2010 15:13, Richard L. Barnes wrote:
>>      
>>> If the DHCP server is providing the same information to everybody --
>>> effectively providing a value by reference -- then there's no reason
>>> to have a policy URI.  You just wouldn't do it.
>>>
>>> Adding a policy URI does introduce another attack vector.  However, if
>>> the client doesn't trust the local network to be secure enough, he can
>>> always irrevocably kill the URI by sending a DELETE request.
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>>
>>> On Jul 30, 2010, at 2:50 PM, Hannes Tschofenig wrote:
>>>
>>>        
>>>> Hi Richard,
>>>>
>>>> I have my doubts that this mechanism gets used for the DHCP based
>>>> solution.
>>>>
>>>> DHCP does not provide confidentiality protection as a built-in
>>>> feature. As Marc mentioned in response to issue#23 (see
>>>> http://trac.tools.ietf.org/wg/geopriv/trac/ticket/23) I raised every
>>>> target would be given the exact same location information on a shared
>>>> medium. So, this is draft-ietf-geopriv-rfc3825bis.
>>>>
>>>> Note: The draft that was forwarded to the IESG does not point out
>>>> this important security aspect, I believe.
>>>>
>>>> If you don't make the same assumption for the DHCP-URI draft then you
>>>> suddenly allow others to modify your policies. This would be really bad.
>>>>
>>>> If you make the assumption that everyone on a shared medium gets the
>>>> same pointer to location and also pointer to policy then you still
>>>> allow others to modify the policy but there is at least no privacy
>>>> harm with revealing location but rather denial of service.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> On 30.07.2010 14:23, Richard L. Barnes wrote:
>>>>          
>>>>> Simplicity: This document does everything that HELD-Context does
>>>>> (except for<snapshot>), without requiring any new XML.  (And
>>>>> <snapshot>  should be a policy extension, anyway.)
>>>>>
>>>>> Generality: This document is not specific to HELD, so that, e.g., it
>>>>> can be used with DHCP.
>>>>>
>>>>>
>>>>>
>>>>> On Jul 30, 2010, at 2:07 PM, Hannes Tschofenig wrote:
>>>>>
>>>>>            
>>>>>> Why not use the existing HELD Context document?
>>>>>>
>>>>>>
>>>>>> On 30.07.2010 14:05, Richard L. Barnes wrote:
>>>>>>              
>>>>>>> The only concern raised in the meeting with regard to
>>>>>>> draft-barnes-geopriv-policy-uri was when Hannes noted that the
>>>>>>> exchange could be made more efficient (in the HELD context)
>>>>>>> overlaying the policy interactions on a HELD transaction.  For
>>>>>>> example, the client could provide policy data in a
>>>>>>> <locationRequest>  object, and the server could specify policy it
>>>>>>> intends to use in the<locationResponse>.  I think we should not
>>>>>>> do this.
>>>>>>>                
>> _______________________________________________
>> Geopriv mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/geopriv
>>      
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>
>
> End of Geopriv Digest, Vol 75, Issue 1
> **************************************
>
>