RE: [Geopriv] HELD and persistent TLS connections in emergency calls
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Geopriv] HELD and persistent TLS connections in emergency calls



The two other TLS sessions (actually there are more) are endpoint to proxy
and proxy to ESRP (the ESRP will have connections to the PSAP and the PSAP
to the call taker.  The ESRP may have one or more ESRPs in the path to the
PSAP).  All of those will normally have persistent TLS connections because
there will be occasional traffic on all of them.

Of course every proxy will not have persistent TLS connections to every
ESRP.  It will only keep connections to ESRPs it regularly deals with, which
I assume would just be experiential based on traffic.  The horsepower on the
proxy to proxy connections makes the cost of the TLS establishment smaller
than on an endpoint.  The statistics for call completion time will be fine
if this connection caching mechanism works.

The LoST connection is somewhat more interesting.  I think the TLS
resumption mechanism in 4507 (thanks all for the reference, I think that is
the answer to the original question) will work here.  At one point we were
wondering about if we needed the same level of security since there was no
identity information in the LoST query, but I think in practice that a query
from a random endpoint to LoST could be assumed to be with its own location,
and thus probably in need of privacy.

That, of course, is an ecrit question, which is why I didn't raise it in the
original email.  I assumed we would use the same solution.

Brian

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom at andrew.com]
> Sent: Friday, September 14, 2007 6:16 PM
> To: Henning Schulzrinne; Stark, Barbara
> Cc: GEOPRIV
> Subject: RE: [Geopriv] HELD and persistent TLS connections in emergency
> calls
> 
> It is unclear to me at least why we are so worried about the potential
> 500ms to get setup the location session, when there are at least 2 other
> TLS SIP sessions to be established, plus a LoST connection from the
> call-server to check the authenticity of the destination as well.
> 
> This seems somewhat moot since without valid location you are either not
> going route at all, or you are going to misroute.
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
> > Sent: Saturday, 15 September 2007 7:57 AM
> > To: Stark, Barbara
> > Cc: GEOPRIV
> > Subject: Re: [Geopriv] HELD and persistent TLS connections in
> emergency
> > calls
> >
> > This may be (barely) true for DSL, but is probably not a safe
> > assumption for 802.11. On the other hand, 802.11 location isn't all
> > that interesting unless there's triangulation, since everybody will
> > get the same (obvious) location of the AP.
> >
> > On Sep 14, 2007, at 2:22 PM, Stark, Barbara wrote:
> >
> > > I strongly suspect that LIS operators would balk at the idea of
> > > maintaining persistent TLS connections for this. The threat of
> > > potential
> > > attack within a tightly controlled access network has not been
> > > proven to
> > > be sufficiently probable to warrant the added expense. Possible,
> yes.
> > > But there is nothing to show that it's probable. I think it's more
> > > likely that someone gets a Trojan on their device that captures the
> > > location and sends it out, than it is likely that the device to LIS
> > > communication is sniffed.
> >
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv at ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
> 
> --------------------------------------------------------------------------
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------------------
> ----------------------
> [mf2]
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv



_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.