Last Modifield: 08/16/2002
Three examples of emergency communications include:
1. Conveying information about the priority of specific phone calls that originate in a VoIP environment through gateways to the PSTN.
2. Access and transport for database and information distribution applications relevant to managing the crisis. One example of this is the I am Alive (IAA) system that can be used by people in a disaster zone to register the fact that they are alive so that their friends and family can check on their health.
3. Interpersonal communication among crisis management personnel using electronic mail and instant messaging.
Initial documents will describe the problem space and its salient characteristics. In particular the working group will devlop a Requirements for Internet Emergency Preparedness in the Internet RFC which will detail the specific functions and technologies needed to provide support for Emergency Preparedness systems in the Internet. The working group may also develop a Framework for Supporting Internet Emergency Preparedness in IP Telephony RFC if it is determined that IP telephony requires special treatment above what would be in the requirements document.
The international community needs advice as to what standards to rely on, in the form of a BCP. This BCP needs to identify mechanisms to provide deterministic behavior of applications, mechanisms for authentication and authorization, and recommendations for application design with existing protocols. In the IETF considerations for treatment and security of emergency communications stretch across a number of Areas and Working Groups, notably including the various telephony signaling working groups, Differentiated Services, Protocol for carrying Authentication for Network Access (pana), and various operational groups, so the IEPREP working group will have to cooperate closely with these groups and with groups outside of the IETF such as various ITU-T study groups.
The working group will develop a BCP RFC or set of RFCs, regarding operational implementation of services for Emergency Preparedness using existing Internet protocols. The RFC may include identification of gaps in existing protocols and requirements for use in new protocol or protocol feature design. It is out of scope for this working group to do protocol or protocol feature development. The working group will not focus on particular national regulations.
Best Current Practice: IETF Recommendations for the Emergency Telecommunications Service using existing protocols - what can be done with existing protcols and what can not be done.
Informational: Requirements for Internet Emergency Preparedness in the Internet. Framework for Supporting Internet Emergency Preparedness in IP Telephony.
|MAR 02||Submit initial I-D of Requirements|
|MAR 02||Submit initial I-D of Framework|
|MAR 02||Submit initial I-D of Recommendations BCP|
|AUG 02||Submit Requirements I-D to IESG for publication as an Informational RFC.|
|AUG 02||Submit Framework I-D to IESG for publication as an Informational RFC.|
|AUG 02||Submit Recommendations I-D to IESG for publication as a BCP.|
18-Novmber-2002, 1530 IEPrep meeting in Salon B Kimberly King and Scott Bradner chairing Agenda Review - Chairs ISP Backbone of Today - Ran Atkinson [James Polk made the point that disparaging information sources is not helpful. Ran indicated that the people who reviewed his slides were mostly in the room and that he was not claiming to represent them and accepted potential errors as his own.] Several points from the ISP presentation: The description is of common properties, not of any specific ISP. Many operators have a prime directive to NEVER drop a packet. Traffic exchanged according to business agreements. Enabling QoS can cause packets to receive worse treatment. Comments/Questions from the audience: After some packet loss statistics were quoted, Janet Gunn asked about packet loss due to Virus' as distinct from no loss due to cable cuts; she was told there was no available answer. Brian Carpenter noted that Diffserv was designed to allow diffserv in the fast path. David Meyer presented "Sprint & CoS" The slides included: What Sprint is doing - Edge QoS using egress (to the customer) access control lists (ACLs), not ToS bits. (Avoiding ToS bits for this functionality ensures they don't have to remark other packets entering the network from Internet connections, for example.) One possible exception (perhaps) is for IPSec protected VPNs. David noted their core traffic (trunks at or over OC48) is uncorrelated, meaning it does not exhibit self-similar behavior. (Thus they may be more confident that traffic loads over their core is smoother and hence feel more confident that sufficient capacity is available even during times of what might be considered a surge.) Their backbone has been measured to handle VoIP at 90 grade MoS (R factor?), better than PSTN. Comments/Questions from the audience: Dave Oran asked what happens in a major disaster. Dave Meyer indicated that even in the loss of large numbers of fibers, there was no effect on services. Peter Lothberg commented that internal topologies are even more complex (and therefore more diverse with additional capacity) than portrayed in Ran's slides. He also emphasized customer management of the customer egress traffic treatment and that ISPs generally do not control customer egress traffic. Meanwhile, customers "don't worry about the backbone." Susan Harris(?) asked about the meaning of "uncorrelated". Dave responded clarifying the effect of aggregation and smoothing at high speeds. Rohan Mahy paraphrased saying that burstiness is dampened. Henning Schulzrinne hypothesized it was possible that so much damage could be caused that the network would actually operate at or over the viable range. Mike St. Johns asked about the factors that caused the 90 grade on the MoS score (rather than 100) and asked about whether truly pathological traffic behavior had been exhibited. Dave Meyer said he had not seen any. Pat Cain from Genuity talked about their recently offered QOS service. This is again an edge service on the local access link only. The purpose is to manage capacity of narrow pipes. He noted that core congestion is generally self-inflicted although very large customers connections (e.g., those connecting with OC-48) can cause some difficulty. The next presentation "PCH; VoIP experience" was by Bill Woodcock. They offer VoIP from end nodes, often on narrow pipes. A demonstration of a VoIP call was established between an VoIP phone sitting in front of Scott Bradner and one in Nairobi, Kenya. Local PTT quality in Nairobi is much worse than VoIP. NAT was (and is) a problem for VoIP. Questions/Comments from the audience: Kathy Nichols - One of the cite article authors also does use QoS Sally Floyd mentioned the current time in Kenya and wondered how many concurrent TCP connections were occurring over the last mile. The discussion of current circumstances are about highly provisioned networks and Henning Schulzrinne commenting that we need to be careful about generalizing the current circumstances to true disaster utilization and effects. Ran Atkinson indicated that @Home could lose almost any capacity and deliver service to what remained connected. Peter Lothberg commented that if you really had that bad an outage, other things would break that would have far more serious effects. He also believes if we have "important traffic" and "normal traffic" then important traffic must be authenticated if it is to be given priority. Such a function requires crypto checksums, timestamps and the capability to check its validity at line rate. This then involves solving key management, and to traverse several jurisdictions, each packet has to carry multiple such headers. Without inventing a way to do this, any priority mechanism is just opening up another attack vector for the 'bad boys'. Pat Cain suggested that we need a lot of other things separate from the QoS issues, and we need to spend cycles on that. Hal Folts presented "IEPrep Requirements" draft-ietf-ieprep-requirements-01.txt Hal said: The draft is about Objectives for emergency communication using IP technology. Not all the objectives may be simultaneously possible, lets see what we can do. He would like any place / any time access a by authorized emergency users. Want preferential treatment for emergency communication [Scott Bradner asked if what was being requested was for emergency workers to be able to plug into any jack anywhere, authenticate themselves, and receive preferential treatment. Hal indicated this was desirable.] The draft objectives also request international / interconnected service SLAs are relevant to this Request for security capabilities Keep the connection up, even in DoS situations Hal ended by asking how to move forward. Questions/Comments from the audience: Dave Crocker - After commenting on the value of general objectives, Dave asked for specific short-term scenarios describing what specific items are needed. Unknown speaker - Discussion of whether these requirements apply to all services, or only to regulated services (PCH does not provide E911 connectivity.) Bill Woodcock responded that there is no consumer requirement to provide E911 services. He doesn't believe there's a legal requirement placed upon users of peer-to-peer devices that they magically make them do anything special when someone dials "911". Dave Oran paraphrased Hal's request as asking for authorized emergency users to be authorized to perform DoS attacks on other users. Scott Bradner rephrased the preferential treatment request as a request for definable probability of successful communication. Scott Bradner suggested that SLAs are an implementation detail. Scott Bradner and Ran Atkinson pointed out that confidentiality, integrity, etc are end-to-end problems, not network problems. Peter Lothberg said that the network cannot do anything about keeping up a "connection" that it does not know about. The network knows about packets, not connections. Scott Bradner pointed out that whether or not we can meet Hal's objectives, it is helpful to know about the objectives Bill Woodcock suggested that the PSTN cannot be made to meet the security requirements proposed in this draft. Unknown speaker suggested that TDM is subject to significant DoS, so why does IEPrep need something special? Another unknown speaker emphasized the value in separating the end system issues from the network issues since they are mixed in the draft. Dave Crocker suggested that there may be things that may need to be done in the network. And we should concentrate on those things that can be done in the near term. Emphasis on end-point only and end-point / access solutions may be useful in the near term. Unknown speaker suggested a requirement on the emergency handling of email, and particularly with the interaction with SPAM filters. Ken Carlberg presented "IEPrep Framework" This is a document on IP Telephony emergency needs; some rewording will occur and example solutions removed. Mike Pierce presented "Accounting" Accounting Requirements for Priority Services is not about packet level accounting. However, he did not restrict this to just SIP. There was discussion of the meaning of "requirement". Particularly interested in auditing, verifying conformance to usage policy ARCH slide actually is referencing RFC 3334. Questions/Comments from the audience. Henning Schulzrinne asked whether this is a SIP call accounting issue. There is ongoing work in SIPPING on accounting related issues. Peter Lothberg chimed in on the unreasonableness of packet level accounting. Scott Bradner suggested looking at the SIPPING and AAA work to see if that meets the needs. Scott Bradner wrapped up. WG chairs and ADs will get together to discuss next steps. Henning Schulzrinne's document is almost ready to ship to SIPPING.