Last Modified: 2005-06-27
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 |
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. |