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)"
<hannes.tschofenig@nsn.com> 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: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
>>>>
>>>>
>>
>>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
