[Sip] RE: [Geopriv] Consensus on changes to location-conveyance
Ted Hardie <hardie@qualcomm.com> Wed, 26 July 2006 12:02 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5i5x-000295-Cd; Wed, 26 Jul 2006 08:02:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Taz-0002uH-7E; Tue, 25 Jul 2006 16:33:37 -0400
Received: from ithip TLS security for by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Tax-0000Jo-Lj; Tue, 25 Jul 2006 16:33:37 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6PKXX8X006897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2006 13:33:34 -0700
Received: from [10.0.1.3] (vpn-10-50-16-122.qualcomm.com [10.50.16.122]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6PKXWYl005768; Tue, 25 Jul 2006 13:33:33 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06230907c0ec2df28347@[10.0.1.3]>
In-Reply-To: <ED0887AEB595F74DB74934F4C37C08DC0A19659E@stntexch04.cis.neustar.com>
References: <ED0887AEB595F74DB74934F4C37C08DC0A19659E@stntexch04.cis.neustar.com>
Date: Tue, 25 Jul 2006 13:33:31 -0700
To: "Rosen, Brian" <Brian.Rosen@neustar.biz>, sip@ietf.org
From: Ted Hardie <hardie@qualcomm.com>
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c
X-Mailman-Approved-At: Wed, 26 Jul 2006 08:02:30 -0400
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
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-honeeded. 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 p 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