Subject: [Sip] Consensus on changes to location-conveyance

From: "Brian Rosen" <[email-masked]>
Date: Tue, 25 Jul 2006 13:41:42 -0400

I have put out a number of emails on proposed changes to location
conveyance.  Some of them have sparked a number of comments.  My summary of
consensus on these issues is:

1. We proposed to explicitly disallow use of a Data URI, which would allow
specification of a Location-by-value in a header.  There was a lot of list
traffic on this, currently in the state where Keith asked for a real use
case for it.  So far, we don't see a use case that cannot be provided by
location-by-reference in a header.  If we don't get a good use case, I think
consensus is to disallow location-by-value in a header.

2. Dereferencing location-by-reference.  We had initially proposed to
document a process to use a raw HTTP(S) Get to dereference.  There was a lot
of discussion, and then I made a new proposal, see item 6. 

3. We proposed to allow a Reason header with a 424 Bad Location response.
This seems to be acceptable to the WG.  Geopriv will create and populate the
registry in a separate draft.

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

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.

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.

If this does not reflect your position, please speak up now.

Brian

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 25 Jul 2006 20:13:41 +0200

Brian,

Your point 4 below is a concrete use case for point 1 (location by value in 
header). Using location for routing decisions benefits from quick access, a 
lookup by reference introduces delay.

If you want a proxy to remove the location info, you cannot put the location 
info in the body, because proxies are not allowed to modify that. So you are 
left with location by reference. The use of TLS is then only to protect this 
URL?

Regards,

Jeroen

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 25 Jul 2006 14:30:39 -0400

Jeroen

I've always disliked location-by-reference because it has delay, and
introduces the possibility (in the emergency case especially) where the
dereferencer has connectivity to the endpoint but not the LIS.

The WG however, has consensus that these issues are not significant, and the
benefits outweigh the problems.

Having said that using a reference is NOT seen as a performance problem then
it's not a performance problem, and you can't argue it's a use case.

Agree that if the endpoint wants location to be removed after routing before
forwarding, then it has to use by-reference.  Don't see that as a problem.

Yes, TLS protects the URL, which is important, because anyone observing the
SIP messaging can connect the identity of the SIP correspondent with the
location (if it is allowed to dereference it), which is bad.

Brian

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]]
> Sent: Tuesday, July 25, 2006 2:14 PM
> To: Brian Rosen; [email-masked]
> Subject: Re: [Sip] Consensus on changes to location-conveyance
> 
> Brian,
> 
> > of think that it is.  If we don't get any more comments on this
> proposal,
> > we

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 25 Jul 2006 22:30:02 +0200

Brian,

Three more remarks:

1 - Location by value is much easier to get interoperable than location by 
reference, also because the latter has many semantic issues (in addition to 
performance, chance at failure):
* When dereferencing, for what time instance do I get the location?
* if { moment of call }, how do you guarantee that the dereferenced source 
will have exactly that information?
* if { moment of dereference }, for how long is the URI supposed / assumed 
to be usable?
* how does the user control/limit access to that location information?

All of the above is clear for location-by-value. It is therefore much easier 
to ensure privacy for that, in a way that is easily explained to the user: 
either you give your location at that moment, or you dont. Period

2 - In particular for emergency scenarios, I think you would want both (by 
value and by reference), even within the same request: rough location by 
value (eg cell-id) could be used to route the call to the appropriate 
emergency center, then a Location URI (provided in the same request) can be 
dereferenced from there, which may give a more precise location after some 
time (say 10s of seconds). Moreover, the reference could be used to track 
the location over time

3 Rather than relying on TLS for security of the location-user mapping, I 
always assumed there would be requirements for access control at the 
location server? To me requiring TLS is a definite way to ensure that this 
will not see widespread use...

Regards,

Jeroen

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Jeroen van Bemmel'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 25, 2006 8:30 PM
Subject: RE: [Sip] Consensus on changes to location-conveyance

>> > conveyance.  Some of them have sparked a number of comments.  My 
>> > summary
>> > of
>> > document a process to use a raw HTTP(S) Get to dereference.  There was 
>> > a
>> > lot
>> > This seems to be acceptable to the WG.  Geopriv will create and 
>> > populate
>> > the
>> > was a proposal to allow two Location headers, one of which could be 
>> > used
>> > for
>> > that to remove the location before it forwarded the message.  There 
>> > were
>> > no

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 25 Jul 2006 17:06:09 -0400

Jeroen

I'm a big believer in location-by-value over location-by-reference,
especially for the emergency case.  You won't find me arguing for location-
by-reference.  However, there is clear sentiment to support it, and a
requirement to support proxy insertion of location, which I also think is a
bad idea.  Given that we have to support proxy insertion, and the sentiment
to support -by-reference, I'm leaning towards one mechanism.

To be fair, whether you get location by value or by reference, the validity
issues on the PIDF are the same.  When you have a reference, you do not know
for how long the reference is valid.  When you place the call, you may get a
"fresh" location before you place the call, or you may not.  If you have to
dereference it, at least there is an opportunity for the LIS to say "I have
someone that wants this location now, I can give him my best current
estimate of that location".  I do worry quite a bit about proxy insertion of
location and how the USERS's notion of access control will be honored and
reflected in the ruleset.  I think whether you get the value by location or
by reference, the rules that are supposed to be in there should be the same,
and will mean the same thing.

I agree that you may want to send both a value and a reference for a case
where there may be mobility.

I think you must control both the integrity and the privacy of the location
reference in the SIP header.  The former is important to make sure that the
PIDF, with its ruleset, is delivered intact.  The latter is important to
make sure the user's identity cannot be linked with his location if he
wishes to do so.  Access control at the LIS on a dereference may be another
chance to control access.

Brian

> Sent: Tuesday, July 25, 2006 4:30 PM
> >> Your point 4 below is a concrete use case for point 1 (location by
> value
> >> in
> >> header). Using location for routing decisions benefits from quick
> access,
> >> a
> >> info in the body, because proxies are not allowed to modify that. So
> you
> >> are
> >> > location-by-reference in a header.  If we don't get a good use case,
> I
> >> > think
> >> > 4. We proposed to explicitly allow hop-by-hop TLS security for
> location
> >> > when
> >> > to the routing-by-location database, but would obligate the proxy
> that
> >> did
> >> > with the parameter and registry entirely.  There was some list
> traffic
> >> in
> >> > will allow sip/sips and pres, not have any http(s) resolution text,
> and
> >> > not

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Jul 2006 21:36:57 -0400

> consensus is to disallow location-by-value in a header.

I repeat what I said before: There is a clear advantage to this  
method in terms of simplicity of operation and reliability. Thus,  
prohibiting it has no technical justification.

In addition, when outbound proxies are behind NATs, deploying a  
reference-based mechanism is far more painful and certainly less  
reliable since that proxy now has to put a LIS outside the firewall/ 
proxy. This is likely to be common in small and medium enterprise  
scenarios, where the enterprise, behind a NAT, has a nailed-up  
connection to some SIP service provider. This also happens to be the  
scenario where proxy-based location insertion is most likely since it  
works reasonably well with network-in-box solutions that combine  
access router, DHCP server and SIP server.

> doing the location based route to remove the location it uses for that

This only applies if there are two locations or a single DND location?

> traffic in
> proposal, we
> and not

I'm concerned about the implementation complexity of this approach in  
proxies. A SUBSCRIBE/NOTIFY adds another asynchronous operation to  
the time-critical forwarding path. This is also significantly more  
complex for proxies to implement than any of the other mechanisms,  
since they have to correlate incoming NOTIFY arrivals with pending  
messages, maintain multiple timers and worry about denial-of-service  
attacks. (A state exhaustion attack in a proxy would simply have the  
NOTIFY for the SUBSCRIBE take a few minutes, thus requiring the proxy  
to keep state for that duration. An attacker in an HTTP-based system  
can pull a similar trick, but it is somewhat easier to bound the  
permissible delay since it is a one-step operation.)

Needless to say, I believe that the security considerations section  
needs to discuss this.

Based on our measurements, the NOTIFY and SUBSCRIBE probably will  
each take as much effort as handling the INVITE, so that the call  
routing throughput of an emergency service routing proxy will be  
reduced by about 2/3. The same is true, to a somewhat lesser extent,  
for HTTP retrievals and to a larger extent for HTTPS retrievals.  
Thus, either solution is likely to be much more expensive than a data  
URL for the proxy-inserted case.