Consolidated ECRIT meeting minutes in-line, following along with each presentation, inserted in chronological order according to best-efforts. Note-taker notation: [nt1]= Robert Sparks [nt2]= Matt Lepinski Add’l note: Only minor spelling changes made to the original submitted notes - where apparent. Consolidated by: Roger Marshall -------------------- IETF71 – Philadelphia, PA ECRIT - Emergency Context Resolution with Internet Technologies WG MONDAY, March 10, 2008 1520-1720 Afternoon Session II Franklin 1/2 RAI Track -------------------- -------------------- * Status Update and Agenda Bashing (Chairs) -------------------- [nt1]no changes requested [nt2]No bashes occurred -------------------- LoST Comments (Henning - No slides) -------------------- [nt2]Three kinds of comments from IESG review 1) Editorial 2) Lack of Clarity (e.g. security considerations, service area overlap) 3) Technical Questions related to Discovery - Comments posted to list. Reply to list if you have input - Should be resolved in a small number of weeks [nt1]Ted - there is still discussion around using input vs output of the UNAPTR algorithm Discussion [nt2]Ted: (on Discovery) - Currently discovery is either by external configuration or else via U-NAPTR - Sam in his review believes the U-NAPTR mechanism should use input to U-NAPTR instead of output (similar to SRV). This requires putting the U-NAPTR input into a PKIX cert - Problem scenario is where a single LoST provider is serving a large number domains. (e.g. All the enterprises in a metropolitan area point to a local government server). It is not reasonable to expect the local government to have every enterprise mentioned in its PKIX cert [nt2]Jon: - SIP had a similar issue and we decided to go with a separate PKIX cert for each virtual domain - Why can't the LoST client just query the local government directly [nt2]Ted: - Then you need to configure the client to know about the local government server and the client may move frequently - If what we're doing is really a problem, then U-NAPTR never should have been approved - Even in Sam's proposal, there is still a reliance on DNSSEC because that's the only mechanism available to deal with cache poisoning [nt2]Scott Lawrence: With the SIP model [use the input to U-NAPTR] you don't need to trust intermediaries. [nt2]Ted: I'm not looking for the authoritative LoST server for a domain, I'm looking for the caching LoST server that I was pointed to [nt2]Jon: I believe what Sam is proposing is as secure as DNSSEC, the only difference is what use-cases you support [nt2]Ted: At the very least, the security properties of Sam's proposal are no better DNSSEC + U-NAPTR [nt2]Jon: What Sam is proposing is more deployable than DNSSEC. However, I'm willing to stick with working group consensus and pound Sam on this [nt2]Ted: The kind of protections that DNSSEC provides are more necessary in other cases than in this case, and we need to deploy DNSSEC soon anyway. [nt2]Ted: There are 3 ways to discover a LoST server - Reconfiguration - DHCP knows about LoST and gives you the URI - DHCP doesn't know about LoST so it gives you the domain and you use U-NAPTR [nt2]Henning: If whatever we do isn't compatible with vanilla OPEN-SSL and requires "special" certs that you can't get from commercial CAs, this is a deal-breaker [nt2]Cullen: Everything works with standard certs if DHCP knows about LoST and gives you the LoST server name [nt2]Ted: What Sam is proposing requires new certificates and may even require a new PKIX extension. It is also still a deployability issue if you require the government LoST server to have a separate cert for every enterprise in the area [nt2]Brian: The definitive LoST server is hosted by the government but this is a small agency that won't pay for tons of certs. However, anyone will be able to provide a local copy of the LoST mappings [nt2]Cullen: Any library that you use will be able to give you back (externally) the cert coming from TLS. [nt1]Hannes - questions to the group: Who understood the problem being discussed Several hands - Should we stick with current U-NAPTR mechanism hands: 10 - Should we use Sam's input alternative hands: 0 Summary: favor to leave the document as is. comment from the mic-line: 95% of people who raised their hand saying they understood the problem wanted to stay with the current proposal ----------------- Framework and PhoneBCP (Brian - See Slides) ----------------- * Brian - Framework and Phone BCP status [nt1]Open issues [nt1]3-way call and use of relay [nt1]No disagreement with slides [nt1]Comments [nt1]Framework should talk about why you disable 3-way calls [nt2]Brian: - With regards to 3-way calls, the text is correct. If a relay is needed, it should be inserted before the call to the PSAP is established. We will describe this better in the next version. [nt2]Stu Goldman: Can you add text describing why you have this provision. (Namely, it is bad for the operator to lose control of an emergency call. e.g. due to a flash event.) Also, it seems like 3-way calls should be okay if they are done in such a way that the operator isn't put on hold. [nt2]Brian: But we also don't want cascading bridges. [nt2]Brian: - With regards to the Cell-ID issue, we need discussion with 3GPP to resolve this. (That is, Is this a problem with current documents as they exist today? Will it likely be a problem once the 3GPP documents are finalized) [nt1]Cell ID as local representation No disagreement with slides [nt1]Comments [nt1]Ted suggests liaison statements to start co-work w/ 3gpp [nt2]Brian: Another 2 weeks of working group last call. Get your comments in. [nt2]Henning: Can we get a "This is what we have found so far" list? We don't have an issue tracker. [nt2]Brian: So far, we only have the two issues that we just discussed. [nt1]Christer - MGCF R-RUI [nt2]Christer: Raises issue regarding service URNs in the Request-URI header and un-upgraded MGCF (PSTN gateway) that don't understand service URIs. [nt1]update on what 3gpp is doing [nt1]Comments [nt1]Brian/Hannes: we might need text describing what happens when a call hits a gateway that has no knowledge of service URIs [nt2]Brian: The ECSCF should know whether it's sending to an IP enabled PSAP or a PSTN gateway. The ECSCP should then "do the right thing". [nt2]Brian: The SOS service URI is targeting the furthest downstream element that understands emergency calls. [nt2]Hannes: Should we add some clarifying text? [nt2]Brian: Yes. This is analogous to the current i2 situation in the US [nt2]Christer; We don't want to prevent the PSTN gateway from knowing that this is an emergency call. The issue is just that gateways might be upgraded at different times. [nt2]Kieth: At the last Ecrit meeting we decided that priority and the service URI serve two separate functions. [nt2]Cullen: Is this documented in a draft? [nt2]Hannes: No [nt2]Henning: Brian's approach has configuration issues. It's not ideal but it should work in the long run. The text should encourage the correct behavior. Overloading the Resource Priority Header is very dangerous!! [nt2]Brian: There is always a problem when you have incremental upgrades. The only good solution is that the upgraded system should know about dumb down-stream elements. We shouldn't try to solve this in ecrit. [nt2]Henning: Christer, what is your proposal? [nt2]Christer: I don't have one. Just wanted to raise the issue for working group consideration. [nt2]Jonathon: Fraud issues make the use of other headers (besides Request-URI problematic). We'll have this discussion again tomorrow for UA-Loose-Route. [nt1]Hannes will pass this text to 3gpp as soon as Brian makes it available [nt2]Hannes: Let's capture the discussion as Brian suggested. Post this to the list and we can pass along to 3GPP. ----------------- Location Hiding (Richard - See Slides) ----------------- [nt1]James Winterbottom: Having a concrete example backing up the requirement for distinguishing emergency from non-emergency calls would help explain that its a MUST implement (support) vs MUST use kind of requirement [nt1]Henning: requirement to provide location to PSAPs should say something like "don't hide information" rather than "provide precise information". [nt2]James W: What about the use-case where no location at all can be provided? [nt2]Henning: There are really several sub-cases - Completely unavailable - Not available yet - Rough with precise later - etc [nt2]James W: Why is point #2 [on slide 4 "Basic Functional Requirements"] a requirement? Resource allocation or billing? [nt2]Richard: It's required for fraud mitigation. [nt2]Henning: This is required for policy by-pass as well as billing. (e.g., You normally can't call Cuba from a U.S. VSP, or you normally can't call anywhere because you haven't paid your bill) However, this is not a requirement in all scenarios. But a general solution should provide this. [nt2]Norris: Why does a PSAP need precise location? [nt2]Henning: The formulation is imprecise, but a PSAP needs the best technically available information for dispatch. [nt2]Ted: [With regards to slide 6] You're talking about contact URIs only and not full LoST with L-by-R? [nt2]Richard: Also service boundaries as well as contact URIs [nt2]Ted: Is the LoST server special-casing? [nt2]Richard: This idea hasn't be fully developed, but probably LoST is not special-cased. Although LoST may be proxied (via an entity with authorization to de-reference). [nt2]Henning: The end-point requires service boundaries, so that it is not completely in the dark with regards to re-querying. [nt2]James W: With L-by-R there is an issue with using my favorite LoST server as I roam. There would need to be discovery of the "special" LoST server. [nt1]Questions to the group slide (path forward) [nt2]Richard: So what is the path forward? [nt1]Brian: you can eliminate LbyR in LoST and LoST in LCP because of authorization issues [nt2]Brian: - L-by-R in LoST doesn't work because forest guides could send you to a random LoST server - Also verification is an issue with LoST in the LCP - The proxy solution would have a standardized signaling issue [nt1]Henning: let's build a checklist table of the alternatives against a shortlist of requirements (that may help avoid repeating list discussions to date) [nt2]Henning: Capture the requirements a bit better and then provide a systematic check-list: Yes/No/"Requires additional mechanism" Version -02 will have this table Send soft/hard requirements to the list [nt1]Jon: Capturing the ways we've decided are not good would be useful for future readers [nt2]Jon: People will do location hiding. Documenting the least annoying approach is worthwhile [nt1]Ted: if do-nothing is the popular choice, then change it to document why we do nothing [nt2]Ted: Add "Document and Do Nothing" to the list of paths forward [nt2]Polk: Will this be a BCP? [nt2]Henning: No, requirements and problem statement with some additional discussion [nt2]Hannes: Revise the document and then we'll make it a working group item [nt1]People would like to see the document revved to reflect these conversations before humming to adopt it as a WG item ----------------- Unauthenticated Emergency Communications (Henning - See Slides) ----------------- [nt2]Question: Is there a way forward if we avoid conflating the 3 issues discussed in the presentation? [nt2]Hannes: Re-spin this as Henning has proposed? [nt2] [nt1]Discussion [nt1]There was no objection to Henning's proposal to separate concepts as shown on slides -------------- Further Discussion -------------- [nt2]Hannes: Henning needs to re-submit the forest guide synch document as a working group item [nt2]Hannes: What about holes in service boundaries? [nt2]James W: There was no consensus. I'm happy if this is informational. It does not update LoST [nt2]Hannes: Henning and James [Winterbottom] will discuss this [nt2]Brian: NENA will not use Henning's mechanism to load things into LoST =============== end =============== --------------- a. raw minutes from R. Sparks below --------------- • ❑ ECRIT at IETF71 ▼ ❑ Status and Agenda Bashing • ❑ no changes requested ▼ ❑ Henning - update on IESG progress on LoST ▼ ❑ Ted - there is still discussion around using input vs output of the UNAPTR algorithm • ❑ discussion ▼ ❑ Hannes - questions to the group ▼ ❑ Who understood the problem being discussed • ❑ Several hands ▼ ❑ Should we stick with current U-NAPTR mechanism • ❑ hands: 10 ▼ ❑ Should we use Sam's input alternative • ❑ hands: 0 ▼ ❑ Summary: weak favor to leave the document as is. • ❑ comment from the mic-line: 95% of people who raised their hand saying they understood the problem wanted to stay with the current proposal ▼ ❑ Brian - Framework and Phone BCP • ❑ status ▼ ❑ Open issues ▼ ❑ 3-way call and use of relay • ❑ No disagreement with slides ▼ ❑ Comments • ❑ Framework should talk about why you disable 3-way calls ▼ ❑ Cell ID as local representation • ❑ No disagreement with slides ▼ ❑ Comments • ❑ Ted suggests laison statements to start co-work w/ 3gpp ▼ ❑ Christer - MGCF R-RUI • ❑ update on what 3gpp is doing ▼ ❑ Comments • ❑ Brian/Hannes: we might need text describing what happens when a call hits a gateway that has no knowledge of service URIs • ❑ Hannes will pass this text to 3gpp as soon as Brian makes it available ▼ ❑ Richard - Location Hiding ▼ ❑ Comments • ❑ James Winterbottom: Having a concrete example backing up the requirement for distinguishing emergency from non-emergency calls would help explain that its a MUST implement (support) vs MUST use kind of requirement • ❑ Henning: requirement to provide location to PSAPs should say something like "don't hide information" rather than "provide precise information". ▼ ❑ Questions to the group slide (path forward) • ❑ Brian: you can eliminate LbyR in LoST and LoST in LCP because of authorization issues • ❑ Henning: let's build a checklist table of the alternatives against a shortlist of requirements (that may help avoid repeating list discussions to date) • ❑ Jon: Capturing the ways we've decided are not good would be useful for future readers • ❑ Ted: if do-nothing is the popular choice, then change it to document why we do nothing • ❑ People would like to see the document reved to reflect these conversations before humming to adopt it as a WG item ▼ ❑ Henning - Unauthenticated emergency communications ▼ ❑ Discussion • ❑ There was no objection to Henning's proposal to separate concepts as shown on slides --------------- b. raw minutes from M. Lepinski below --------------- --------- Agenda --------- No bashes occurred -------------------- LoST Comments (Henning - No slides) -------------------- Three kinds of comments from IESG review 1) Editorial 2) Lack of Clarity (e.g. security considerations, service area overlap) 3) Technical Questions related to Discovery - Comments posted to list. Reply to list if you have input - Should be resolved in a small number of weeks Ted: (on Discovery) - Currently discovery is either by external configuration or else via U-NAPTR - Sam in his review believes the U-NAPTR mechanism should use input to U-NAPTR instead of output (similar to SRV). This requires putting the U-NAPTR input into a PKIX cert - Problem scenario is where a single LoST provider is serving a large number domains. (e.g. All the enterprises in a metropolitan area point to a local government server). It is not reasonable to expect the local government to have every enterprise mentioned in its PKIX cert Jon: - SIP had a similar issue and we decided to go with a separate PKIX cert for each virtual domain - Why can't the LoST client just query the local government directly Ted: - Then you need to configure the client to know about the local government server and the client may move frequently - If what we're doing is really a problem, then U-NAPTR never should have been approved - Even in Sam's proposal, there is still a reliance on DNSSEC because that's the only mechanism available to deal with cache poisoning Scott Lawrence: With the SIP model [use the input to U-NAPTR] you don't need to trust intermediaries. Ted: I'm not looking for the authoritative LoST server for a domain, I'm looking for the caching LoST server that I was pointed to Jon: I believe what Sam is proposing is as secure as DNSSEC, the only difference is what use-cases you support Ted: At the very least, the security properties of Sam's proposal are no better DNSSEC + U-NAPTR Jon: What Sam is proposing is more deployable than DNSSEC. However, I'm willing to stick with working group consensus and pound Sam on this Ted: The kind of protections that DNSSEC provides are more necessary in other cases than in this case, and we need to deploy DNSSEC soon anyway. Ted: There are 3 ways to discover a LoST server - Reconfiguration - DHCP knows about LoST and gives you the URI - DHCP doesn't know about LoST so it gives you the domain and you use U-NAPTR Henning: If whatever we do isn't compatible with vanilla OPEN-SSL and requires "special" certs that you can't get from commercial CAs, this is a deal-breaker Cullen: Everything works with standard certs if DHCP knows about LoST and gives you the LoST server name Ted: What Sam is proposing requires new certificates and may even require a new PKIX extension. It is also still a deployability issue if you require the government LoST server to have a separate cert for every enterprise in the area Brian: The definitive LoST server is hosted by the government but this is a small agency that won't pay for tons of certs. However, anyone will be able to provide a local copy of the LoST mappings Cullen: Any library that you use will be able to give you back (externally) the cert coming from TLS. ----------------- Framework and PhoneBCP (Brian - See Slides) ----------------- Brian: - With regards to 3-way calls, the text is correct. If a relay is needed, it should be inserted before the call to the PSAP is established. We will describe this better in the next version. Stu Goldman: Can you add text describing why you have this provision. (Namely, it is bad for the operator to lose control of an emergency call. e.g. due to a flash event.) Also, it seems like 3-way calls should be okay if they are done in such a way that the operator isn't put on hold. Brian: But we also don't want cascading bridges. Brian: - With regards to the Cell-ID issue, we need discussion with 3GPP to resolve this. (That is, Is this a problem with current documents as they exist today? Will it likely be a problem once the 3GPP documents are finalized) Brian: Another 2 weeks of working group last call. Get your comments in. Henning: Can we get a "This is what we have found so far" list? We don't have an issue tracker. Brian: So far, we only have the two issues that we just discussed. Christer: Raises issue regarding service URNs in the Request-URI header and un-upgraded MGCF (PSTN gateway) that don't understand service URIs. Brian: The ECSCF should know whether it's sending to an IP enabled PSAP or a PSTN gateway. The ECSCP should then "do the right thing". Brian: The SOS service URI is targeting the furthest downstream element that understands emergency calls. Hannes: Should we add some clarifying text? Brian: Yes. This is analogous to the current i2 situation in the US Christer; We don't want to prevent the PSTN gateway from knowing that this is an emergency call. The issue is just that gateways might be upgraded at different times. Kieth: At the last Ecrit meeting we decided that priority and the service URI serve two separate functions. Cullen: Is this documented in a draft? Hannes: No Henning: Brian's approach has configuration issues. It's not ideal but it should work in the long run. The text should encourage the correct behavior. Overloading the Resource Priority Header is very dangerous!! Brian: There is always a problem when you have incremental upgrades. The only good solution is that the upgraded system should know about dumb down-stream elements. We shouldn't try to solve this in ecrit. Henning: Christer, what is your proposal? Christer: I don't have one. Just wanted to raise the issue for working group consideration. Jonathon: Fraud issues makes the use of other headers (besides Request-URI problematic). We'll have this discussion again tomorrow for UA-Loose-Route. Hannes: Let's capture the discussion as Brian suggested. Post this to the list and we can pass along to 3GPP. ----------------- Location Hiding (Richard - See Slides) ----------------- James W: What about the use-case where no location at all can be provided? Henning: There are really several sub-cases - Completely unavailable - Not available yet - Rough with precise later - etc James W: Why is point #2 [on slide 4 "Basic Functional Requirements"] a requirement? Resource allocation or billing? Richard: It's required for fraud mitigation. Henning: This is required for policy by-pass as well as billing. (e.g. You normally can't call Cuba from a U.S. VSP, or you normally can't call anywhere because you haven't paid your bill) However, this is not a requirement in all scenarios. But a general solution should provide this. Norris: Why does a PSAP need precise location? Henning: The formulation is imprecise, but a PSAP needs the best technically available information for dispatch. Ted: [With regards to slide 6] You're talking about contact URIs only and not full LoST with L-by-R? Richard: Also service boundaries as well as contact URIs Ted: Is the LoST server special-casing? Richard: This idea hasn't be fully developed, but probably LoST is not special-cased. Although LoST may be proxied (via an entity with authorization to de-reference). Henning: The end-point requires service boundaries, so that it is not completely in the dark with regards to re-querying. James W: With L-by-R there is an issue with using my favorite LoST server as I roam. There would need to be discovery of the "special" LoST server. Richard: So what is the path forward? Brian: - L-by-R in LoST doesn't work because forest guides could send you to a random LoST server - Also verification is an issue with LoST in the LCP - The proxy solution would have a standardized signaling issue Henning: Capture the requirements a bit better and then provide a systematic check-list: Yes/No/"Requires additional mechanism" Version -02 will have this table Send soft/hard requirements to the list Jon: People will do location hiding. Documenting the least annoying approach is worthwhile Ted: Add "Document and Do Nothing" to the list of paths forward Polk: Will this be a BCP? Henning: No, requirements and problem statement with some additional discussion Hannes: Revise the document and then we'll make it a working group item ----------------- Unauthenticated Emergency Communications (Henning - See Slides) ----------------- Question: Is there a way forward if we avoid conflating the 3 issues discussed in the presentation? Hannes: Re-spin this as Henning has proposed? -------------- Further Discussion -------------- Hannes: Henning needs to re-submit the forest guide synch document as a working group item Hannes: What about holes in service boundaries? James W: There was no consensus. I'm happy if this is informational. It does not update LoST Hannes: Henning and James [Winterbottom] will discuss this Brian: NENA will not use Henning's mechanism to load things into LoST