Emergency Context Resolution with Internet Technologies WG TUESDAY, March 21, 2006 0900-1130 Morning Session I ===================================================== Chairs: Hannes Tschofenig Marc Linsner Minute Taker: Spencer Dawkins Jabber scribe Ted Hardie: http://www.ietf.org/meetings/ietf-logs/ecrit@rooms.jabber.ietf.org/2006-03-21.html Slides are available at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 Agenda Bashing / Current Status (Chairs, 15 min) ------------------------------------------------------------ Interim meeting held Feb 1-2, minutes available on web page. Requirements document ready for WGLC after interim (started March 14 ), still updating issues list (see issue-tracker at www.ietf-ecrit.org), probably looking at another round of comments. Emergency identifier - work on sos-02 stopped; sipping-service adopted as a wg item. See: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-01.txt Mapping protocols - merging LUMP and ECON to LoST, stopping work on DNS-based mapping. Merged document at: http://www.ietf.org/internet-drafts/draft-hardie-ecrit-lost-00.txt Milestones updated after interim meeting. New milestones presented (see ECRIT agenda presentation file at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65) All milestone dates are WGLC dates. Rechartering text sent to lists for comments, not on our charter page yet. Agenda for today: Open issues in requirements - Roger Marshall Open issues in security threats - Tom Taylor Service URN - Henning Schulzrinne LoST presentation - Andy Newton Discussion on Future work Discussion of Emergency Authority to Citizen - Steve Norreys Architecture - Henning Schulzrinne Phone bcp - Brian Rosen Agenda bashing: James Polk also wants to talk about the "Analyzing ECRIT Mapping of a Location to an Emergency URI for Emergency Calling" draft. Requirements (Roger Marshall, 15 min) ------------------------------------------------ http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt Issues raised during WGLC Were able to resolve every open issue during the interim meeting - no logged issues remaining. Since interim meeting, have done rearranging and rewording, removed duplicates and overlapping requirements. Not sure "identifier" versus "dial string" is currently resolved in consensus text. ASP/VSP distinction still hanging around - These terms could probably be restated as "Service Providers". Henning - struggling with RFC2119 language in this document. Remove this from the current draft? Applications can implement or not implement based on recommendations. James - "must be implemental for the operator to use" is the real requirement. Tom - Security document has same issues - broke into three classes in that document. Stephen Kent - are you writing requirements for a protocol, or are you writing the protocol? Security Threats Document (Tom Taylor, 15 min) ----------------------------------------------------------- Document accepted as WG work item. draft-ietf-ecrit-security-threats-00.txt Document identifies threats to emergency identifiers. Based on phone BCP text. Paul - can call PSAP, but can't call anyone else? Jonathan - this isn't true. Issue is who expands the URI. Connect identify breaks here. Tom presenting threats to emergency identifiers, mapping. Mapping protocol can contribute to DOS attacks, etc. Major open issue - do we allow authentication/confidentiality, or require it? Jonathan - what do we do with authentication in both directions? Tom - these are emergency calls, have to let calls go through or not. Steve Kent - we do MUST for protocols, not for deployment - mandatory to use is never on the table. These are system requirements. SMIME can't do end-to-end security because there's no end-to-end PKI. Roger - as much as we hate it, people are going to charge for a mapping service and that needs to work. Tom - is this a security requirement or a protocol requirement? Roger - needs to handle proxy-to-mapping service requirement. Should this document be published as a standalone document or part of another one? Hannes - don't want to cut and paste entire drafts into another draft! Henning - don't repeat and reword requirements! Don't leave this in limbo - decide something now. Working group accepting this draft? Chairs encourage every one to read this document and comment. Rohan asks everyone to read and response. Jonathan has comments about understanding normative/informative document references - this needs to happen "Soon". If a reference disappears from earth, could you still build the function and have it interwork? Roger will work with Tom to integrate the text in the requirements document. A Uniform Resource Name for Services (Henning Schulzrinne, 15 min) --------------------------------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-01.txt Discussion of open issues Two open issues remaining - how to identify the call post-resolution, and server resolution. We have at least four use cases for proxy call recognition and resolution. Jonathan - the problem is that this assumes the proxy can know the location. Hannes - Henning is presenting a 3GPP architecture here. Keith - what if the phone moves? The recognizing proxy doesn't know its location any more. Hannes - could carriers raise their issues on the list? Keith - we do recognition in the end system, but it doesn't work 100 percent of the time. Steve Norris - location information is what's needed . Henning - this is not the architecture discussion Paul - how will anyone make rules that match dialstring encodings? End system may put route headers in the request. Henning - proxy recognition and proxy resolution deserves at least a warning. Jonathan - should say that we're breaking IETF protocols here if end systems don't recognize emergency calls. This architecture is fatally flawed and we should say so, and then fix itl Hannu - can use locally defined numbers (112, 911) and have them work. Henning - could we move along? This has nothing to do with the draft, and I'm not going to get to the draft if we keep talking. Keith - Proxy case isn't what I asked for. Are we being told that handets recognize calls so the network doesn't have to? No. Can we punt the "free calling for calls marked as emergency calls" issue? If outbound proxy does mapping the call always goes to a PSAP anyway. Need to make very clear that the URI points to a PSAP in the draft. Several ways to identify calls - need to pick one. Henning likes having one identifier in one place, but the problem is that this approach doesn't solve this problem. Penn - suppose identification fails. And then ... what do you do with the call? Henning - two possibilities - either you route the call as a normal call, or route it as an emergency call anyway. Paul - Accept-contact is the new INFO. Is there ever a time that this is an appropriate use of Accept-Contact? You're using SOS header in Accept-contact - is that even legal? (Voices say, "no"). We will punt on this problem? (Andrew says, "allocating PSAP IP range would be even worse than allocating PSAP domain")... Hannu - we had the same problem dialing emergency calls in other networks. Just route on an emergency call context. Jonathan - we did something with GRUU that might help - URI flag that says "routes emergency calls". Henning - why won't this make things worse? Other end is colluding with me. Jonathan - let you know that you don't need to do mapping because downstream element will. Brian - use remapping if you care, or punt if you don't care. That's a workable solution (maybe the only one). Keith - how do you know you have a valid set of route information? Tom - if there's no mapping information, you can't do remapping. This isn't an implementation bug, it's a hack. Hannes - need to keep going here. Jonathan - split this draft, focus on SOS URN registration with no protocol work. May put identification in wrong document, but maybe that's OK. Rohan - can we split the document? Jonathan - what does "redo mapping" mean? UA and proxy will always both do mapping? Henning - if a UA is capable of doing mapping, UA will always do mapping. A proxy which does special treatment looks at URI - is it a legal PSAP URL? Is it a new URL the proxy has not seen? If so, perform matching. Hannes - can Henning take this to the mailing list? Brian - no one is speaking for another alternative. Rohan - if a proxy can do no checking at all anyway... Hannes - we need text, let's move on. James - what was being mapped? PSAP URI or services URN? UA will always do LoST? Yes. Using DDDS, but there have been some changes recently. Mark - update RFC 3958 to include U flag, but those authors don't agree. Jon - what are advantages? Mark - regular expression matching. Andrew - point of S-NAPTR is that it's based on implementation experience, which really matters, and all we have to do is add U flag. Jon - use NAPTR and don't get it wrong? This may be a faster path forward. Rohan - Yes, we should do this, in the LoST document. Want to use LoST for non-emergency services. Is there a problem with moving this to LoST? All other protocols with DDDS mechanism define it in the protocol. Lawrence - do you really mean I flag on the end? I flag is optional. Please don't. It's dangerous. Two known open issues - marking (can be separated), DDDS needs NAPTR expert advice. LoST: A Location-to-Service Translation Protocol -------------------------------------------------------------- (T. Hardie/A. Newton/H. Schulzrinne, 30 min) http://www.ietf-ecrit.org/cache/draft-hardie-ecrit-lost-00.txt Current status, open issues and next steps Had three proposals, merged two of them into LOST. Looking at transport options now. LOST runs "whenever" (bootup, location changes, after time passes, at call time). Lots of work left, mostly mechanical. Complete schema, error/condition codes, transport mechanism selection, dialstring discovery, security considerations, IANA considerations, Internationalization considerations (or not), load balancing and service discovery. Jonathan - looks mostly good. Want to mention mutual-auth mode. Looking forward to next level of detail. Brian - when is next version coming out - soon? Had two detailed drafts, don't have details in one draft now. Henning - doing implementation in parallel. Rohan - have many small edits - is there one primary editor? Would like to have high- bandwidth proposal with 1-3 editors. Marc - accept as WG document? Lots of "yes" hums, no "no" hums in the room. Jonathan - and please don't change the name - LOST is great. Discussion about future work (All, 75 min) ------------------------------------------------------ Mapping Architecture (Henning Schulzrinne) ------------------------------------------------------ http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-mapping-arch-00.txt Henning: Is architecture/terminology acceptable? Need to track LoST draft, need to fill in some missing pieces Jonathan - think we need to do this, but not a priority right now - need to focus on how the parts fit together. Andrew - think this should be a priority - people coming into the working group are getting confused. Hannes: Include a proposed charter item for this? Hums in the room were to include it. Hannes: The group expressed interest in working on an ECRIT architecture document as well. draft-schulzrinne-ecrit-mapping-arch-00.txt focuses on the mapping protocol architecture. A few working group members expressed interest to work on a document that describes the larger picture. James - we need something that explains where we have been. Andrew - should be one document, we can combine to avoid overlap/conflicting documents. Hannes: Include a proposed charter item for this? Hums in the room were to include it. Best Current Practice for Communications Services in support of Emergency Calling ------------------------------------------------------------------------------ http://www.ietf.org/internet-drafts/draft-rosen-ecrit-phonebcp-00.txt . "There's all these drafts, what do I do?" - Guidance, not normative . Provides big-picture view of emergency calling . Have gotten some list comments . When guy who controls network, they can use any protocol they want - if you don't control the network, you need to tell people what the network expects. . Phones have AND between protocol requirements, servers have OR between protocol requirements . Jonathan - need greater clarity - vagueness in emergency calls is a bad thing. Need a minimum set of requirements, at a minimum - what's mandatory-to-implement? . Andrew - strike a balance here - use what your network attachment network expects. . Steven Kent - does PSAP want to know things about the phone? If so, we need SEC clue to get this information to the PSAP. . Hannes - why does the PSAP need to know the source of the location information? . Steven Kent - how unspecified can we be about the protocol used to provide this information, if the PSAP expects to use it? . Tom - don't think we're ready to write this document at this stage of the WG. Need meta architecture first, need to identify the minimum mandatory-to-implement functionality. . Ted - don't think self-reporting will be valid in many jurisdictions . Peter Blatherwick - very important document, maybe too important for a BCP . Hannes - IAB not excited about BCPs too early, but we can work on BCPs now. Who is in favor of working on this document within the working group? Most in favor, one hummed against. Authority to Citizen Communication (Steve Norreys) ---------------------------------------------------------------- How to inform citizens of an emergency situations (known - hurricanes, unknown - london tube explosion) . Can't tell people where to stay, or where to go, in emergencies. . Lots of service objectives listed in the document . Will send note with reference to the list for interested parties Analyzing ECRIT Mapping of a Location to an Emergency URI for Emergency Calling (James Polk) ----------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-events-00.txt . Have written five documents recently. . What happens if ECRIT query fails? "New Mapping Failure" response (4XX). . Maybe do INVITE to fall-back URI? . Andrew - are timeouts different from failures? Yes. . Options - Pre-mapping with DHCP? with SIP REGISTER? HTTP? SIP SUBSCRIBE? Could be with LoST...