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

Marc Linsner <mlinsner@cisco.com> Tue, 10 August 2010 13:54 UTC

Return-Path: <mlinsner@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 57EAC3A6909 for <geopriv@core3.amsl.com>; Tue, 10 Aug 2010 06:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.901
X-Spam-Level:
X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
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 t9YzSwuH20yQ for <geopriv@core3.amsl.com>; Tue, 10 Aug 2010 06:54:42 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C22383A6885 for <geopriv@ietf.org>; Tue, 10 Aug 2010 06:54:41 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAIr3YExAZnwN/2dsb2JhbACfdmFxp0+bT4U6BIk6
X-IronPort-AV: E=Sophos;i="4.55,348,1278288000"; d="scan'208";a="145752728"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 Aug 2010 13:55:16 +0000
Received: from [10.116.195.121] (rtp-mlinsner-8718.cisco.com [10.116.195.121]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7ADtFPA019157; Tue, 10 Aug 2010 13:55:15 GMT
User-Agent: Microsoft-Entourage/12.25.0.100505
Date: Tue, 10 Aug 2010 09:55:14 -0400
From: Marc Linsner <mlinsner@cisco.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, hannes.tschofenig@nsn.com, geopriv@ietf.org
Message-ID: <C886D282.279B5%mlinsner@cisco.com>
Thread-Topic: [Geopriv] draft-ietf-geopriv-rfc3825bis
Thread-Index: Acs4k6f+N2u+B8XbHUeTnpyc7hLb6Q==
In-Reply-To: <20100810132659.272400@gmx.net>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
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: Tue, 10 Aug 2010 13:54:43 -0000

Hannes,

On 8/10/10 9:26 AM, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> wrote:

> You are saying that nobody is going to deploy location at the level of
> individual hosts (but only at the level of access points) and hence there is
> no risk. 
> 
> If you think so then write that into the draft.

I don't believe it's necessary.

Further, RFC3825 includes:

" Wireless hosts can utilize this option to gain knowledge of the
   location of the radio access point used during host configuration,
   but would need some more exotic mechanisms, maybe GPS, or maybe a
   future DHCP option, which includes a list of geo-locations like that
   defined here, containing the locations of the radio access points
   that are close to the client"

Since draft-ietf-geopriv-rfc3825bis is updating RFC3825, it takes strong
consensus to add/remove text from RFC3825.  Since this text is missing from
draft-ietf-geopriv-rfc3825bis, one has to assume the wg agreed to taking it
out.

You might want to go back and figure out why this text was removed and
suggest that it's put back in, or modified and put back in.

-Marc-

 
> 
> -------- Original-Nachricht --------
>> Datum: Tue, 10 Aug 2010 09:22:59 -0400
>> Von: Marc Linsner
>> begin_of_the_skype_highlighting     end_of_the_skype_highlighting
>> <mlinsner@cisco.com>
>> An: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, geopriv@ietf.org,
>> hannes.tschofenig@nsn.com
>> Betreff: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis
> 
>> 
>> 
>> 
>> On 8/10/10 9:17 AM, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> wrote:
>> 
>>> The security consideration section in the draft is there to indicate
>> what the
>>> potential risks are and what should be done about them.
>> 
>> And I'm claiming that the risk is zero, hence we don't need any extra
>> guidance.
>> 
>> -Marc-
>> 
>>> 
>>> I have heard someone saying that "64kb ought to be enough for
>> everyone"...
>>> 
>>> 
>>> -------- Original-Nachricht --------
>>>> Datum: Tue, 10 Aug 2010 09:14:11 -0400
>>>> Von: Marc Linsner
>>>> begin_of_the_skype_highlighting     end_of_the_skype_highlighting
>>>> <mlinsner@cisco.com>
>>>> An: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>,
>>>> geopriv@ietf.org
>>>> Betreff: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis
>>> 
>>>> Hannes,
>>>> 
>>>> Think about what you are saying.
>>>> 
>>>> The only medium currently in use that works as you posit is 802.11.
>> How
>>>> practical (or even possible) is it to use DHCP to provide device level
>>>> location values on a wireless network?  Think thru how one might
>> implement
>>>> such a mechanism and you'll realize it ain't gonna happen!
>>>> 
>>>> -Marc-
>>>> 
>>>> 
>>>> 
>>>> On 8/10/10 9:09 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
>>>> <hannes.tschofenig@nsn.com> wrote:
>>>> 
>>>>> Think about a regular hotel network.
>>>>> 
>>>>>> -----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
>>