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

From: Tschofenig, Hannes (NSN - FI/Espoo) ^lt;hannes.tschofenig@nsn.com>
Date: Wed Aug 18 2010 - 04:39:49 EDT

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
Received on Wed, 18 Aug 2010 11:39:49 +0300

This archive was generated by hypermail 2.1.8 : Wed Aug 18 2010 - 04:40:23 EDT