RE: [Geopriv] Location-by-value in a SIP Location Header

From: Drage, Keith (Keith) ^lt;drage@lucent.com>
Date: Thu Jul 20 2006 - 09:24:58 EDT

See inline

Keith

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Sent: 19 July 2006 14:00
> To: Drage, Keith (Keith)
> Cc: 'Thomson, Martin'; Rosen, Brian; Henning Schulzrinne;
> sip@ietf.org;
> geopriv@ietf.org
> Subject: Re: [Geopriv] Location-by-value in a SIP Location Header
>
>
> Hi Keith,
>
> Drage, Keith (Keith) wrote:
> > (As SIP WG chair)
> >
> > Just to set some limits to this discussion, let me state
> where we are
> > in the progression of this work item. Remember it is now being
> > classed as urgent and we need to get an RFC out of the door, and the
> > SIP chairs are working with the GEOPRIV chairs as to the
> quickest way
> > to do this:
> >
> > 1) The requirements in the document have been approved by
> the SIPPING
> > group (a long time ago) and therefore we should not be inventing new
> > requirements without a clear use case that has clear agreement.
>
> At that time when the requirements were written we weren't
> even close to
> understand how the VoIP emergency service solutions would look like.
>

The statement I wrote did not preclude new requirements, merely said that new requirements MUST be well justified with a clear use case and that we then need to seek agreement on the new requirement, i.e. start a thread with "We need this new requirement because...." rather than "Wouldn't it be nice if we could do..."

> >
> > 2) The SIP group have already identified that two mechanisms to
> > support these requirements should be documented (e.g. the
> location by
> > value in a body, and the location by reference in a header.
> These two
> > mechanisms appear to support all the current requirements. In other
> > words, SIP have agreed the technical solution, and we are in the
> > stage of trying to document it.
>
> Actually, as James pointed out the document supports implicitly three
> mechanisms:
> * Location by Value in the Body (by end host)
> * Location by Reference in the Header (by end host and by the proxy)
> * Location by Reference in the Body (by end host)
>
> In my scenario mail I wanted to point out that it is necessary to
> describe these 3 mechanisms and to discuss the difference
> between an end
> host and a proxy doing the processing.
>

In terms of previous WG agreements we have only two mechanisms:
- location by value in a body
- location by reference in a header
Any side effect of poor specification does not mean that the SIP WG automatically needs to consider anything else. To reiterate, if you think we need a new solution other than these, then in all probability the requirement that leads to this need is missing, and you need to start from the use case that generates the requirement - as I grant that you are working towards (although at the moment I (individually) am not convinced.

> >
> > 3) Using a data URL appears to add a third mechanism, if
> only because
> > it will at least need to have a different set of security
> > considerations documented for it.
>
> As I argued in my long list of scenarios I don't believe that the
> security properties are different compared to the approach where
> Location by Reference (with the reference being added by the
> proxy) is used.
>
> > We should only be adding a third mechanism if:
> >
> > a) the existing mechanism can be shown not to meet all the
> > requirements; or b) the use case where it offers advantages is
> > clearly identified; and c) the compatibility issues are addressed
> > (i.e. does the UAS need to support all of what is now three
> > mechanisms or is there some other support requirement); and
> d) this
> > can be shown as impossible to be discussed as a future extension.
>
> Within the emergency work we got the feedback that a number
> of folks are
> interested in attaching location information per value by a SIP proxy.
> I don't want them to do it without having us to look at the
> implications.
>
> The 3GPP architecture wasn't quite detailed enough on this subject to
> judge whether they are one of the potential consumers. Are they? You
> know it better than I do. We still need to have a discussion
> on some of
> these issues in ECRIT. Ted provided excellent meeting minutes.
>

We will need to consider than outside this mail. Personally I think by reference works better for the 3G architecture in this use case. There is certainly no explicit 3GPP requirement at the moment.

>
> >
> > Could I also suggest (in addition to the above) that if people want
> > to proceed with this discussion, it would be appropriate to
> submit an
> > i-d targeted at the SIP WG identifying the technical solution
> > proposed (with as much completeness as is possible). And remember if
> > you think this discussion is needed, it needs to occur quickly.
>
> Sure, we can do this.
>
> Still, I believe it also helps the solutions offered in the current
> document if we discuss the security aspects. I am interested
> to have a
> good location conveyance document that covers a discussion
> about these
> issues.
>

This draft isn't going to proceed unless we get the security right. Normal drafts only have to jump the IESG security hurdle. We need to get it though GEOPRIV and their security (privacy) requirements as well.

> In GEOPRIV we had a long discussion about the security aspects of
> retrieving location information from the access network using
> a layer 7
> protocol. If we ignore the details then there is a lot of similarity.
>
> >
> > regards
>
> Ciao
> Hannes
>
> >
> > Keith
> >
> >
> >> -----Original Message----- From: Thomson, Martin
> >> [mailto:Martin.Thomson@andrew.com] Sent: 19 July 2006 00:15 To:
> >> Rosen, Brian; Henning Schulzrinne Cc: sip@ietf.org;
> >> geopriv@ietf.org Subject: RE: [Geopriv] Location-by-value in a SIP
> >> Location Header
> >>
> >>
> >> If you want technically feasible, I can post a URI to the list that
> >> includes a complete PIDF-LO with DSig. It's a little long though.
> >>
> >> I'm not suggesting that this a good idea, but I see no reason to
> >> prevent it.
> >>
> >>
> >>> -----Original Message----- From: Rosen, Brian
> >>> [mailto:Brian.Rosen@neustar.biz] Sent: Tuesday, 18 July 2006
> >>> 11:07 PM To: Henning Schulzrinne Cc: sip@ietf.org;
> >>> geopriv@ietf.org Subject: RE: [Geopriv] Location-by-value in a
> >>> SIP Location Header
> >>>
> >>> Perhaps some enlightenment is in order. It's not clear to
> >>
> >> me how you
> >>
> >>> dsig a Data uri in a Location header (or maybe you mean
> >>
> >> dsig the pidf-lo
> >>
> >>> and put both the pidf-lo and the signature in the Data URI)
> >>> somehow? Are there some examples of this kind of thing elsewhere?
> >>>
> >>>
> >>> If we are ignoring technical arguments (as opposed to use
> >>
> >> cases), it's
> >>
> >>> out of forgetfulness, and not willfulness. What were you
> >>
> >> referring to?
> >>
> >>> Brian
> >>>
> >>>
> >>>
> >>> -----Original Message----- From: Henning Schulzrinne
> >>> [mailto:hgs@cs.columbia.edu] Sent: Tuesday, July 18, 2006 8:59 AM
> >>> To: Rosen, Brian Cc: sip@ietf.org; geopriv@ietf.org Subject: Re:
> >>> [Geopriv] Location-by-value in a SIP Location Header
> >>>
> >>> Brian, James:
> >>>
> >>> this is simply false. If desired, XML-DSIG is a well-known and
> >>> accepted mechanism to achieve integrity. Such specification is no
> >>> longer than the MUST NOT that you propose. You are also
> >>> willfully ignoring the other technical arguments made as part of
> >>> this
> >>
> >> discussion.
> >>
> >>> Henning
> >>>
> >>> On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote:
> >>>
> >>>
> >>>> There was a desire expressed by Hannes to provide a way
> >>
> >> for a proxy to
> >>
> >>>> insert location-by-value. He had proposed a SIP Location
> >>>> header specific way. In IETF66, Henning suggested just using a
> >>>> data URI.
> >>>>
> >>>> Doing this may run afoul of the geopriv location privacy
> >>>> concerns, because there is no way for the user to sign the
> >>>> header to provide assurance that the PIDF, and specifically the
> >>>> retention and other policy bits are preserved. Note that
> >>>> S/MIME provides sufficient
> >>
> >> integrity
> >>
> >>>> protection for a body. It's probably okay to use TLS per hop
> >>>> to provide privacy, but not integrity protection. The authors
> >>>>
> >>
> >> believe that there
> >>
> >>>> is no really compelling use case for this feature, and
> >>
> >> the effort to
> >>
> >>>> define acceptable security mechanisms for location data
> >>
> >> in a header
> >>
> >>>> would be a significant effort, further delaying the draft.
> >>>>
> >>>> We propose, therefore, to state in sip-location-conveyance,
> >>>> that a Data URI MUST NOT be used in the Location header until a
> >>>>
> >>
> >> standards track
> >>
> >>>> RFC defines a suitable security mechanism to protect the PIDF
> >>>> in the header.
> >>>>
> >>>> Brian and James
> >>>>
> >>>> _______________________________________________ Geopriv mailing
> >>>> list Geopriv@ietf.org
> >>>> https://www1.ietf.org/mailman/listinfo/geopriv
> >>>
> >>>
> >>> _______________________________________________ Geopriv mailing
> >>> list Geopriv@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/geopriv
> >>
> >> --------------------------------------------------------------
> >> ---------------------------------- This message is for the
> >> designated recipient only and may contain privileged, proprietary,
> >> or otherwise private information. If you have received it in error,
> >> please notify the sender immediately and delete the original. Any
> >> unauthorized use of this email is prohibited.
> >> --------------------------------------------------------------
> >> ---------------------------------- [mf2]
> >>
> >
> >
> > _______________________________________________ Geopriv
> mailing list
> > Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
> >
> >
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 20 Jul 2006 14:24:58 +0100

This archive was generated by hypermail 2.1.8 : Thu Jul 20 2006 - 09:35:50 EDT