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

[Marc Linsner <[e-mail]>]

Hannes,

Do you agree that it's OK for DHCP to deliver device level location on
networks that provide confidentiality at layer 2?

-Marc-

On 8/18/10 4:39 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
<[e-mail]> wrote:

> Hi James, 
> 
> I already suggested text that should be included.
> If this group cares about privacy then the document should better say
> something (like it does in other documents as well).
> 
> Ciao
> Hannes
> 
>> At 02:46 AM 8/17/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> 
>>>> 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.
>>> 
>>> Whether the hotel network provider uses DSL or Cable does
>> not matter for
>>> this purpose.
>> 
>> huh? Cable uses BPI, and DSL systems are individually run. How are
>> they the same, and why is this an issue?
>> 
>> 
>> 
>>>> 
>>>> 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.
>>> 
>>> The GEOPRIV working group is about describing what privacy properties
>>> are being provided for the solutions we develop. You have always been
>>> quite keen on documenting everything in detail -- particularly when
>>> other people proposed something.
>>> 
>>> Describing what we assume are reasonable operational
>> considerations that
>>> are applicable is a good thing, I believe.
>> 
>> and yet your text could prevent a valid design choice(s). So
>> how is that good?
>> 
>>> We cannot have all these chats about how important privacy
>> is for us but
>>> then when it actually has an operational impact then we back-off.
>>> 
>>> In this specific case, I am not sure I understand what you mean with
>>> additional requirements. A DHCP server better has an idea about the
>>> network topology since otherwise how does it hand out the IP
>> addresses
>>> and other configuration parameters.
>> 
>> for one, RAIO means it doesn't matter what topology is between the
>> server and the RAIO, but your suggested text doesn't account for that.
>> 
>> another point, in a built wiremap database, as long as the final link
>> is switched, the entire topology is immaterial - which isn't
>> accounted for in your text either.
>> 
>> and still another point, if the final hop is within the house, and
>> the house has a shared topology, does that mean the location provided
>> by the home gateway (acting as a DHCP server to the home) is an
>> invalid topology? You text says this home gateway MUST NOT hand out
>> any location, which is just plain wrong.
>> 
>> 
>>>> 
>>>> 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.
>>> 
>>> There are two parts here:
>>> 
>>> 1) The first part is to describe what the privacy risks are with the
>>> technology
>> 
>> the doc already has a warning about DHCP communications not being
>> secure, and that already passed IESG review in RFC 3825. What changed
>> in this version that made things so much more insecure to warrant
>> modifying the text about that warning?
>> 
>>> 2) The second part is to make some recommendations for anticipated
>>> envionments.
>> 
>> Then I suggest you offer text about every type of topology and see if
>> you can get "strong" consensus, which is required to change the text
>> of a "bis" document.
>> 
>> 
>>> With SMBs and the usage of this document you are touch on
>> item #2. Your
>>> recommendation would be that the privacy risks are not so dramatic in
>>> such an environment and I believe it is OK to say that.
>>> 
>>> You still want to talk about item #1 in the document.
>> 
>> it is already there, as I and others have stated.
>> 
>> James
>> 
>> 
>>> Ciao
>>> Hannes
>>> 
>>>> 
>>>> James
>>>> 
>>>> 
>>>>>> -----Original Message-----
>>>>>> From: ext Marc Linsner [mailto:[e-mail]]
>>>>>> Sent: Tuesday, August 10, 2010 3:59 PM
>>>>>> To: Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
>>>>>> 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)"
>>>>>> <[e-mail]> 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:[e-mail]]
>>>>>>>> Sent: Tuesday, August 10, 2010 3:23 PM
>>>>>>>> To: Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
>>>>>>>> Subject: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis
>>>>>>>> 
>>>>>>>> Hannes,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 8/10/10 3:33 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
>>>>>>>> <[e-mail]> 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
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> _______________________________________________
>>>>> Geopriv mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>> 
>>>> 
>> 
>>