2.7.4 Emergency Context Resolution with Internet Technologies (ecrit)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27

Chair(s):

Hannes Tschofenig <Hannes.Tschofenig@siemens.com>
Marc Linsner <marc.linsner@cisco.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:

General Discussion: ecrit@ietf.org
To Subscribe: https://www1.ietf.org/mailman//listinfo/ecrit
Archive: http://www.ietf.org/mail-archive/web/ecrit/index.html

Description of Working Group:

In a number of areas, the public switched telephone network (PSTN) has
been configured to recognize an explicitly specified number (commonly
one that is short and easily memorized) as a call for emergency
services.  These numbers (e.g. 911, 112) relate to an emergency
service context and depend on a broad, regional configuration of
service contact methods and a geographically-constrained context of
service delivery.  These calls are intended to be delivered to special
call centers equipped to manage emergency response. Successful
delivery of an emergency service call within those systems requires
both an association of the physical location of the originator with an
appropriate emergency service center and call routing to deliver the
call to the center.

Calls placed using Internet technologies do not use the same systems
to achieve those goals, and the common use of overlay networks and
tunnels (either as VPNs or for mobility) makes meeting them more
challenging.  There are, however, Internet technologies available to
describe location and to manage call routing.  This working group will
describe when these may be appropriate and how they may be used.
Explicitly outside the scope of this group is the question of
pre-emption or prioritization of emergency services traffic. This
group is considering emergency services calls which might be made by
any user of the Internet, as opposed to government or military
services that may impose very different authentication and routing
requirements.

The group will show how the availability of location data and call
routing information at different steps in session setup would enable
communication between a user and a relevant emergency response
center. Though the term "call routing" is used in this document, it
should be understood that some of the mechanisms which will be
described might be used to enable other types of media streams. Video
and text messaging, for example, might be used to request emergency
services.

While this group anticipates a close working relationship with groups
such as NENA and ETSI EMTEL, any solution presented must be useful
regardless of jurisdiction, and it must be possible to use without a
single, central authority.  Further, it must be possible for multiple
delegations within a jurisdiction to be handled independently, as call
routing for specific emergency types may be independent.

This working group cares about privacy and security concerns, and will
address them within its documents.

Goals and Milestones:

Apr 05  Informational RFC containing terminology definitions and the requirements
May 05  An Informational document describing the threats and security considerations
Aug 05  A BCP describing how to identify a session set-up request is to an emergency response center
Aug 05  A BCP describing strategies for associating session originators with physical locations
Aug 05  A BCP or Standards Track RFC describing how to route an emergency call based on location information
Nov 05  A BCP describing how to discover the media stream types an ERC supports

No Current Internet-Drafts

No Request For Comments

Current Meeting Report


Emergency Context Resolution with Internet Technologies WG (ecrit)

TUESDAY, August 2 at 1030-1230
==============================

CHAIRS: Hannes Tschofenig <Hannes.Tschofenig@siemens.com>
Marc Linsner <Marc.Linsner@cisco.com>


Scribe:
- Tom Taylor
- Hanns Juergen Schwarzbauer
- Martin Thomson

AGENDA:


Agenda Bashing / Current Status
-------------------------------

Chairs

http://www.ietf-ecrit.org/IETF63/IETF63-Agenda.ppt


Requirements for Emergency Context Resolution with Internet Technologies
------------------------------------------------------------------------

Roger Marshall
http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01.txt

http://www.ietf-ecrit.org/IETF63/IETF63-Requirements.ppt

Moved security related requirements to the new security draft allocated BCP items and removed them from the previous draft. cleaned up many requirements (see mail 5/18/2005); includes a summary of changes contributions from various sources (Linsner, Schulzrinne, Polk) 114 + changes submitted by Polk.


Question from Jonathon Rosenberg about the identification of an emergency message - does this apply to all nodes in the message path? Point was that all nodes need to have this ability. Henning recommended that this has two motivations - the call handling in general (both before and after mapping, as recommended by JR) and the mapping requirement. Henning suggested that a split of the req. might be necessary.

Discussion on R5, comments on the should/must strength of this req. Discussion also about limiting the number of nodes that are involved in the emergency call. James Polk suggested that this was a goal. R Mahy suggested that this might involve a tradeoff that might be a goal, agreement from James Polk and Henning Schulzrinne. Rog Marshall suggested BCP, Henning thought otherwise - this is still a design goal that might need to be collected into a section of a document - Richard Stastny suggested that the words MUST and SHOULD are used for this.

Steve Norreys - the definition of minimum connectivity was requested and agreed to be defined.

On setup delay - Henning recommended that a setup delay figure be included, if only for an order of magnitude. Comments from James Polk that 2 seconds is the point where callers start hanging up. Brian thought that 2 seconds should be the goal. Comments that too stringent requirements might add engineering constraints from Tom Taylor. James Polk suggested that ECRIT might be able to provide some assistance in reducing time. Rohan Mahy suggested that this was actually a requirement, not a goal. Hannes Tschofenig thinks that the entire discussion is somewhat artifical since many factors that contribute to the entire emergency call latency cannot be influenced by the work in ECRIT.

James Polk suggested that the renumber might be a little premature, since mailing list archives would not match with the document. Agreement that this might be best before the final version.

Jon Peterson suggested that we don't want to introduce constraints on the conveyance of location information that would affect non-emergency cases.



Security Threats and Requirements for Emergency Calling
-------------------------------------------------------

Hannes Tschofenig
http://www.ietf.org/internet-drafts/draft-tschofenig-ecrit-security-threats-01.txt

http://www.ietf-ecrit.org/IETF63/IETF63-Threats.ppt

Hannes asked for help in creating this document and that this is already behind schedule.

Tom Taylor raises his hand.

The content of the document was already discussed in the interim meeting. Interim meeting slides can be found at: http://www.ietf-ecrit.org/Interim2005/MeetingMinutes.html

Progress on this document needs to be made, we are already behind our milestones
Most attacks lead to Denial-of-service. some security issues relevant for the “big Picture” are out of scope for ecrit
Hannes recommended that the document needs to be cleaned, with some parts moved to other documents or removed.

An IRIS schema for Emergency Service contact URIs
-------------------------------------------------
Andrew Newton

http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-02.txt

http://www.ietf-ecrit.org/IETF63/IETF63-IRIS.ppt

Andrew provided background information on the IRIS-based protocol. ECON based on IRIS rfc3981, It’s a simple request/response protocol using XML

Andrew points to section 3.2 of the draft where the different service types are described. This issue was raised during mailing list discussions.

Henning suggested that the division of the service types into function/area/target might be a little too much to place onto the user. Also that the dispatch decision should not be placed on the end user.
Brian Rosen suggested that at most a list is easily navigable, that the structure proposed is too complex for a user in a crisis scenario - more likely a single number is reasonable.

Steve Norreys suggested that this sort of information is not likely to be useful in the first instant, so this isn't a requirement in a mapping protocol.

Richard Stastny: This issue is independent of the nature of the proposals and something that needs to be solved.

Andrew: The work on the proposals reveal these types of problems and are thus useful to some degree.

Andrew talks about database replication and indicates that this is outside the scope of the working group.

Henning suggested that database replication have a standard way so that multiple interoperable implementations can exist. AN suggested that this isn't well enough understood currently; the problem exists in other protocols the past (DNS, LDAP); suggested that this is out of scope.

Andrew talks about object signing. He mentiones that it is not quite clear what the benefit is.

Brian Rosen suggested that fraud is a big problem, so knowing that a call is suspect is valuable, so signing may still be useful.

Hannes points to the security discussions and the open issue whether channel security betwen two neighboring nodes is sufficient to address all the threats.
RM suggested that a validation might either take time, or can occur at the same time as the call (also that channel security requires the same infrastructure as object signing).

Hannes Tschofenig suggested that the cost of cryptography needs to be low, so that it does not offer a barrier to completing the call.

Roger Marshall suggested that the cost before establishing this call is zero, but that the cryptography is later useful.

Brian Rosen suggested that channel security might need to be established before a call.
Henning Schulzrinne mentioned that object signing might have application in non-time-critical situations, such as with MSAG validation.

Hannes Tschofenig pointed out that the security model should be investigated to keep a balance between possibility of fraud and usability.


Location-to-URL Mapping Protocol (LUMP)
---------------------------------------

Henning Schulzrinne
http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-lump-00.txt

http://www.ietf-ecrit.org/IETF63/IETF63-LUMP.ppt

Henning talks about caching.
Andrew has some doubts about caching model.

Caching query - answer is that caching is no different to caching in general, except that an expired cache should be used in the absence of an authoritative value.

Andrew: MSAG only applies to the US.

Henning: a check might be a good thing to do.

Andrew: wanted to avoid an operational requirement on a pre-event check.

Conclusion on caching - too much - will take up on the list.

Patrick Faltstrom - two parts to this protocol. How this works is very similar to X.500. This needs to be reviewed with APP group. General comment extends to all of these protocols and how the issues of distributed databases are managed and implemented.

Jonathan Rosenberg - there are two components to this proposal: query and the back end are different. Back end might be better left out of scope for the short term.

???: things like management and administration need to be considered and ECRIT must decide if they are in scope for this WG.


Emergency Call Information in the Domain Name System
----------------------------------------------------

Brian Rosen
http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-02.txt

http://www.ietf-ecrit.org/IETF63/IETF63-DNS-SOS.ppt


MT: non-hierachial nature of civic addresses.

Brian Rosen: delegation can manage this.

Patrick Faltstrom : why does this blob have to be a civic address? BR: it is clear to a user what it is.

Roger Marshall: this is a reversible transform.

Andrew: you might need to provide a tree with nulls in certain places. BR: build a tree with nulls where necessary.

Andrew: geo - how does it work. BR: polygons exist at a certain level.

Jonathan: problems with searching - DNS doesn't do searching. BR: allow a query to level X to provide a list of pointers to levels below. This allows searching of the next level down from a level that works.

Bernie H: what happens with same names that exist in different areas.

Olafur: how does geo work. BR: need an example.

Andrew: question on misspells. BR: Need to clarify that searching is only for validation.

Jonathan: carrier considerations? Will you consider allowing carriers to operate their own root servers?
Brian Rosen: <laughs>


A Uniform Resource Name (URN) for Services
------------------------------------------

Henning Schulzrinne
http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-service-00.txt


http://www.ietf-ecrit.org/IETF63/IETF63-URN.ppt

HT: moved discussion to the list due to lack of time.



----

James Polk: requires a hum on the requirements document becoming a a WG item:

Hannes: hum for working group document -> result WG document

James Polk: asks for comments and input on the SIP location conveyance document.

Slides

Agenda
ECRIT requirements update
Security Threats and Requirements for Emergency Calling
Emergency Contacts (ECON)
Location-to-URL Mapping Protocol (LUMP)
draft-rosen-dns-sos-02
Service URN