From: Spencer Dawkins [spencer@wonderhamster.org] Sent: 11 November, 2009 11:35 To: Hannes.Tschofenig@gmx.net; Marc Linsner Cc: Roger Marshall Subject: My notes from ECRIT 1.1 ECRIT Marc is remote, Brian Rosen is remote, James and Henning aren’t able to join remotely… 1.1.1 WG Status Update (Hannes) Mapping architecture is now an RFC, four more docs in IESG processing. Cullen – in PhoneBCP, “individual INVITE has to have an offer” – why? Causes problems with H.323, etc. That’s a good question, nobody leapt to the mike and answered… Any update on IESG processing docs? They are on Cullen’s desk… framework and PhoneBCP have a couple of questions. Expecting these to go to IESG Last Call in next two-six weeks. All will be IETF Last Called – even Informational. How to proceed with PhoneBCP questions? Short of key participants here. Cullen will ping the list in next five minutes and see what happens. Emergency Services Workshop – Hannes wasn’t able to join, but Richard participated in last week’s workshop. Smallest we’ve had, first in Asia. Did standards analysis and heard from UK (is this right?) operators. Will we have more workshops? Either in Europe or the US, sometime this spring. No virtual interim meeting this IETF cycle, planning to have another one soon. 1.1.2 LoST Sync (Hannes) http://tools.ietf.org/html/draft-ietf-ecrit-lost-sync Goal: Presentation of the revealed deployment options Make the group aware of the issue and solicit feedback. People using different deployment approaches for LoST. Hannes is showing examples for Austria and Finland, but these are JUST examples. Can use LoST sync between forest guide and LoST server (shown for Austria), as well as between forest guides (between Austria and Finland). Conclusion on list was that source was sufficient to identify pointer to LoST server. Example is simple but realistic (didn’t include all of the boundary information, but that’s just for readability). Germany has only stage-two PSAPs which are directly addressable – may not want to expose that if you move to ECRIT. Document now reflects this deployment description and should be more readable now. Andy Newton – was there also something about LoST being incorrect? Hannes thought that we would use a different URI scheme, but there is no scheme for LoST itself – using source parameter is sufficient (as Andy proposed). No remaining plan to change LoST. Different between two servers that cover the same region being synced and a subordinate server being told what it’s responsible for – not sure both need to be in the same document and don’t think subordinate case changes information very often. Hannes says depends on countries, but outside EU, it’s more dynamic than Andy thinks. Plan for US is one big forest guide that summarizes the state forest guides. Andy thinks that we need to be very careful if the Nevada state server suddenly announces it’s responsible for a larger geographical area – can’t know if this is accidental (oops) or intentional (large-scale disaster). May want to confirm it, but want a way to automatically update the structure. Brian Rosen - US will have national -> state -> local but won’t use LoST for this. 1.1.3 Service URN Update (Henning, remote) http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00 Goal: Conclude the IANA registration policy proposal. Now published as RFC 5031 and defines service URN and registry, and two sub-services (sos and counseling). Each sub-service has its own rules for adding entries, but policy to add top-level is standards-action, and we now have proposals for top-levels that we don’t think we need standards-action for (it’s overkill). Change to expert review? Cullen – hard to give guidance to experts – if you have food.italian.pizza, is adding food.pizza ok? Where is a bar? Gets more and more complicated. APPS people want to see a lot more advice. Is there someplace that expertise about this exists and could be imported? Feels like a library science exercise. IESG would either say “no” or ask for more advice today. Paul Hoffman - APPS tried a decade ago, failed and ran away screaming – ask Larry Masinter for details. Cullen – APPS guys thought it was funny RAI didn’t even recognize the problem – we are clearly not the right guys to solve the problem! Finding pizza with LoST is fine; just need guidance on naming for non-emergency services. Recommendation is to find a group we can delegate to/steal from that has expertise. Start with Larry! 1.1.4 SOS Parameter (Milan, remote) http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-07.txt Goal: Draft was updated and generalized. Confirm approach by the group. Major change in -07 is that “sos” URI parameter changed to reg-type and can take values, and a “sos” value is defined for use in Contact header for emergency REGISTERs. Other reg-types can be registered as well. Recent AD comment – option tags discussed before and considered unnecessary? Document is important to 3GPP, on their priority list and will move quickly. Cullen is confused but thinks point is that UA can recognize that “emergency calls aren’t going to work” and tell user – if a UA doesn’t recognize this mechanism, how does it know that the mechanism won’t work? Tag the request and say “please REGISTER even if you wouldn’t allow me to do that ordinarily” – allowing the network to apply policy if it wants to. If the network doesn’t recognize the mechanism, network can’t apply policy. Hannu – no indication of “emergency call will work” – only that the UA can try. Cullen – just need text that clarifies that, but skeptical that people are going to be OK with that. Hannes – how is this making the situation worse? Cullen – not a fan of “didn’t make it worse”. Case I’m worried about is when UA adds this tag and registrar doesn’t support this at all, but tells the UA that the REGISTER works. Not a problem for 3GPP, because they’re going to support this, but other people may not support it and then emergency calls may fail even if REGISTER worked. Hannu – but if you don’t include the option tag, the same thing would happen. Critical point is what happens when you have an emergency call – if you set up the network to be aware of emergency calls, everything works, if you don’t, it’s going to fail anyway. Cullen – my question was answered about how the draft works. Now we can talk about whether we’re happy with the answer. Martin channeling Milan in Jabber – is the group OK with the changes made in this draft? That’s fine. 1.1.5 LOST Revision Based in Implementer Feedback (Hannes) How far do we want to go on fixing obvious bugs in the specification? Cullen – could you use the ERRATA process for this? Depends on how many changes, and how big. Had two different ways to indicate that a service substitution has taken place. Remove the warning element? Allow element to contain location of profiles that weren’t included in the request? Describe load balancing/alternate routing? Include contact info for error reporting? Martin – document doesn’t describe what a civic service boundary is or means – document is unusable, can’t use the ERRATA process to fix it, it’s too broken. Service boundaries can be very coarse – could come up with an algorithm that says “at least my country hasn’t changed”, that could be enough, but we don’t even say that today. Brian – don’t think there’s much wrong with civic service boundaries, but that may be because you don’t have mobile devices that get civic locations very often. We would go all the way down to house numbers in requiring a re-query. Martin – fine with that, we just need to give that advice in a document. Brian – agree – we are reading a lot into the document, writing something down would be great. Brian – if we’re not going to limit to minor changes, NENA would like to bring up two items from i2 validation database. When you validate, say “I recognize the location but it’s an alias, and here’s the real one” (Route 19/Perry Highway – PSAPs want to get the real one. Not actually an ERROR, just saying “don’t use that one, use THIS one”. Also return an error that includes a suggestion – mark fields that did match and make suggestions for fields that didn’t. You may get more than one suggestion. Martin – LoST is extensible. I agree with the idea, but why don’t we write an extension to accomplish that? Brian – sure, we could do that. Roger – extension is a good idea and we’re planning to write an extension draft. Hannes – branch out address validation into LoST validation and make document simpler. Brian will write a new draft for the two NENA suggestions if people think these are good ideas. Paul Hoffman – civic not an issue for mobile devices – but first responders do. Hannes – but that’s not the mechanism that they would use. Paul – that’s not what I see with policemen in my city on cell phones. Brian – we’re doing that in NENA privately, but we could bring this forward. We’re using the LoST server to route when we need to choose a PSAP with a different service URN so they can call police AND fire departments, etc. When agency wants to choose a responding agent, they use Computer-Aided Dispatch that has fancy algorithms, knows where units are, etc. Paul – hear what you’re saying but you may be assuming the optimal situation – that everyone is talking on their own networks, and my experience is that this isn’t always the case. Maybe this is a good time to fix this. Sometimes we have federal responders, they aren’t going to switch over. Brian – please bring comments to the list/send private e-mail about this – think we have satisfactory mechanisms without extending LoST. Roger – might be natural fit for Europe with consolidated PSAPs that distribute to responders. Cullen-the-Cisco-guy – we canceled internal development because the RFCs were going to be immediately revised – Both GeoPriv and ECRIT have this problem. Either stop sending stuff for AD review that’s wrong or stop tweaking things that are right. Hannes – we had implementations before the document was finished. Thanks for the feedback. 1.1.6 ECRIT Direct (Martin) http://tools.ietf.org/html/draft-winterbottom-ecrit-direct-01.txt Goal: Start architecture discussion Somewhat controversial on the mailing list… we’ll see how far we get today! We’re actually underspecified because SIP allows you to send calls directly to the other endpoint. Don’t rely on Route header, contact PSAP directly at the URI provided by LoST. Also adding a new mechanism for PSAP callbacks. Brian – is there a reason that you can’t use the Route header? Prefer that Emergency Services look just like PhoneBCP. Martin – no problem with that. Problem is outside regulatory domains, and without involvement of VSPs. Could discover forest guides ourselves. Callback: a.. Contact headers could be insufficient for callback. b.. Devides that allow callback REGISTER with ESRP using SIP Outbound. c.. No identity/credentials needed. Major concern is with security and hoax calls. Lots of discussion. Don’t have agreement of desired properties of any solution in this space. Identification (for retribution) and classification (for prioritization). Not sure how Bulgarian VSP gets trusted by my PSAP – maybe I get second-class treatment as a result. Some regions will demand this not be used. Brian – mischaracterized my objection – if you can’t make a regular call, you can’t make an emergency call, and you’re violating that invariant (at least in the US) – lots of experience with this, all bad. Martin – but that’s jurisdictional policy, and it’s not the only thing that matters. What about devices that I would never use to make a phone call? Brian – disagree – if you want to use a game console with an Internet connection, you’ve got a service with at least some credentials. Making an emergency call from a Playstation is fine but it comes through a service. There are PSAPs that are willing to allow unauthenticated emergency calls, but we use emergency registration for that, don’t need another mechanism for this. But you can make a call without an outbound proxy – you only need IP service. What are the security goals that Brian really has? Brian – plenty of ways to abuse emergency call systems, we can’t fix all of them, but we’re trying to avoid the problems we’ve had in the past. Devices usually won’t send SIP calls directly. Some services do have poor credentialing (a once-valid e-mail address). Can’t stop everything but don’t want to encourage bad behavior – tens of thousands of calls with no good calls when you allow unauthorized emergency calling. So the PSAP can recognize what comes through a VSP? Is there some authentication mechanism you’re thinking of? Brian – not trying to filter bad calls, trying to prioritize good calls. Not really great, but we recognize that we get better calls when we require a VSP on the path. Cullen channeling Castapella – the rest of NENA isn’t as concerned about this as Brian is. (Brian named who he’s talking to at NENA). Marc – have a little pushback here – we know people call 911 to show that a phone works when they are selling it. Brian says this goes along with PhoneBCP, but PhoneBCP says “use your normal call path when you make emergency calls”, and we’re violating that. Marc hasn’t seen any VSPs today that don’t control the application, and if I am starting a new application for the first time when I’m making an emergency call, that’s bad. We’re also adding a REGISTER responsibility for ESRPs that requires them to provide more processing horsepower, etc. and this is a huge DoS opportunity. John Ewell – large enterprises are going to be known to PSAPs, but smaller ones aren’t. If you accept that, what’s the difference between supporting small PBXs and allowing unregistered calls? Martin – this is providing an alternative to the normal callpath, and maybe that becomes a fallback when the normal callpath doesn’t work. We’ve talked about this a lot on the list, not sure we’ll make any more progress here. Hannes – agree. Not sure we’re in a position to make a decision about this topic. Brian – John’s point – PBXes do what PhoneBCP says, send on normal call path, and that’s through a carrier, and that’s what we want. 1.1.7 Unauthenticated Emergency Services (Dirk) http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access-06.txt Goal: Decide whether the described approach is viable or whether an approach like ECRIT direct should be taken. Document focuses on two aspects (what happens if you don’t have a VSP, and what happens if you don’t have credentials that allow network access). Dirk is focusing on unauthenticated network access today. Section 6 is new and describes this. Unclear whether anything can be said about this. How to indicate emergency during network attachment? a.. L2 indications (adding TLVs to wireless MAC messages, turning off L2 security over-the-air). b.. EAP-based indications (based on NAI or with a dedicated method) We use EAP in a lot of the relevant scenarios. L2 indications allow handling emergency calls at earlier stage but are L2 technology-specific. EAP isn’t dependent on specific access technology, and is integrated into authentication/authorization, but happens late if your problem is radio overload, and things like femto MAC-layer whitelisting conflicts with an EAP-based solution. Bernard has had a number of helpful comments on the mailing list – any others? Hannes – we’re all SIP guys and SIP guys don’t understand lower-layer authentication/authorization (by the time we get to SIP, this is all over). One problem is that we already have a lot of stuff deployed – don’t think about the open IETF network, think about the hotel asking for your credit card when you’re making an emergency call. Many regulators claim their requirements are technology-independent. We think some countries will require this, although things are going in the other direction. Steve McCann – we need feedback in this draft, because if we want to go down the L2 path, IEEE 802.11 needs to know and start working on this – if we pick EAP, dump it on EMU and it’s all in the IETF. Applies to WiMAX Forum as well. L2 work takes more time because there’s more impact on chipset vendors, etc. Do we just capture different approaches in this document, or do we make a recommendation? Brian – there are jurisdictions that require access for unauthenticated devices. I’m interested in solving this, just at a lower priority (“not right now”). 1.1.8 Data-Only Emergency Message (Brian, remote) http://tools.ietf.org/html/draft-rosen-ecrit-data-only-ea-00.txt Goal: This is a new document. Solicit feedback from the group. No human and no media – that’s how we’re different from a typical call. May be sensor-based. May not have a pre-established arrangement with the PSAP. Use CAP – has all the fields, used for similar purposes – but there’s no general agreement on CAP transport (ATOM, WEP, and other approaches in use today). Need relationship for subscribe/notify, and there is overhead involved here for things that happen almost never. Proposing to use SIP MESSAGE – standard CAP message, treated as normal SIP call in Phone-BCP. CAP message has “area affected”, not the same as GeoPriv shapes. Need location in SIP Geolocation. Need to talk with OASIS and CAP authors. Martin – are you concerned about multipart? What’s the shape problem? CAP gives you circles, etc. A lot more limited than geo, and doesn’t handle Civic location, etc. Just trying to copy fields from CAP into SIP header so that things will work. Randall – would you use something else to do things like surveillance video from a sensor network? Yes. 1.1.9 PSAP Callback (Milan/Henning) http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01.txt Goal: Make a decision about the solution approach We don’t have slides for this (Henning not here). Cullen wants to see a solution draft before chartering work. Hannu says 3GPP will delay their work because this is running late, so we have a little more time. You get an emergency call, PSAP calls back, would like to give preferential treatment (don’t block incoming calls) – how do we mark? How do we secure? More like PAID or more like Identity? Hannu – have requirement to suppress supplementary services for callbacks, so need to have them marked. 3GPP wants to use ECRIT but timeline isn’t lining up for Rel-9 and previous – will remove this and give ECRIT a bit more time to get this done. Cullen – two solution paths (generate token on initial call, or certificate trust anchor). Working group could decide to pursue either or both, or discuss forever, but we’re going to have to pick, and can’t charter a bunch of work while we’re discussing – can’t involve “the right’ security guys, for example, until we understand the high-level direction(s). Certificates not a problem, because only PSAPs need one. Take this to the list, or flip a coin? Hannes – can’t pick one because you make the other group unhappy. Need to hash this out on the mailing list. Martin – ask people to bring proposals? Current document is a little vague, need more detail to say “this one’s better”. Hannes – specific header fields don’t matter, high-level workflow is the part we need to nail down.