Re: [Geopriv] draft-ietf-geopriv-rfc3825bis

"James M. Polk" <jmpolk@cisco.com> Mon, 16 August 2010 20:37 UTC

Return-Path: <jmpolk@cisco.com>
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABB03A6A92 for <geopriv@core3.amsl.com>; Mon, 16 Aug 2010 13:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.485
X-Spam-Level:
X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wz+mPQUFIt8R for <geopriv@core3.amsl.com>; Mon, 16 Aug 2010 13:37:16 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C57453A6817 for <geopriv@ietf.org>; Mon, 16 Aug 2010 13:37:16 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.55,378,1278288000"; d="scan'208";a="574261351"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Aug 2010 20:37:52 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7GKbq6X023539; Mon, 16 Aug 2010 20:37:52 GMT
Message-Id: <201008162037.o7GKbq6X023539@sj-core-2.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 16 Aug 2010 15:37:51 -0500
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, ext Marc Linsner <mlinsner@cisco.com>, geopriv@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E5CD08@FIESEXC015.nsn-in tra.net>
References: <3D3C75174CB95F42AD6BCC56E5555B4502E238B8@FIESEXC015.nsn-intra.net> <C886C565.2799E%mlinsner@cisco.com> <3D3C75174CB95F42AD6BCC56E5555B4502E5CD08@FIESEXC015.nsn-intra.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Aug 2010 20:37:17 -0000

At 08:09 AM 8/10/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>Think about a regular hotel network.

many/most wired hotel networks are DSL-like based, so this doesn't 
apply as directly as it may seem.

What you are suggesting (that the server MUST NOT hand out location 
in shared mediums) is requiring a DHCP server to have physical 
topological awareness before implementing option 123.  The same DHCP 
server can be unaware of ever network topology between it and the 
client - therefore I believe you are placing an excessive burden or 
limitation on DHCP as an LCI delivery means.

I'm concerned about the SMB or residential gateway impact of adding 
this context - which can easily lead to some vendor(s) reading what 
you are proposing and consider DHCP not appropriate for homes or 
small businesses inadvertently, where it otherwise would be logical 
to use. Many gateways of this sort have DHCP as a client to the WAN, 
and as a server to the LAN.

We need to be careful with how we word any changes.

James


> > -----Original Message-----
> > From: ext Marc Linsner [mailto:mlinsner@cisco.com]
> > Sent: Tuesday, August 10, 2010 3:59 PM
> > To: Tschofenig, Hannes (NSN - FI/Espoo); geopriv@ietf.org
> > Subject: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis
> >
> > Hannes,
> >
> > What specific network type(s) are you worried about?
> >
> > -Marc-
> >
> >
> > On 8/10/10 8:25 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
> > <hannes.tschofenig@nsn.com> wrote:
> >
> > > But the conclusion is missing: if you are on a shared link
> > then you must
> > > not share location at the level of the individual hosts. I fear that
> > > those who implement and deploy would not get the point and would
> > > nevertheless reveal information and put the user at risk.
> > >
> > >> -----Original Message-----
> > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com]
> > >> Sent: Tuesday, August 10, 2010 3:23 PM
> > >> To: Tschofenig, Hannes (NSN - FI/Espoo); geopriv@ietf.org
> > >> Subject: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis
> > >>
> > >> Hannes,
> > >>
> > >>
> > >> On 8/10/10 3:33 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
> > >> <hannes.tschofenig@nsn.com> wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> during the GEOPRIV meeting I mentioned missing text in
> > >>> draft-ietf-geopriv-rfc3825bis regarding security.
> > >>>
> > >>> 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) every
> > >> target would
> > >>> be given the exact same location information on a shared medium.
> > >>>
> > >>> Unfortunately, the security consideration section does not
> > >> mention this
> > >>> aspect with a single word.
> > >>
> > >> Not true, currently in the security consideration section of
> > >> the draft:
> > >>
> > >> " Since there is no privacy protection for DHCP messages, an
> > >>    eavesdropper who can monitor the link between the DHCP
> > server and
> > >>    requesting client can discover this LCI."
> > >>
> > >> I don't believe more text is needed.
> > >>
> > >> -Marc-
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>  Hence, I suggest to add:
> > >>>
> > >>> "
> > >>>    Since there is no confidentiality protection for DHCP
> > >> messages, an
> > >>>    eavesdropper who can monitor the link between the DHCP
> > server and
> > >>>    requesting client can discover this LCI. In cases
> > where multiple
> > >>>    hosts share the same link and can therefore see each
> > others DHCP
> > >>>    messages the DHCP MUST NOT hand out location for
> > individual hosts
> > >>>    but MUST rather provide location of the DHCP relay,
> > DHCP server,
> > >>>    or a similar device instead. This ensures that none of the end
> > >>>    devices are able to learn exact information of the other hosts
> > >>>    on the same network.
> > >>> "
> > >>>
> > >>> Ciao
> > >>> Hannes
> > >>>
> > >>> _______________________________________________
> > >>> 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