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, geopriv-request@ietf.org 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 geopriv@ietf.org 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 geopriv-request@ietf.org You can reach the person managing the list at geopriv-owner@ietf.org 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 <mlinsner@cisco.com> Subject: Re: [Geopriv] policy-uri To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Cc: geopriv@ietf.org Message-ID: <C87C572D.27569%mlinsner@cisco.com> 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" <Hannes.Tschofenig@gmx.net> 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 Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv------------------------------ _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv End of Geopriv Digest, Vol 75, Issue 1 **************************************
