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

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

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
> > >
> > >
> 
>