Current Meeting Report
Jabber Logs

2.8.7 Internet Emergency Preparedness (ieprep)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 08/16/2002

Scott Bradner <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
A. Mankin <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe ieprep
Description of Working Group:
Effective telecommunications capabilities are imperative to facilitate immediate recovery operations for serious disaster events, such as, hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen any time, any place, unexpectedly. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations.

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.

Goals and Milestones:
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.
  • - draft-baker-ieprep-requirements-00.txt
  • - draft-folts-ieprep-white-paper-00.txt
  • - draft-ietf-ieprep-framework-02.txt
  • - draft-ietf-ieprep-security-01.txt
  • - draft-ietf-ieprep-requirements-00.txt
  • - draft-ietf-ieprep-packet-marking-policy-01.txt
  • - draft-ietf-ieprep-reflexive-dscp-00.txt
  • - draft-ietf-ieprep-reference-00.txt
  • - draft-ietf-ieprep-sip-reqs-00.txt
  • No Request For Comments

    Current Meeting Report

    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 
    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 
    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 
    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 
    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 
    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"
    Hal said:
    The draft is about Objectives for emergency communication using IP 
    Not all the objectives may be simultaneously possible, lets see what we can 
    He would like any place / any time access a by authorized emergency 
    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 
    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 
    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 
    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 
    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 
    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 


    IP Telephony Framework, v2
    ieprep User Objectives
    An ISP Reality Check
    Some Thoughts on CoS and Backbone Networks
    Accounting Requirements for Priority Services