ECRIT IETF-69 23 July 2007 5:40pm to 7:50pm [Note: following notes are a compilation of two independent sets of notes, taken from sections as titled. Lines beginning with “>” represent the 2nd note-taker’s comments and there has been some attempt to properly slot them in sequence. –Roger Marshall, ECRIT Secretary] Meeting Chairs: Hannes Tschofenig Marc Linsner Provided general introductions and Note well: Announced Roger Marshall officially introduced as Secretary of ECRIT -- Agenda-Bash: General view was that most people did not require the amount of time allocated. -- Status of work group drafts: Ecrit-requirements draft is now in RFC editors queue Service-urn draft needs some revision after IESG comments > Marc - IESG Discuss service-URN-06 a number of comments > Jon - No comments are blocking progress of draft Security threats draft has some issues outstanding from IESG. Basically 2 comments have been made; looking as DoS for emergency responders, relating location dependability. Second issue is to do with confidentiality of service requestor and subsequent response. Service URN has 6 IESG comments. -- Proposing new milestones: October proposed for LoST and Mapping drafts December 07 for framework and phone BCP. Do we want to pick up location hiding? -- Announcement: Emergency services workshop to be held in Brussels Belgium October 30 to November 1. -- Liaison notice: Liaison received from ATIS (some time ago), nobody knows what to do with it. [Presentation Section] -- Presentation: LoST: > LoST: A Location-to-Service Translation Protocol http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/ Moderator: Ted Hardie Current status there was trouble with submission of document, so new version will be submitted soon. Updates:- ID attribute added errors clarified, error messages will only come back in 200 OK HTTP. Add a polygon profile. WG agreed to add shapes types circle, ellipse and arc-band to a new profile mandatory to implement in LoST. (James W agreed that this was satisfactory). > Proposed update additional profile to include circle, ellipse > Brian - question conversion and were it is done > Hannes - ? (missed comment) > James – pidf-lo just introduces two extra shapes so it may be worthwhile referencing this work > Ted This is the compromise solution and everyone is happy with it (incl. James) this will then go for WGLC after being submitted to the list. [end of presentation] -- Presentation: Framework, Brian Rosen > Framework for Emergency Calling in Internet Multimedia > http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-framework/ > http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-overview-00.txt > Moderator: Brian Rosen > Open issues Hannes not all issues need to be resolves e.g. location hiding/integrity could be done separately so the base document needs to be completed. All comments resolved except for Henning's. Some updates required to reflect maturity of LoST. Open issues: All open ecrit issues HELD references dereferencing location hiding location integrity How IMS will conform Hannes indicated that not all this stuff needs to go in it. Select what needs to be done and write extra stuff for later. eg: Put HELD and deref in the document, but not location hiding and integrity and IMS. Hannes indicated that these extra things are in the same bag as the unauthenticated access, which is not included in the list above. Brian believes that framework and phone-BCP need to come out last from the WG, since they need the details above. Hannes believes that we can get something out and then produce additions later. Location hiding, for example, will have its own location hiding document. James Polk agrees with Hannes in the interest of getting the document out. Hannes indicated 2 main issues came up on the list. Wants deployment scenario of SIP-Proxy inserting location and performing routing. Some comments, James W, Brian, Hannes and Jonathon R, result was that this is allowed, but the text in the document needs clarifying and a diagram needs to be added. > Brian - considers that the framework/bcp are the last documents out of ECRIT as they document how this works and to go to a RFC status then > Hannes - argues that they are orthogonal > Hannes - QoS how is this done is another, e.g., so this is just for the base protocol > Brian - can do it. > James - just going to second Hannes > Consensus to go for WGLC > Hannes - Two further issues need to be resolved [1] why can the SIP proxy communicate with the LIS and LoSt server? > James - need to support the pbx scenarios that can access the LIS/LoST servers directly and this should not prohibit this from happening > Brian - read out the text that takes care of the problem > Jonathan R - does not think that the text takes care of this information and it was agreed that it was not clear and would be taken care of [end of presentation] -- Presentation: Phone BCP, Brian Rosen > Best Current Practice for Communications Services in support of Emergency Calling > http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-phonebcp/ > Moderator: Brian Rosen Hannes suggested to reorganize the document. Brian would like to keep the document as it is, but to highlight the BCPs better and say who they apply to, and then produce table at the back as to what environments need to implement which bits. Put specific tags to allow requirements/sections to reference. General agreement was reached for this to happen. Spencer Dawkins mentioned that he was glad that authors were thinking about how to make requirements for each node in the network explicit. Adding extra data: "Call Info" like who was the carrier, sub name and address. James W raised concerns about the security aspects of putting this into a header and suggested that it be moved to a different document and addressed later owing to security considerations. Hannes was asking about emergency marking. James P apparently wrote a document about this. Apparently Jonathon R has written a draft that may apply to this topic. JR's draft was killed today, so this is now an open issue. Action: James W and Richard B and Steve Norreys and Barbara Stark to review Phone BCP. > Status no [version] change from last meeting > Doc at present is in the flow of the emergency call set up > Comments made that the phone, proxy servers etc are separated and have separate sections. > Hannes - add an annex to set out the suggestion but reference to the main text. > Is this annex to draft informative? > Use call info header so that info re caller is added and no XML data structure is specified. > Jonathan - must define the XML or else interoperability will not work. > James - Security constraints as to who can access/view it must be added to the XML specification. > Paul K - what prevents the UA from adding the header [Brian - Nothing] > Hannes - push this to the list > Hannes - Marking of emergency sessions Brian reference this out to draft but the draft was deleted out of SIP so it is an open issue. [end of presentation] -- Presentation: Resource Priority Namespace for ECRIT, James Polk Cut-off missed due to error in template. Provide indication in message for priority treatment. Brain R indicates that NENA wants this. Steve Norreys indicated that once you hit the ESRP then all calls have a high priority. > Steve N why is it needed once it reaches the emergency services boundary The example that James Polk indicated was that if a major disaster happened in some area then they may require even higher priority. James W indicated that this example should be added to the document. > James P what if a disaster happens [to] the PSAP network, then [what] action to be taken[?] Stu Goldman indicated that allowing the UAC to add the priority indicator was a good architecture even if it was not commonly used. Richard Barnes indicated that the falsification of RPH was an issue in the location hiding aspect and that this needs to be covered in the security considerations. Stu Goldman indicated that if RPH was set and the service URN was incorrect that the call should fail. This raised concerns throughout the room that emergency calls don't fail. Keith Drage indicated that there was an existing RFC addressing these security concerns and that this function is just extending that. Richard Barnes indicated that the mechanism in this document does not flag an emergency call, just a priority. James W indicated that if you have RPH without the service URN then the call is not an emergency and may be dropped. James P suggested that this may be true and required further investigation. … skip (notetaker at the mic) > James W indicated that if it reaches this point then it is already an emergency so what extra priority is required > James P - ? > Stewart Goldman indicated that this is needed > Janet packet cable indicated that it is needed > Approx quarter of the room read the draft 01 draft > All agreed with the SOS namespace. > Keith - Question on using existing priority > Richard B > Keith - do distinguish emergency calls from normal calls > James W - if no indication then emergency calls can be dropped as it cannot be distinguished from other calls > Jonathon R - service request URI would indicate that this is a emergency call [end of presentation] -- Location Hiding :- Hannes Tschofenig http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-location-hiding-requirements-00.txt Moderator: Hannes Tschofenig > Discussion of the requirements for location hiding based on the slides Introduction of the problems space. > James P - two types of information required for emergency call routing to psap and dispatching so the location is used for two function Marc Linsner asked [as to] where the notion of giving location away for free came from. Jonathon R indicated that nobody will pay for it specifically, so if you give it to the end-point it is free. … skip (at the mic) Jonathon R Location hiding needs to meet the requirements and business models of the callers. Brian Rosen agreed with this position in that it needs to be done. > James W, Jonathon R, Brian, all support this work Ted Hardie believes that we need an architecture that supports user control, and that we need the original ECRIT architecture, and not support location hiding. Ted believes that this option needs to be optional, or it will not pass and will not work, and the WG will fail. > Ted - does not want to build an idealistic version but still needs to have end user control and this cannot undermine this Hannes indicated that location hiding is an extension to the base architecture. It is used for areas where the base architecture cannot be implemented. … skip (at the mic) > Spencer D - So this will be the first requirement > Marc - if this is to difficult for the end user then this > Brian - does not think that this breaks the rules in the original > Jonathon - could give location psap that would route to psap 23 to give a non precise location info > James P - fundamental to GEOPRIV to not give misleading info and this is part of the work and so this should be separate set of RFC's to the framework discussed earlier. Hannes: Question to the group whether they would like to work on this subject. Strong support for doing the work. No objections. [end of presentation] -- IEEE 802.11 unauthenticated access discussion. … much debate both for and against. > 802.11u support of emergency calls > Slide set is a tutorial of where the IEEE is in their work on supporting emergency calls > So if a SSID supports emergency calls but the UE cannot authenticate itself to the network so it will advertise this and allow emergency calls. Mo security so link layer attackers could happen. > With public credentials not feasible but points out some methods for exchanging keys > Hannes - in order for the network to provide this functionality it must be able to identify that this session is an emergency session. Hence, the network needs to be application and/or content aware > Jonathan - Someone needs to able to get this unauthenticated emergency services scenario to work. It is very hard > James W - makes unauthenticated users illegal as in a number of countries > Jonathon - Need to make this work as this is not just a test case as it would be a useful > Jonathan Lennox - the end point is out of scope as it the wifi could do what they advertise that can do > Brian - PSAP operators don’t want accept unauthenticated calls Hannes: Question to the group whether they would like to work on this subject. Strong support for doing the work. A few objections. [end of presentation] [following listed presentation was not presented] * Proxy Authentication of the Emergency Status of SIP Calls http://tools.ietf.org/wg/ecrit/draft-barnes-ecrit-auth-00.txt Presentation: Richard Barnes