Subject: RE: [SIP] Re: Location information

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Feb 2001 13:04:25 -0000

See below.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Rosen, Brian[SMTP:[email-masked]]
> Sent: 	05 February 2001 17:01
> To: 	'William Marshall'
> Cc: 	[email-masked]
> Subject: 	RE: [SIP] Re: Location information
> 
> The problem that location presents that is different from the 
> privacy draft (unless I missed it) is that an emergency call must
> yield location information.  There is not an option for the user
> to suppress this, by law. 
> 
While the current privacy draft identifies that a user requesting "full"
privacy will receive this, I do not believe it is true. The current PSTN,
ISDN and mobile network service definitions all provide for some special
users (normally law enforcement agencies or emergency attendants) who have
access to this information no matter what the anonymity aka restriction
parameters indicate. I think the privacy draft needs to identify that
certain categories of user will exist that override the anonymity setting,
and that this is a "national option" of whatever the IETF equivalent of such
terminology is.

>  The path by which a user might connect
> to an emergency center cannot be pre-arranged.  I believe that it
> will take creation of a cryptographically secure infrastructure
> to allow such a system to have the desired property that the user
> can control location information, but when required it can be
> securely delivered.
> 
> I also think that location is not an "all or nothing" kind of
> thing.  The privacy draft presupposes that the world is bifurcated
> into trusted and untrusted domains, and privacy is secured
> when venturing into an untrusted domain.  This is not the behavior
> I really want. The desired behavior I want is:
> 	Accuracy (precision) of location is variable
> 		I may want to give some people precise information, others
> 		less precise.  There will be multiple levels
> 	Time (and motion) variability - if I am mobile, then where I
> 		am changes over time.  I need to express this somehow,
> 		but I also need to control it (not everyone can be told that
> 		I am mobile)
> 
This will vary between different services. For emergency calls, the current
location at the time at which the INVITE was sent is probably sufficient.
Location information in other protocols does include both accuracy and
velocity indicators, if such are required. Other services may require a more
continuous update of location - at some point this ceases to become
something that the SIP protocol should provide and becomes something that
should be in a separate media stream. Any views on where this breakpoint is
reached?

> What we learned in the spatial effort is that the whole location thing
> is more complex that you would like it to be, and it is hard to get
> an implementable subset that has enough functionality to be interesting.
> 
We could end up here building something that does everything, but is over
complex.

I would note that we have two potential mechanisms to cater for this:

i)	the same location could be repeated in a request, each intended for
different service capabilities and with different levels of accuracy. One of
the proposals is to repeat the Remote-Party-ID header. Thus a highly
accurate location could be propagated with the request for emergency calls,
and a somewhat more general location could be propagated to a server
providing location based services.

ii)	the final proxy before a untrusted hop is reached could reduce the
accuracy of location information.

I am not sure how we would go about specifying this behaviour generically
for all identifiers. It could be done for certain identifiers in an
application specific manner.

> We also learned the difficulties in reaching consensus on issues that
> involve privacy.
> 
> Brian
> 	
> 	
> 	
> 
> > -----Original Message-----
> > From: William Marshall [mailto:[email-masked]]
> > Sent: Monday, February 05, 2001 11:40 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [SIP] Re: Location information
> > 
> > 
> > Brian,
> > 
> > It seems that the privacy draft faces up squarely to the privacy
> > concerns.  The draft already deals with all the regulatory 
> > requirements
> > about verification of identity, hiding of identity, etc.  The security
> > implications of knowing who you are are just as daunting as knowing
> > where you are.  In some places regulations already cover 
> > location info,
> > and the framework in the privacy draft deals with them.
> > 
> > As with the subscriber identity - the UA may insert it, and may
> > demand (via a tag and a Proxy-Require) that it be kept private.
> > The proxies may verify the identity, and mark it verified, or mark
> > it unverified, and must delete the information if privacy was 
> > requested.
> > The procedures are all there in the privacy draft, and just need
> > some minor extensions to handle multiple identity types, and 
> > per-identity
> > privacy requests.
> > 
> > The previous efforts (spatial) generated a string giving location
> > information.  Sip uses "name-addr | addr-spec" everywhere, which
> > includes a display-name string; however a URL format would be nicer.
> > I was sure I had heard about a URL format with this information, but
> > can't find any reference to it.
> > 
> > Bill Marshall
> > [email-masked]
> > 
> > -----original message-----
> > From: "Rosen, Brian" <[email-masked]>
> > Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft)
> > Date: Mon, 5 Feb 2001 10:44:54 -0500
> > 
> > There was an effort started several IETFs ago to define a PROTOCOL
> > to exchange geographic location.  That was shot down.  There is still
> > a low level effort to define a format for exchanging such information.
> > 
> > Before starting another effort, you might want to look at the prior
> > work (spatial).  You also MUST forthrightly face up to the privacy
> > concerns that have stymied other efforts.  The security 
> > implications of
> > knowing where you are can be VERY daunting, and in general discussions
> > on the issues have yielded more problems than answers.'
> > 
> > Brian
> > 
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to [email-masked] with
> > "subscribe sip-implementors" in the body.
> > 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to [email-masked] with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 6 Feb 2001 08:18:15 -0800 (PST)

> and that this is a "national option" of whatever the IETF equivalent of such

   Ick. This sounds like just the kind of thing that
   _shouldn't_ be handled at the protocol level, but
   instead at the service deployment level with the
   necessary agreements. Why can't the UAC look at
   the INVITEE's identity to determine if it wants
   to give out its identity after all? Why can't you
   make the proxy log INVITE's with calling anonymity
   requested and then the cops can get it out of the logs
   if required?

		Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 06 Feb 2001 15:36:39 -0800

> and that this is a "national option" of whatever the IETF equivalent of such

There is no equivalent, since there are no national IETF standards.
Anything that relies on end systems "being nice" (i.e., doing things
they have no interest in doing) is per definition doomed in the Internet
that we know. Thus, we can assume that devices will provide accurate
information when making a 911 call (since the end system can easily know
that this is an emergency call), but if law enforcement has the illusion
it can rely on that on other calls, they need to find a different
Internet to play in. Should a proxy want to enforce or insert it, those
users that are so inclined will find a different proxy.

> > can control location information, but when required it can be

I don't see this as a problem if we can arrange for an end-to-end public
key for PSAPs (or one of the copies of the entity that routes to PSAPs)
stored in end systems.

> should be in a separate media stream. Any views on where this breakpoint is

This seems like a SUBSCRIBE/NOTIFY operation until the request rate
reaches some threshold. I don't think that there is a hard threshold,
since this depends solely on the resources one wishes to expend on this
and with end-to-end notifications, the effort for "the network" isn't
all that large. I would guess that most would agree that 10 msg/sec is
probably excessive (and calls for a media stream) and that one
message/minute is probably ok, but we'll differ on the points in
between.