Emergency Context Resolution with Internet Technologies WG

MONDAY, November 7, 2005
1300-1500 Afternoon Session I
=====================================================

CHAIRS: 

   Hannes Tschofenig 
   Marc Linsner 

Minute Taker:

  James Winterbottom and Nadine Abbott
 
  Jabber Log by Ted Hardie and Andrew Newton:
  http://www.xmpp.org/ietf-logs/ecrit@ietf.xmpp.org/2005-11-07.html

Slides are available at:  
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64
or at 
http://www.ietf-ecrit.org/IETF64/


AGENDA

 o Agenda Bashing / Current Status (Chairs, 15 min)

http://www.ietf-ecrit.org/IETF64/IETF64-ECRIT-Agenda.ppt

Hannes Tschofenig opened the discussion with a status report on the milestones for the WG. Although good discussions have occurred on the list server, we are behind on the projected milestones.  Hannes suggested a list of tools that could be used to bring discussions to closure.  May need to have conference calls, an interim meeting, etc

Brian Rosen commented that time is not allocated on the agenda to discuss the proposed mapping solutions.  This was acknowledged, and underscored the need for interim calls/meetings.

Interim meeting is being planned for January.

Brian Rosen had concerns about the agenda in that no agenda time had been allocated to discuss solutions documents of which there have been several provided.
 


 o Open Issues in the Requirements (75 min) 

   
   o Open Issues in the Requirements Document (Roger Marshall)
   ========================================
   
   draft-schulzrinne-ecrit-requirements-01.txt

  Presentations are available at: 
http://www.ietf-ecrit.org/IETF64/IETF64-ECRIT-Requirements.ppt

Roger Marshall proceeded to go through a number of the open action items 

During the discussion of the requirement for civic location validation Brian Rosen indicated that this was an absolute requirement and critical to be resolved within ECRIT to meet NENA needs. He indicated that all the proposed solutions at this time could meet this requirement.

Henning: shouldn’t make artificial separation between protocol and architecture. Useful to distinguish: 
• protocol must support
• implementer must implement
• user must use.

Ted Hardie:  Need to be able to validate addresses.  Need to be able to confirm that an address can be mapped to a URI.  Would we be satisfied with a simple Yes/No response?  Mapping may succeed even if the details of the street, for example, are not correct/valid.
Brian Rosen:  Actual requirement is that address can be recognized in the jurisdiction.  Can get that result by using mapping protocol.
Andy Newton:  Need to understand the difference.  Ought to have more wording around when validation ought to occur.
Brian Rosen: Will send text to clarify.

Rohan Mahy indicated that the requirement may be worded by stating that the mapping function protocol must be capable of supporting civic location validation.


Requirement MA.9: Traceable resolution
--------------------------------------

Discussion regarding whether the LCMS needed to be authenticated, what that meant, and how it would be managed.

Rohan Mahy suggested that two issues where at play:

1)     Knowing who provided the mapping information

2)     Being able to prove who provided it.

Henning suggested that the provable component should move to either the security section of the document, or out into the threats document.

 

Rohan Mahy agreed to provide Roger some new text for this requirement.

 
Henning Schulzrinne:  This is a discussion for the security document, not for the requirements document.  Requirement is necessary, but shouldn’t imply mechanism.
Resolution: If there is determined to be a security requirement, it will be added to that document.

Additional issues will be added to the tracker, e.g.,
•	Add seekers to requirements
•	New requirement around testing.

Brian Rosen: Commented that some of the NENA requirements have not been included or added to the issues tracker.  Brian agreed to add them to the issue tracker.



LCMS
----

Marc Linsner: Two issues need to be added: 
1) LUMP doesn’t address location by reference.
2) James Polk’s DHC URI. –worthy of discussion?
Rohan Mahy:Enough information to get to somebody when need help?  What about third dimension (altitude?)? Information about relays is unmotivated.  He will send summary of this comment to the list.
Andy Newton: Why would you want to send anything other than location-by-value to the LCMS?
James Winterbottom: If we are going to restrict LCMS to only support mapping, then should add rqmt to say that user identity is not provided along with the location information.  He agreed to resend an email that documents this issue.
Brian Rosen: Personal observation: mapping should only be by value, and with no identity. There is great value in providing mapping well before an emergency call and caching it.  But it should be recommended to map right before the call, and use cached information only as fall-back.
Henning Schulzrinne: When invoked, this is an operational issue, and should not be a requirement. E.g., a hotel or coffee shop might map and cache and then provide locally to users.
James Polk:  Concern was about limiting/preventing early queries and caching.  If this is allowed, he is OK with requirement.


About "Ahead of time mapping": The consensus in the room was that this is something that should be allowed but certainly must not be mandated. There is an outstanding operational issue as to when this is a reasonable thing to do.



 o Open Issues in the Security Threats Document (Tom Taylor)
 ============================================
  
 draft-taylor-ecrit-security-threats-00.txt  


http://www.ietf-ecrit.org/IETF64/IETF64-ECRIT-Security.ppt

Tom Taylor made presentation of security threats document issues.
Provided diagram of potential Emergency Call Routing Attack Points.
ECRIT won’t address all—only mapping-related issues.

Architecture determines threat perception.
If mapping is done at user client configuration time: lowers likelihood that attacks on mapping server are effective; raises likelihood that attack on user client itself would be effective
If mapping is done at call time, and mapping client is a proxy: raises likelihood that attacks on mapping server would be effective; attack on user client itself less likely to be effective.


In other words: In general, there are two architectures and the threats model is different for each.

Henning Schulzrinne: What does it mean to authenticate? Should be clear as to whether it means that a certificate is provided (e.g., by Verisign) indicates that this is a mapping server, or whether it means that the server has been authorized to provide service in a geographic area.  
Steve Kent: Should describe and get agreement on what the requirements are before identifying use cases for attacks.  
Andy Newton: Disagree. Layout of draft is good, but need to have more specific association between threats and requirements
Jon Peterson:  Supports approach in draft. Start with use cases for security; indicative of properties that are needed; then define requirements. Specific vulnerabilities must be detailed.
Hannes Tschofenig:  Ideally, we would like to have perfectly secure system, but in case of failures, don’t want to fail the call.
Steve Kent: There are no vulnerabilities when correct operation is not defined.  If you can’t step back and say what you are assuming about correct operation, then you don’t have a context for correct operation.  Tradeoffs should be made, but after the requirements have already been identified first. 
Jon Peterson:  Agree that need to have a common understanding of requirements.  But should continue on trying to define them based on what has already been identified. (He said this much more elegantly.)
Henning Schulzrinne: Suggest that we specifically focus on this document.
Hannes Tschofenig: Requested Steve Kent to review the document and provide comments to help it be more complete.
 



Further discussion on mapping server authentication. Specifically need to make a distinction as to how and what level this should occur at. In particular, discussion excerpt is as follows.



Henning Schulzrinne:  Most people take authentication as identifying a “type” controlling access; but doesn’t usually imply that information is correct.
Can I ascertain that mapping server has been authorized to provide this information?
Not a protocol or crypto problem, but rather a problem of determining/assuring the recognized authority.  Since this is out of scope of IETF, then has to be done in general terms to make it possible.
Andy Newton:  Agreed with Henning. 
Hannes Tschofenig:  A requirement of the PSAP?
Unknown: Threats from outside?  Threat on the call pass?
Hannes Tschofenig:  Trying to address an impersonation threat.  Have been trying to determine what security threats are important enough to address.
Brian Rosen:  This is a threat to be considered.  But not a strong requirement.  Nice to have.
Jon: It would be tough to meet a requirement like this.  Need basic integrity protection.  However, getting certificates based on serving area could be complicated.
Henning:  Need to get away from concept that UA would authenticate mapping server, but rather should have a chain of trust. 
Ted Hardie: Should be careful not to create a requirement that is not a protocol requirement, but that is also not an operational requirement.  Have agreed that would still want to use results in case of authentication failure.  But the operational requirements expressed indicate that it should be the highest priority.
Jonathon Rosenberg expressed deep concerns over how to stop denial of service attacks against PSAPs. He sited spoofing the identity of the mapping service to always return the URI of the same PSAP as one example. No clear solution to this problem as been identified. It is clear that DoS attacks against PSAPs are of concern. A rogue mapping server could fool endpoints into participating in an attack on a PSAP.  
Steve Norreys: Also need to address the situation where an event initiates a lot of calls.
Jonathan Rosenberg: Need to protect the PSAP
Brian Rosen: A difficult balance between protecting the PSAP from DOS and also accommodating large number of calls, possibly related to an event(s) reported from a common location.
Ted Hardy indicated that he was not sure that providing authentication for this actually had any value. The example he sited was that if you make a call to the mapping function once to get a URI and you believe that it is suspect, then making a second call will most likely yield the same result. The outcome is that unless you use the URI the call cannot be routed anyway, so what choice do you have. Some discussions ensued about how one might provide indications with the outbound call to flag the concern over the resulting URI. No solution to this specific problem was proposed

Issue remains unresolved.


 o ECRIT Architectural Considerations  (Andrew Newton)   
 ==================================

 draft-polk-newton-ecrit-arch-considerations-01.txt


http://www.ietf-ecrit.org/IETF64/IETF64-ECRIT-Arch-Considerations.ppt

Henning opened with a question as to whether the document should be more of a clarifying document so that all people have the same view of what the architecture is.

Everyone has a different view on how this will work.
I-D tries to identify things that every network architecture will need to address.

• Bootstrapping
• Mapping
• Convergence
• Conveyance

(Major topics summarized below to help relate to discussion. See presentation for details. 
 
Andy indicated that in some situations that conversion between Civic and Geo and Geo to Civic may be required.

This opened up discussions on Geocoding

Richard Stastny indicated that he does not believe that GeoCoding should occur on the way through the system.

Brian Rosen indicated that the only node that should ever do conversions should be the PSAP.

James Polk believes that the group was largely talking past each other because we did not all have the view of the architecture.

The issue was raised over what an emergency identifier is and how to use it. 
Rohan Mahy: Terminology about identifier is confusing.  Something used by the user, not by parts of the network.  Requirement from user perspective:  May exist some numbers/strings that you can use to specify an emergency call.
Henning Schulzrinne: I-D uses new terminology that is not consistent with other documents that precede it.  Should try to be consistent.
Andy Newton: We keep working on terminology in requirements document.  Common understanding of architecture will help with this.
Henning Schulzrinne: New terms don’t help this, where they are not necessary.

General outcome of this discussion was that some kind of universal emergency identifier was desirable, Henning presented some possible mechanisms later (also see the presentation).


Static mappings between locations and PSAP URIs: Concern was raised by Marc Linsner as to whether this was possible, since the URI mapping is technically owned by the PSAPs since they control the boundaries. This seems to tie back to the concepts of ahead of time mapping, and should be allowed but not mandated. How it is managed are operational concerns.

 

 o Impact of the Location-to-URL Mapping Architecture 
   (Henning Schulzrinne)
   ==================================================
 
 draft-schulzrinne-ecrit-mapping-arch-00.txt


http://www.ietf-ecrit.org/IETF64/IETF64-ECRIT-Impact-of-architecture-on-requirements.ppt


Henning: No clear-cut entity to talk to in some areas.  Would be nice to be able to get started without having universal agreements.

Resulting Requirements:
End user must be able to perform mapping if mapping function is offered by VSP or other
Mapping nodes must be able to refer clients to more appropriate node
(see slides for details)


 o Emergency Services URI (Henning Schulzrinne, 15 min)
   ======================
   http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-service-00.txt
   http://www.ietf.org/internet-drafts/draft-ietf-sipping-sos-01.txt



http://www.ietf-ecrit.org/IETF64/IETF64-ECRIT-Emergency-Service-Identifiers.ppt

This raised lots of discussion. How to mark a call as an emergency call being first in the fray.

Jon Rosenberg:  “To” could work for 911, but can’t be used for other services where forwarding might be invoked.
What about SOS? Is that OK also?  For mapping, that is another issue.
Ted Hardie: Somewhat concerned about incremental deployment.

Henning Schulzrinne:  Two scenarios: 
1)In visited network with outbound proxy, but my home network supports emergency calling.  Outbound proxy will recognize normal URI, route to my home and then process as an emergency call.
2)If my own service provider doesn’t know about emergency calling, then Outbound proxy could recognize and route call.  If Outbound proxy doesn’t do this [...]

Rohan Mahy: Don’t have problem of going to outbound proxy.  If trying to solve least common denominator, have to use numbers.  Easier to change UA to get mapping based on location.  Would you use service URI for roaming or not-roamin?
Brian Rosen: A way to mark calls as emergency call.
Rohan Mahy: Marking implied by a number.
Brian Rosen:  Need one that is recognized all along the way by everybody.  Willing to have phased in.


Henning and Brian were strongly in favour of a common URN for example sos@emergency.com. The concern raised with this approach was that it did not yet exist, and would require international acceptance to implement. Discussion was had over whether the ground work laid by ENUM could be used to facilitate this more quickly, and whether or not it was something that could be phased in incrementally.

Rohan Mahy raised concerns about this approach and was suggesting that local identifiers such as 911 could still be used. This caused some concern because it was unclear what 911 would mean in Europe or Asia and how this would be addressed. This lead back to the universal URN discussion, it was very clearly stated that the users must be able to “dial” the emergency number most recognized by them, but that the universal identifier be used on the wire. No outcome on how to proceed with this was decided.

Brian Rosen: You do need to have capability to refer a call to 911.  (Worse and easier than re-targeting)

Ted Hardie: Has this been referred to URN or URI WGs?  This will be useful.

---

Brian Rosen asked: Is there is a sense of mapping solutions?

Meeting closes (out of time)

Interim meeting to be planned for the new year.