[Sip] RE: [Geopriv] Consensus on changes to location-conveyance
"Rosen, Brian" <Brian.Rosen@neustar.biz> Tue, 25 July 2006 20:42 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tjk-0000ST-7V; Tue, 25 Jul 2006 16:42:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tji-0000QQ-6D; Tue, 25 Jul 2006 16:42:38 -0400
Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Tjh-0001z3-Bo; Tue, 25 Jul 2006 16:42:37 -0400
Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PKgaox008341; Tue, 25 Jul 2006 20:42:37 GMT
Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 16:42:36 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 25 Jul 2006 16:42:35 -0400
Message-ID: <ED0887AEB595F74DB74934F4C37C08DC0A19662C@stntexch04.cis.neustar.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] Consensus on changes to location-conveyance
Thread-Index: AcawKZxZAaHsJrZ2T7CK9PirQWRobgAAErbw
From: "Rosen, Brian" <Brian.Rosen@neustar.biz>
To: Ted Hardie <hardie@qualcomm.com>, sip@ietf.org
X-OriginalArrivalTime: 25 Jul 2006 20:42:36.0736 (UTC) FILETIME=[DCDF1400:01C6B02A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cbb41f2dbf0f142369614756642005e3
Cc: geopriv@ietf.org
Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
Thanks. To define the "retransmission for routing" bit, we need to rev PIDF-LO. I don't think doing that in location-conveyance is the right place. Would you agree? Is there consensus one way or the other on this? Generally, I do agree explicit is better than implicit for any kind of permission. I'm loath to generate yet one more RFC, but this one looks simple enough. With respect to an HTTP protocol for location by reference dereferencing, I have no problem with having some other document specify this. We're going to have a simple mechanism defined in location-conveyance to allow such an extension; it won't require the SIP change process. If that is an acceptable compromise, then we can close this issue, although I'll certainly be holding off a couple of days to hear from other folks. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Tuesday, July 25, 2006 4:34 PM > To: Rosen, Brian; sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Geopriv] Consensus on changes to location-conveyance > > At 2:45 PM -0400 7/25/06, Rosen, Brian wrote: > >Summarizing, you think hop-by-hop security (TLS) is acceptable when the > >location is sent for the purposes of location based routing, but you are > >not in favor of defining "retransmission=no" to permit sending the > >location to the routing database (e.g. LoST). You want a more explicit > >permission. > > Yes. > > >I don't think a cid: with a ruleset is acceptable, as it would not > >permit location by reference added by a proxy to specify this. > > Fair enough. > > > > >If this is the consensus, I think we would have to add a bit to the PIDF > >to explicitly control this behavior. > > I think an extension that says "retransmission for routing=yes" is the > cleanest > way to go. > > > >Why do you think we must specify an HTTP dereference procedure in this > >document? What is the purpose when the SIP based method is available? > >We had believed we had to have SOME method of dereferencing to make > >location-by-reference meaningful in the document. If we have one sip > >based method, we meet the requirement. Having more options, especially > >completely new HTTP based protocols IN THIS DOCUMENT seems unnecessary > >and unwise. For example, if we define such a protocol, it becomes a > >geopriv "using protocol" and needs an explicit analysis against the > >geopriv criteria. > > I don't think we have to do it in this document, but I read your previous > message as a statement of consensus about the HTTP dereference mechanisms > that have been discussed. I don't agree with that statement, since I > think the > HTTP discussions somewhat over-thought the potential problems. In > particular, a > lot of the discussion was around the idea that > http://dereference.example.org/foo-pidf-lo > might mean lots of different things, depending on what http meant. There > are > already ways to deal with that; none of them are perfect (see, for > example, > the discussion in draft-reschke-webdav-mount-05.txt and its appendix A for > a similar > problem in a different context), but they can work, especially if you set > a baseline > approach. > > regards, > Ted Hardie > > > > >Brian > > > >> -----Original Message----- > >> From: Ted Hardie [mailto:hardie@qualcomm.com] > >> Sent: Tuesday, July 25, 2006 2:19 PM > >> To: Rosen, Brian; sip@ietf.org > >> Cc: geopriv@ietf.org > >> Subject: Re: [Geopriv] Consensus on changes to location-conveyance > >> > >> At 1:38 PM -0400 7/25/06, Rosen, Brian wrote: > >> >4. We proposed to explicitly allow hop-by-hop TLS security for > >location > >> >when the endpoint wished to allow routing based on location. We > >further > >> >proposed to interpret "Do not Distribute" flags as allowing sending > >of > >> >the location to the routing database (LoST for example). Hannes > >pointed > >> >out that there was a proposal to allow two Location headers, one of > >> >which could be used for routing and another for onward forwarding to > >the > >> >recipient. Hannes' message seemed to agree that "Do not distribute" > >> >would allow sending of the location to the routing-by-location > >database, > >> >but would obligate the proxy that did that to remove the location > >before > >> >it forwarded the message. There were no other messages on this > >thread. > >> > >> Actually, I commented on the same problem, though it may have been > >> connected to one of the related threads; here's the text of that > >message: > >> > >> >At 5:23 PM -0400 7/19/06, Brian Rosen wrote: > >> >>NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT > >> ONLY TO > >> >>GEOPRIV > >> >>However, this opens up the issue of geopriv privacy concerns because > >the > >> >>sender does not know the identity of the element (proxy) that will > >route > >> the > >> >>call using LoST. It may be that the UAC itself does this, but it > >may be > >> >>some other intermediary. > >> >> > >> >>If the identity of the intermediary is not known, then protecting > >the > >> >>location information becomes more difficult, because we cannot > >encrypt > >> using > >> >>keying material from the intended recipient. > >> > > >> >Just to mention this, it appears to also rule out the idea of > >encrypting > >> >with the user's key, since there is no way of knowing whether the > >> "intended > >> >recipient" has that key material either. Intended recipient is > >actually > >> >a bit of a problematic term here, since it's really the on-path > >network > >> elements > >> >which consume the information. They aren't the intended recipient of > >> >the communication, they are the recipients of the signaling (of which > >> location > >> >is now a part). > >> > > >> >This is a bit confusing because it seems to be possible to include a > >> >"re-transmission allowed" rule with a value of "no" (intended to be > >> >consumed by the "intended recipient" of the underlying > >communication), > >> >while still wanting to allow the location to be passed along the > >path. > >> > > >> >>In fact, we would need to use > >> >>hop-by-hop security, with transitive trust. This is what the > >emergency > >> case > >> >>does, but it also allows no channel security if necessary (usually > >> meaning, > >> >>try it with TLS and if that fails, try again without TLS). > >> > > >> >While I certainly encourage hop-by-hop security, I don't think it > >really > >> >meets the geopriv privacy concerns. I think you have to have some > >way > >> of > >> >expressing "re-transmission for routing permitted" (and likely > >retention > >> >limited), since that is a separate statement. > >> > > >> >Just typing aloud here, but could we come up with a way to use an > >> >external ruleset to express this? With an embedded cid, that would > >> >not actually require dereferencing. > >> > Ted > >> > > >> > >> > >> > >> >We conclude that allowing hop-by-hop security for location based > >routing > >> >is acceptable, and Do Not Distribute DOES allow forwarding to a > >routing > >> >database, but requires that the proxy doing the location based route > >to > >> >remove the location it uses for that purpose. > >> > >> To reiterate this, I do not believe that this is sufficient; I think > >you > >> have to > >> have some way of saying "re-transmission for routing permitted" before > >> you meet the geopriv privacy concerns. > >> > >> >5. We proposed to create a parameter and a registry to distinguish > >> >multiple ways to dereference a location where HTTP(S) was the > >transport. > >> >Resolution of this issue depends on resolution of issue 6. > >> > >> I believe that an HTTP GET of a PIDF-LO object is a reasonable > >baseline. > >> Saying that other mechanisms should update this document with their > >> dereferencing mechanisms if they could be confused with the baseline > >> seems to me to be sufficient. I'm not sure a registry is needed. In > >> practice, > >> I don't think we would hit the interoperability problems often. These > >> days, > >> extensions to HTTP commonly use different mime types to indicate the > >> special > >> handling, and I expect anyone creating a more feature-rich > >dereferencing > >> mechanism built on HTTP would not end up using pidf-lo. > >> > >> That means the "uri confusion" aspects of the discussion are probably > >not > >> that severe. The only issue is if someone supports only the more > >feature- > >> rich > >> alternative and not a baseline GET of the pidf-lo. I think we should > >> discourage that, by establishing a real baseline. > >> > >> Note also that HTTP URIs don't indicate the HTTP Method directly; > >often > >> they > >> support multiple methods (e.g. HEAD and GET). > >> > >> >6. We proposed to allow sip/sips and pres: in the location header. I > >> >later speculated that if we allow this, it forms a simple way to do > >> >location-by-reference, and we could eliminate the raw HTTP(S) Get > >> >proposal, with the parameter and registry entirely. There was some > >list > >> >traffic in favor of this. Martin Thompson is skeptical that SIP > >> >Presence Subscribe/Notify is actually allowed as a geopriv "using > >> >protocol". Several of think that it is. If we don't get any more > >> >comments on this proposal, we will allow sip/sips and pres, not have > >any > >> >http(s) resolution text, and not propose a parameter and accompanying > >> >registry. > >> > >> I share some of Martin's skepticism here, but I won't fall on my sword > >> if the WG goes in this direction. > >> > >> Thanks for the clear set of issues and opportunity to comment, > >> > >> Ted Hardie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Consensus on changes to location-conveyance Brian Rosen
- Re: [Sip] Consensus on changes to location-convey… Jeroen van Bemmel
- RE: [Sip] Consensus on changes to location-convey… Brian Rosen
- [Sip] RE: [Geopriv] Consensus on changes to locat… Rosen, Brian
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- [Sip] Re: [Geopriv] Consensus on changes to locat… Andrew Newton
- Re: [Sip] Consensus on changes to location-convey… Jeroen van Bemmel
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Peterson, Jon
- [Sip] RE: [Geopriv] Consensus on changes to locat… Rosen, Brian
- RE: [Sip] Consensus on changes to location-convey… Brian Rosen
- [Sip] RE: [Geopriv] Consensus on changes to locat… Rosen, Brian
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Thomson, Martin
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Brian Rosen
- [Sip] RE: [Geopriv] Consensus on changes to locat… Peterson, Jon
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Jeroen van Bemmel
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Brian Rosen
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Brian Rosen
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Winterbottom, James
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Rosen, Brian
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Jeroen van Bemmel
- [Sip] RE: [Geopriv] Consensus on changes to locat… Marc Linsner
- [Sip] Re: [Geopriv] Consensus on changes to locat… Ted Hardie
- [Sip] RE: [Geopriv] Consensus on changes to locat… Ted Hardie
- [Sip] Re: [Geopriv] Consensus on changes to locat… Henning Schulzrinne
- Re: [Sip] Consensus on changes to location-convey… Henning Schulzrinne
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Marc Linsner
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Paul Kyzivat
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Rosen, Brian
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Henning Schulzrinne
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Henning Schulzrinne
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Henning Schulzrinne
- [Sip] Re: [Geopriv] Consensus on changes to locat… Henning Schulzrinne
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Jeroen van Bemmel
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Henning Schulzrinne
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Henning Schulzrinne
- [Sip] RE: [Geopriv] Consensus on changes to locat… Abbott, Nadine B
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- [Sip] RE: [Geopriv] Consensus on changes to locat… Abbott, Nadine B
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Henning Schulzrinne
- [Sip] RE: [Geopriv] Consensus on changes to locat… James M. Polk
- [Sip] RE: [Geopriv] Consensus on changes to locat… Brian Rosen
- [Sip] RE: [Geopriv] Consensus on changes to locat… Winterbottom, James
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… James M. Polk
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Henning Schulzrinne
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Henning Schulzrinne
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Winterbottom, James
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Winterbottom, James
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Winterbottom, James
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Brian Rosen
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Henning Schulzrinne
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Winterbottom, James
- [Sip] RE: [Geopriv] Consensus on changes to locat… James M. Polk
- Re: [Sip] RE: [Geopriv] Consensus on HTTP(S) in S… James M. Polk
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… James M. Polk
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Dawson, Martin
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… James M. Polk
- Teasing apart positions (was Re: [Sip] RE: [Geopr… Andrew Newton
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… James M. Polk
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… James M. Polk
- [Sip] RE: [Geopriv] Consensus on changes to locat… Winterbottom, James
- RE: Teasing apart positions (was Re: [Sip] RE: [G… Thomson, Martin
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Dawson, Martin
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton
- Re: Teasing apart positions (was Re: [Sip] RE: [G… Andrew Newton
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Marc Linsner
- [Sip] RE: [Geopriv] Consensus on changes to locat… Drage, Keith (Keith)
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Drage, Keith (Keith)
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Hannes Tschofenig
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Hannes Tschofenig
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Hannes Tschofenig
- [Sip] Re: [Geopriv] Consensus on changes to locat… Hannes Tschofenig
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Hannes Tschofenig
- [Sip] Henning's Suggestion Hannes Tschofenig
- [Sip] Location by Reference Requirements Hannes Tschofenig
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Hannes Tschofenig
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Brian Rosen
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Brian Rosen
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… James M. Polk
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… James M. Polk
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Stark, Barbara
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Jeroen Van Bemmel
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Henning Schulzrinne
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Jeroen van Bemmel
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Hannes Tschofenig
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Jeroen van Bemmel
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Hannes Tschofenig
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Jeroen van Bemmel
- RE: [Sip] RE: [Geopriv] Consensus on changes to l… Brian Rosen
- Re: [Sip] RE: [Geopriv] Consensus on changes to l… Andrew Newton