Current Meeting Report
2.8.3 Internet Emergency Preparedness (ieprep)
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 06/05/2002
Fred Baker <firstname.lastname@example.org>
Transport Area Director(s):
Scott Bradner <email@example.com>
A. Mankin <firstname.lastname@example.org>
Transport Area Advisor:
Scott Bradner <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
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
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.
Requirements for Internet Emergency Preparedness in the Internet.
Framework for Supporting Internet Emergency Preparedness in IP
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
No Request For Comments
Current Meeting Report
Meeting Minutes of ieprep 17-18 July 2002 in Yokohama.
Ian Brown discussed the draft-ietf-ieprep-security-01.txt
Comments raised: We had a general discussion of the simple case in which an IP telephone passes unknown numbers to a PSTN gateway, and the PSTN authenticates using its already-defined mechanisms. Bill Woodcock among others object to requiring common authentication mechanism between PSTN and IP Network. Use of Area Code 710 (as US GETS does) as a preliminary authorization mechanism prior to authentication in the IXC is a non-starter - it will not necessarily work with user-defined dial plans, and has holes with respect to denial of service etc in the IP Internet.
Allison Mankin comments that the document primarily reflects solutions, not requirements. She looks for a threat analysis and a discussion of appropriate strategies.
Hal Folts discussed requirements draft as reworked in side meetings and on the list.
The draft should refer to RFC 1633 section 3.1 for the definition of QoS Requirement of elastic and real-time applications.
Title of the services should be consistent with standards used in other organizations: Emergency Telecommunications Service (ETS).
Section 3: quantification of services would be useful, to convey a notion of what services might be expected to accomplish various things.
Ken Carlberg discussed draft-ietf-ieprep-framework-02.txt
Requirements commentary should be limited to issues not covered in the requirements document.
Harald Alvestrand called for a reference to a technical definition of "call completion", in the sense of completing call setup as well as appropriate QoS. This may be in the requirements draft or the framework, and perhaps both.
Henning Schulzrinne offered to suggest text that explicitly indicates that RTP is unlikely to be an appropriate mechanism since bits in the RTP header do not influence the delivery priority of IP packets.
Allison Mankin suggested that solutions be removed from the document.
Rohan Mahy offered to assist in a section rewrite regarding SIP.
Van Jacobsen raised issues with depending on Diffserv EF without any admission protocol, and with proposing priority as a mechanism without any authentication or authorization procedure for its use.
Janet Gunn will get back to Ken to clarify the statements about limitations on the use of network resources by GETS calls
Henning Schulzrinne discussed requirements for resource prioritization for SIP-based applications
The fundamental service is the assertion (by an IP device running SIP) of priority and call type to the PSTN. This is asserted, in existing PSTN systems, by the caller, and asserts a choice among the choices s/he is presumably authorized to make. This must of course be verified once the user is authenticated.
Henning was asked to come back with a document that addressed requirements for Call Type information, Call Priority information, authentication and authorization of access to service and bandwidth, call-waiting/pre-emption as an end system, proxy, or gateway feature, and bandwidth admission. These apply to four classes of calls: calls starting in an IP network and ending in an IP network, starting in an IP network and ending on a PSTN or PSTN-like network, starting in the PSTN or a network like at and ending in an IP network, or tunneling through an IP network from PSTN to PSTN.
Dennis Berg discussed draft-berg-ieprep-sip-isup-gap-analysis-00.txt
The draft suggests that some parameters be exchanged in a rational way between PSTN protocols and IP telephony networks. Rohan Mahy suggested that it be recast as a requirements document and submitted to sipping for editing into SIP. Rohan to post the pointer to the process document to the ieprep list.
Fred Baker presented draft-ietf-ieprep-packet-marking-policy-00.txt
Van Jacobsen presented a concern for Kathy Nichols, Diffserv co-chair. The concern was that the DSCP is intended to identify traffic supported by a service, as opposed to traffic of a certain application type. He also worried that a specific BCP indicating the facilities used to support such services might be misused by regulators to mandate ISP services. Specifically, he wanted a statement between the requirements document and a document suggesting a specific configuration identifying the fact that inter-service-provider signaling as specified in this draft is certainly specified but is not commonly implemented.
Christian Huitema and another speaker also commented that while a cookbook such as this was an interesting useful document, it didn't seem to directly stem from emergency as a context.
Rei Atarashi presented draft-ietf-ieprep-reflexive-dscp-00.txt
Van basically felt that the notion of a default response from the host was inappropriate; this is something every network should provide a policy for.
Interim Meeting Minutes------
Hal Folts, Requirementes for Emergency Telecommuniations Capabilities in the Internet
Hal Folts presentation
· Perspective: building top-level concept for top-down approach.
· E. 106 is the IEPS document that only applies to PSTN.
· The concept has been expanded to include international emergency multimedia service (IMS) over packet networks, and is documented in F.706, which is not publicly available. Hal will try to make it available to the group on the ieps website.
· Together IEPS plus IMS are ETS.
· Requirements need to address selection of multimedia as well as telephony services. At the moment Telephony is the biggest issue for IP-based emergency services, but in the long run other services will overtake telephony. In addition to telephony, it expects IP-based services, such as email, IM, telemedicine, web access to gain in importance.
· Q: is the authentication purely national based? Hal Folts: today it is, but as the service spreads out that issue will have to be addressed
· Approach to realization:
o Utilize existing standards to the maximum extent possible; if required extend standards
o Don’t impede or impact basic functions of the internet
· Legality of preemption in US
o James Polk: it is neither explicitly forbidden, nor approved by the Telecommunications Act of 1934, but it does say that all traffic must be treated equally
o Hal Folts: where currently used or practical, preemption could be used
· Comment: priority is meaningless without a context. GETS has priority in access but not the bearer transport.
· Hal Folts: only applicable when needed to overcome congestion or limited bandwidth due to loss of network resources.
· Cory Beard: does the service provider decide whether an overload exists, or is decision up to the user?
· Fred Baker: concerned that you are making implementation more difficult. And concerned that we are building policy into technology. Why build policy into the technology? To avoid this, write the requirements in terms of a level of service. State QoS requirements, and let the networks implement according to policy. Then the service provider will guarantee that, when needed, you will receive the level of service that you contracted for (something happens, and then something kicks in). Written in this way, the requirement is for the service provider to deliver “what you contracted for”, not for “preferential service”. We should not tell the service provider how to deliver the level of service that he is obligated to deliver to you. The bottom line is that we want the “call” to go through, not how it is done.
· Comment: handing out discrete bandwidth in telephony is different from dealing with elastic traffic in the internet
· Dennis Berg – the National Communication System, the agency responsible for GETS, doesn’t want a service that requires activation. They want a service that is “always on”, but that it not applied to every communication request. The FCC Report and Order ruling in favor of a wireless priority service requires that the service be invoked on a “call-by-call” basis.
· Stu Goldman: if there is no congestion in network, then no features are activated.
· Dennis Berg: the user instructions tell the GETS user to dial a normal call first. If that call fails, then use GETS.
· Responding to doubts that GETS users can be counted on to adhere to the user instruction, Hal Folts and Dennis Berg commented that authentication for GETS requires input of up to 32 digits, which effectively discourages users from invoking GETS except when the user has experienced blocking.
· Stu Goldman: the switch doesn’t know if the user followed the instructions and dialed POTS first; it sees the GETS dialed digits and gives the call the GETS features.
· Dennis Berg – The GETS requirement is now stated as “95% probability of call completion at 10x overload when the entire call path has GETS features deployed”. Admittedly, how to achieve this is a separate issue.
· Stu Goldman: in GETS the Government determined what could be done technically first so they had this information when stating requirements.
· Dennis Berg: GETS started with a real, immediate problem. We don’t have the problem in front of us yet; instead we are attempting to anticipate the problem and solve it before it occurs. GETS did not start with a requirement for a level of service. It started from the position that any improvement in service was better than nothing. After we figured out what could be done and modeled the performance to see what we could achieve, then we stated a service level requirement. GETS was a classic case of backing into the requirement.
· Fred Baker: does “preference” mean a separate queue for priority packets? Take the example of downloading a graphic file, which involves very large packets. If these large packets are in the priority queue, they will start to impact other services, such as VOIP. I see services stop working when I hear ‘preference”.
· Comment: we need to define the service requirements first, and then let the experts tell us how best to do it
· Dennis Berg: There is a value in standardizing services. GETS in the Local Exchange Carrier networks was standardized through a set of generic requirements, so the service is uniform across a dozen different LECs. The GETS Inter-exchange Carriers, on the other hand, were given only a functional spec and asked to realize it in whatever way was most efficient in their networks. Now the IXCs are in the process of migrating to a standardized delivery of GETS. Experience has shown that the different approaches take by the GETS IXCs make technology insertion and interoperability with new services, such as Wireless Priority Service (WPS) difficult.
· Hal Folts: the use of ieprep functionality to generate denial of service attacks needs to be guarded against. For sensitive traffic – eavesdropping should be avoided and non-trace ability of identity and location of the parties is desirable.
· Fred Baker: there seems to be a inconsistency with the Government position that they want to be able to eavesdrop on all calls including Government calls (CALEA), yet here it is being said that the Government has a requirement that some calls cannot be eavesdropped on. Also, generally it is those who are attempting denial of service are interested in non-trace ability.
· Comment: anonymizer services are one way to hide identity and location.
· Fred Baker: in Finland laws allowed being anonymous. CALEA-type requirements forced carriers to disclose who was being anonymized. It is not clear what would happen if the anonymizer were the Government.
· Fred Baker: what proof is required that spoofing has not happened – a digital signature on the entire email?
· Fred Baker: concerning denial of service, can traffic to an attacked system be rerouted to an ops node, the sender taken out of service so that his address can be checked? How much of a threat must be present before the service is considered “broken”?
· Comment: how can denial of service attack be distinguished from bursty traffic?
· Comment: what usually happens is that the denial of service is brought to the attention of IT, and then they want to fix it immediately.
· Comment: now I don’t have to detect the denial of service - you tell me and I’ll react.
· Stu Goldman: the Government is asking for authentication as soon as possible in the call path.
· Question: is it necessary to support secure devices? Dennis Berg: the Government requires support for STU IIIs and CONDOR phones.
Ian Brown presentation on security
· Ian Brown: the PSTN/IP gateway must translate priority markings appropriately.
· Janet: do we need to translate all parameters in SS7?
· Dennis Berg: don’t need to translate everything in SS7; need to pass all in SS7 and translate what is need in the intervening IP network.
· Stu Goldman: there was a problem with not being able to hold up of a 911 call so that location could be determined.
· Alyson: the SIP to ISUP document has been put out for final comment without much discussion to date. The ieprep group should look at this document before it is too late.
· Fred Baker asked for a volunteer to look into this. Dennis Berg volunteered to develop a draft of what needs to be translated and James Polk agreed to contribute.
· Stu Goldman advised to look at T1 S1.7, which contains a mapping of SS7 to IP rather than reinventing the wheel.
· Comment: we should come up with complete list of what must be translated and present at next meeting.
· ________ agreed to make a first cut at identifying other IETF activities with a direct impact on ieprep tasks.
· Comment: concern that we are getting into PSTN style as opposed to pure SIP privacy. What if the guy is already in the network? This is harder, but we need to deal with cases where the session starts within the IP network.
· Comment: a device can have user verification as part of its profile.
· Alyson: we should follow the authentication approach and use certificates. A SIP proxy, when it receives a request, trusts some proxy in the path, or else it authenticates.
· James Polk: SIP has the 401 response code to do that.
· Fred Baker: if you can put together a global pki, hats off to you
· James Polk: we are trying too much to state a solution. The requirement should be that two proxies should perform authentication vis-à-vis each other, not how they do it.
· Fred Baker: agree.
· Q: is it a requirement that if the access network authenticates, then a second network also has the option to authenticate? A: technology needs to be there, the network will decide whether to use it.
· Stu Goldman: we may want to have both options available to cover the case of a foreign user versus roamer.
Ian Brown presentation on the Ken Carlberg’s Framework document
· Stu Goldman: the requirement that a preference be given to calls originated by the owner of a line doesn’t translate into GETS which has the goal of being accessible from any phone line.
· Fred Baker: we need a requirements document.
· Mike Pierce: I given many presentations on requirements and will do so again without saying anything new. What more can I present?
· Fred Baker: what is missing is a document. Henning put a document together.
· Mike Pierce: I thought that the header has been agreed to – that we just need to agree on how many values we need.
· Fred Baker: in the UK service of GPTS, there does not seem to be a need for multiple values; it’s a binary.
· Mike Pierce: the UK’s GPTS is a 1950’s service.
Mike Pierce presentation
· Mike Pierce: the DoD does not want to deploy VOIP unless their basic requirements for MLPP can be met. When facilities are oversubscribed, a higher priority call must get through.
· James Polk: the namespace concept allows each network to decide whether that namespace is valid for its network.
· Alyson: this work has not been added to the sipping charter. I need to understand why, if there are 15 levels in GSM, is it necessary to translate?
· Fred Baker: is preference being requested for both the signaling and bearer layers?
· Stu Goldman: both.
· Fred Baker: we seem to be mixing two things – is it not enough that the bearer is EF, but packets themselves must be given preference? Is the requirement to emulate the telephone service? In telephony, signaling requests a circuit; once the circuit is allocated, the data gets through. In data, the traffic is marked as EF, and it gets through. Why do we need to do more? Why do we need priority levels and preemption?
· Comment: if the entire traffic load can’t be served, then the highest priority traffic should be served at the expense of preempting the lower priority traffic.
· Fred Baker: if the network cannot serve the traffic, is shouldn’t accept it.
· Fred Baker: preference in transporting the traffic is not needed. If the priority level mechanism applied during call admission results in knocking down the call, the call isn’t there consuming bandwidth and the higher priority call should be able to be served. We should just use EF in call setup.
· Mike Pierce: if we could assume that process everywhere, then we could rely just on preemption and we wouldn’t need to mark the data packets themselves. But we can’t assume that.
· Cory Beard: This would be right if all use a constant bandwidth or are allocated according to maximum needed bandwidth. If it is a case of variable bandwidth, then the signaling level sets up preemption at the packet level. This is a data plane issue as much as signaling plane issue.
· Comment: STU IIIs are constant bit rate sources.
· Alyson: in SIP a call can set up multiple data streams and carry pictures in the message, so it is possible to set up a video call that has both voice and data. Can these two types of traffic be identified separately?
· James Polk: by call id, different dialogs.
· James Polk: the original MLPP spec said preempt as many calls as necessary to get the needed bandwidth. So if preemption is needed for a video call, preempt several voice calls.
· Mike Pierce: it is necessary to protect information on what areas have a high level of traffic. In the DoD world this information is very sensitive.
· Fred Baker: In conversation with naval station on how to work around congestion, one topic was congestion avoidance routing. Their requirement is to have the routing info DSCP identified in the traffic stream. Their routing metrics measure mean rtd and queuing delays. The Navy wants this information in routing, not to hide it, but have it known to the routing system.
· Mike Pierce: this information would only be hidden from the outside world.
· Q: are we talking about the current routing used for SIPRNET and NIPRNET
· Alyson: how the semantics of the namespace is used should be understood before we agree to it.
· Polk: do you want a semantics statement for each namespace?
· Alyson: examples of what mechanisms would be invoked by the namespace.
· James Polk: the resource priority header not specific to ieprep
· Fred Baker: yes.
· Comment: there are already mechanisms in these networks. NIPERNET does not have QOS.
· Fred Baker: mapping 802 labels - even if there are the same number in each set, it is not always easy to map.
· Comment: the ieprep recommendation should be that an identifier be generated either by proxy server or gateway, and that this identifier must be honored, or ignored and passed, but not changed.
· Q: how is ieprep architecture a subset of assured services? (Especially use of access routers - do we need to tell others how middle boxes work?)
· Mike Pierce: we have not advocated differentiating queuing of priority data packets by priority level, and this functionality should not be pursed (i.e., priority queuing of voice packets in respect to other voice packets). Modeling has shown that this approach does not provide benefits, but instead creates jitter.
· Dennis Berg: where can I find this analysis?
· Fred Baker: the assured forwarding spec was written in ‘97-‘98. EF has recently been updated to give it a better math foundation. The number of levels has been based upon commercial service provider requests. Recommend that we use commercial values and then add local values.
· Mike Pierce: that would require arranging for these local values in networks on a case-by-case basis, which is too cumbersome.
· Fred Baker: I would object if the commercial networks would have to support extra mechanisms just to have them available for contingent use. My company’s equipment can today give you the needed range of local values.
· Fred Baker: request that you write an Internet draft and take it to the diffserv working group.
· Comment: diffserv can tear down a call; “record route turned on at proxy server”, any redirection between endpoints goes through the proxy server.
· Mike Pierce: who stops the media flow?
· James Polk: the proxy server. It sends a bye to each end.
· Comment: it would be preferable to introduce delay before discarding packets
Cory Beard presentation
· Have tried to write an alternative requirements document that states only generic requirements and avoids stating requirements in terms of any on solution. Preferential treatment is one approach, but not the only approach.
Policy decisions need to be made by the service providers, not by the ieprep WG.
· There are three approaches: 1) best effort, 2) statistical guarantees, 3) preferential treatment.
· Fred Baker: We surveyed the top 70 networks and found that the highest utilization rate was 12%. I think this will continue for a long time. Where there is some congestion today: campus links, access links, inter-service providers links (at 70%). Also, it takes 10 months to add a new fiber link, so service providers are going to start early to be ahead of the curve.
· Alyson: how the semantics of the namespace is used should be understood before we agree to it.
· Polk: do you want a semantics statement for each namespace?
· Alyson: want examples of what mechanisms would be invoked by the namespace.
· James Polk: the resource priority header not specific to ieprep. SIP has always had a priority header to enable originator to tell called user that it is an important call.
· General consensus that the field ought to be named “namespace.value”, not
· Alyson: I am assuming you won’t process ___until the call goes through the network.
· Alyson: want to limit people’s access. You want end-to-end integrity.
· Polk: we will recommend authentication.
· Alyson: if you register a namespace you are impacting the behavior of SIP
· Fred Baker: SIP already has the ability to clear an existing call.
· Alyson: at the request of the caller.
· Comment: Sipping could be the home for a namespace document.
· Alyson: Scot wants us to be standards track if it is to be an IANA registration.
· Dennis Berg: who owns a namespace?
· James Polk: Anyone who wants can use the structure.
· Dennis Berg: what if I don’t want anyone else to use it because I don’t want their traffic intermingled with my service? Do I get an exclusive on the namespace when I register it with IANA? It seems to me that the structure of the parameter should be defined here. Any specific namespaces should be accompanied by a service description when the namespace is registered with IANA. Namespace territorial claims should not be in the ID defining the parameter.
· Hal Folts asked if we want E.106 to be an informational RFC for ieprep. Fred Baker states that he didn’t object. Hal also wants to make the F.706 and informational RFC.
· It was agreed that the presentations would be included in the minutes.
· PSTN Gaps/Requirements Polk+Berg designate
· Elastic Traffic Requirements Beard+Folts
· Resource Priority Requirements Schulzrinne+Pierce
· Security Framework for ETS Brown (ask Eric Rescorla)
· Framework for ETS Carlberg+Brown
· Edge Interface (BCP) Baker
· Terms of Reference (BCP) Brown
· Diffserv Reflexive DSCP (BCP) Atarashi+Baker
· IEPREP SIP Namespace (BCP) Polk+Berg?
Interim- Framework for Supporting IEPS in IP Telephony
Interim- Network Requirements for Internet Emergency Preparedness Services
Interim- Securing prioritised emergency traffic
Interim- SIP Resource Priority Header
Interim- DOD Requirements for Prioritized Voice
- Henning Schulzrinee
- James Polk
Reflexive DSCP Policy
- Don Choi
- Mike Pierce
- Steve Silverman
Making a call in a hybrid network
IEPREP Requirements ID Proposed Revisions