RE: [Geopriv] Consensus on changes to location-conveyance

A couple notes on the whole "Do not Distribute" flag and its meaning in a SIP context.

Firstly, I think it's obligatory to flex the muscles of location by-reference in response to this. When you send only a reference to location information in an INVITE, that INVITE is not sharing the location information with routing entities, is not a using protocol, and is not "distributing" location information in any sense. Any routing entity that dereferences the URI, and attempts to acquire location information, can be individually authorized by the Location Server, and the protocol over which location information is transmitted to those entities (be it SIP NOTIFYs or whatever) is the using protocol, and is distributing presence information. The entities that receive PIDF-LO through that mechanism are bound not to retransmit it by the "Do not Distribute" flag, but can use it for their personal consumption to make decisions. In short, my contention would be that nothing is broken in this case.

So, what if you're using location by-value? Well, if you can use encryption, then "Do not Distribute" still has some plausible applicability. Of course, encrypting the PIDF-LO object is cumbersome, and you have to be certain to whom you are encrypting it, but I don't think the PIDF-LO can be said to have been "distributed" to anyone that can't even inspect it. They're just relaying a closed envelope to the entity that can open it. That entity would be bound by any "Do not Distribute" flag. Without speaking to the details of the LoST protocol, or making any specific proposal to modify it, I can imagine an approach where the PIDF-LO object could only be decrypted by the LoST server, and even the proxy that sends the query to LoST could not decrypt the object.

And supposing you can't or won't encrypt? Well, in that case I agree that sending location information by-value in an INVITE is ambiguous with regards to the "Do not Distribute" flag. Many, if not most, SIP proxies don't inspect MIME bodies by default, and probably wouldn't even be aware that they are distributing location information - we can't reasonably hold automata responsible for violating the flag in the course of their conventional behavior, anyway. I think back in the day, we roughly concluded that if you need to send location information by-value in cleartext in something like a SIP INVITE, you should set the flag off. There was much talk back at the time that in emergency services cases, you had to sacrifice a certain expectation of privacy that you might want to retain for other location-based services.

I also would like to stress something that I've said a couple of times in the history of this draft - that location conveyance does not exist solely for the purposes of ECRIT's use cases. Don't forget that there are other location-based services that we want to enable in a SIP context, and that even if some approaches wouldn't make sense for ECRIT, that doesn't mean that they shouldn't be specified.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Ted Hardie [mailto:[email protected]]
> Sent: Tuesday, July 25, 2006 11:19 AM
> To: Rosen, Brian; [email protected]
> Cc: [email protected]
> 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
> 
> _______________________________________________
> Geopriv mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip