Subject: RE: [Geopriv] Geopriv for emergency calls

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 18 Nov 2003 14:40:40 +0100

hi brian, 

please see my comments/questions inline:

> At IETF58, I presented a short summary of issues of location for
> emergency calls (9-1-1 in NA, 1-1-2 in GSM, ...).  They are:
>   1) Emergency calls route based on location (e.g. what PSAP serves 
> 	you depends on where you are)
> 
> 	Therefore, location must be on first message (INVITE in SIP)
> 
>   2) There are 2 or more intermediaries between the origination and 
>      termination that need location to route; it's not end to end
> 
>   3) Post Dial Delay (e.g. rule processing time) is very limited 
>     (fraction of a second for 2 second PDD)
> 
>   4) Rules for retention, forwarding, and to some extent, accuracy 
>      are determined by local laws, i.e. RM is LR
> 
> The implications of this on the geopriv work is:
> 1) Choice of crypto is important, because and end-to-end
> mechanism is problematic, and compute resources, especially
> at the originating terminal (sip phone) is limited.

you argue that this message communication is not end-to-end. why do you
think that end-to-end security is then problematic?

i assume you would like to avoid asymmetric cryptographic algorithms.

does the originating terminal (sip phone) know which entity is going perform
cryptographic verification?

is it sufficient to protect the location object to the first entity (e.g.,
first sip proxy) only? is there are strong trust relationship between the
entities in the network which need to inspect location information for the
purpose of routing the call?

> 
> 2) It is not practical (or legal), for the originating user
> to specify the rules for e.g. retention, retransmission,...
> as they are governed by the destination or law.

sounds reasonable. do you want us to add some text about default rule
description for the emergency case into the geopriv authorization policy
document?

> 
> There is work ongoing in SIP/SIPPING and elsewhere to deal with
> emergency calls.  At the moment, it appears that phones will
> learn their location and report it when placing an emergency
> call.  At the meeting, I proposed:
> 
> a) SIP phones be required to implement S/MIME to protect
> geoloc data, but use of TLS or IPSEC should be used in
> an emergency call, so that intermediary routing elements
> (sip proxy servers) can route based on location.  We note
> that in many cases, the security associations may be established
> in advance, thus further reducing the delay, while maintaining
> reasonable authentication, integrity and privacy of location
> data

this sounds very useful for me. in order to protect the location object
against eavesdroppers it has to be encrypted. 
this needs to be considered. 

i think that it might be difficult to mandate s/mime protection everywhere
particularly since you might already protect sip signaling (or other using
protocols) already. considering this issue in light of the using protocol
might be useful. 

> 
> b) A default rule for emergency calls be specified in the RFC
> for the using protocol.  Emergency calls would reference this rule.

sounds good. 

ciao
hannes

> 
> I welcome your comments on this proposal.  
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Nov 2003 09:24:16 -0500

> cryptographic verification?

No - that's the whole point (unless you assume that all emergency call 
centers share the same private/public key pair, which is clearly not a 
good idea). You address the message to an abstract entity, but the 
recipient may, depending on your location, be any of thousands of 
emergency call centers, all operated by different governmental entities.

Redirection can solve some of these problems, but it does add 
significant delay if you have to traverse the wireless channel several 
times and transmit a large (signed) object across it or have to set up 
an on-demand TLS connection with the multiple round-trip times that 
requires.

(Redirection = contact locally trusted proxy that then tells you the 
identity and public key of the ECC, so that you can send e2e encrypted 
material. This assumes that there is a directory of such ECCs that is 
being made available to the public. This, unfortunately, may or may not 
happen; I'm working within NENA to convince people that they should, but 
calling this an uphill struggle is an understatement.)

> purpose of routing the call?

Depends on what you define by trust. You pretty much have to trust your 
outbound proxy, as it can probably just refuse to open the firewall for 
you and it needs to be able to inspect the destination address. It knows 
your network attachment point, so it probably has a good idea about your 
location in any event.

The outbound proxy will then likely contact some kind of proxy or 
redirect server that has knowledge of the geo-to-ECC mapping. While no 
such entities exist today in the IP arena, it seems reasonable to assume 
that they will be operated by either a government agency or a delegate 
(some private company or not-for-profit operating the service on a 
contract basis). In the PSTN, the model is similar, with the 'selective 
router' filling that role, operated typically by the ILEC in the US, on 
a PUC-regulated basis.

> this needs to be considered. 

Presumably channel security such as TLS can satisfy this need.