Internet Emergency Preparedness (ieprep) Bof

2.7.22 Internet Emergency Preparedness (ieprep) Bof

Current Meeting Report

Notes of the IETF 52 Internet Emergency Preparedness BOF

(thanks to Greg Bain for the raw minutes)

The BOF commenced at 09:00 hours on December 13, 2001 with approximately 100 participants. The BOF was co-chaired by Scott Bradner of Harvard University and Hal Folts of the National Communications System (NCS). The featured speaker was Fred Baker from Cisco.

Scott opened the BOF by stating that this is not the first time the IETF has done a BOF on emergency services. (The first time was at IETF 48.) The September 11, 2001 incident has crystallized more interest in emergency services. Scott stated that the IETF, through this BOF, is beginning to address the issue of emergency services in the Internet.

Scott briefly outlined to the BOF an example of an emergency communications system deployed by Japan. The system, IAA (I Am Alive), was used on September 11 and provides a way for people to communicate to their loved ones that they are OK after a disaster.

With respect to Internet/PSTN (Public Switched Telephone Network) interface a few questions surfaced. With respect to Internet connectivity during a disaster, the question arises with respect to: "What happens when a person using the Internet during a disaster situation wants to go to a semi-collapsed PSTN?" How does the person tell the Internet to prioritize a call when going to the PSTN?

Scott stated that the Internet worked "just fine" during the September 11 incident.

At this point in the BOF Fred Baker gave a presentation covering three acronyms: IEPS, ETS, IEPScheme. All these acronyms represent the same thing with respect to emergency communications.

ETS (Emergency Telecommunication Services) has been under development in the ITU for the past few years. People (mostly from the NCS) have been coming to the IETF to ask for help because disasters happen e.g., earthquakes, storms, all of which require Government communications for disaster relief.

Fred stated that in the United States there is a PSTN system called GETS (Government Emergency Telecommunications Service) to facilitate government emergency telecommunications during disasters. (In the United Kingdom there is a similar system.)

With respect to the Internet, RFC 791 contains a way to prioritize traffic,

which has been obsoleted. The MLPP internet drafts (Polk) regarding SIP propose to use exactly the same mechanism - to embed a policy as well as a label into a field, where IMHO a label should be used and let the policy be external.

Fred stated that an Internet application that was extensively used on September 11 was Instant Messaging (IM).

We have to look at the way the telephone system behaves and how to interconnect to that behavior. Remember the telephone system is not TCP friendly!

TCP adapts to congestion. Telephony on Internet e.g., Voice over IP, streaming, mimics tradition.

Internet applications:
Fred gave some views from a different perspective. Fred stated that Dr. Ohno (of Japan) presented a video on IAA at the previous emergency services BOF. IAA provides a cheap and simple way to get people off the telephone network, but also to convey information among people.

FEMA is an example of a government agency which responds to disasters, and has among its bag of tricks an "office in a box", consisting of a satellite-based IP network, a router, and some number of PCs and VoIP telephones. They load the thing into a truck and can deploy it within a short time after delivery. People that really use the Internet in response to emergencies find a way to ensure that it will be available to them at the time they need it.

Other Internet application examples include fireman on the ground where Instant Messaging has utility.

Fred provided important cases to note and consider:

(1) Telephone capabilities in New York City were taken out during the September 11 incident. The loss of these capabilities impacted the entire United States. The Internet, however, worked just fine during the time of these telephone losses.

(2) TCP congestion management was added in 1988 because of a congestive collapse of NSFNET. We (the Internet community) learned a lot.

In 1996 Fred was part of a panel covering Next Generation Networks (NGNs).
The panel recognized that elastic applications behave differently than inelastic applications. It is not clear we (IETF emergency services BOF) have the same problem as inelastic applications.

In 1996 Fred was on a panel with Phill Gross in which he stated that earlier in the year Internet MCI had experienced as much as 20% loss rates on some links. In the presence of those loss rates, Internet MCI was not reported as "not working", but as "slow". In addition the Atlantic links, which have had loss rates in excess of 4% for years, and showed some simulations in which TCPs were experiencing as high as 43% loss rates. Each of these was getting its job done, albeit under very adverse conditions. It is important to note that elastic applications (applications which run on TCP or transports with the same congestion avoidance characteristics) do not have the same problems as inelastic applications such as VoIP.

Fred discussed Network Access (NA) during an emergency.
If you are in a location prone to problems, e.g., earthquakes, you can pre-provision more capabilities, i.e., prepare in advance.

To get Internet Service Providers (ISPs) attention, e.g., "Hi I am important." How should the ISPs respond?
Fred spoke about GETS priority and restoration priority (lines that are restored first during or after a disaster).

Any program which presumes commandeering of existing Internet service in order to support use by emergency personnel presumes that the emergency folks have a way to identify themselves to the ISP agreed on in advance, and presumes that the equipment in use can get the right configuration without the emergency person having to think about it.

Prime Issues:
(1) We need to talk to a telephone network, especially with respect to signaling.
(2) We need to address AAA (Authentication, Authorization, and Accounting) issues.
(3) We need to address contract issues.

At this point Scott opened the floor to comments asking "What does the IETF need to do to deal with emergencies?"

Aaron Falk:
>From an office in a box (a portable, Internet-enabled, set of equipment that can be brought to the site of an emergency) perspective, it is not clear that the IETF has to do something. Fred said that we do not have to address this, except for telephone interconnections.

Kev Lauhburn(?):
The network was not under attack on September 11.
Special emergency communications should already be operating.
Access services were full on September 11. Internet backbone traffic was similar to the traffic of Sept 10.

We may have to address access better. Everybody dealing with emergencies should have an Internet phone available at all times.

FTS 2000 (a US government telecommunications contract) had contract provisions to address problems.
How to run a country in a standalone mode: different ISPs are in different countries, some of these countries we do not like.

Summary: Backbone is not a problem. The problem is access. The PSTN core has enormous Bandwidth (BW). Specialized systems are not part of the PSTN

Hal Folts:
The public network is used by GETS. GETS uses a card for users to get network access.

Henning Schulzrinne:
Technical: TCP overload, TCP reverts to a non-congestion control mechanism.
Even for traditional Internet under severe overload, we still may be able to address emergency services.
Content distribution: It may be something to use to distribute Web content. Data bases, such as IAA and CNN had access problems on September 11.

Dr. Ohno:
There is a long history on how to manage these data base systems. The systems are operated every day. These systems accept many big things. IAA is addressing access. These systems are important to emergencies.

Karen Sollins:
The computer systems board of the National Research Council addressed emergency care responses.
Does the IETF want to focus on application level responses?
It would be nice if a cell phone system can convert to a peer-to-peer system. What happens when a break is on the other side of the network?
>From an AAA perspective, who has priority when the emergency first happens?
Will the ambulance services give up priority to police? How do you get access to deploy fire departments? Should the information on fire deployments be protected?
Layers of abstraction need to be addressed.
The computer board CSTV reports are online and need to be made available.

Rod May:
Congestion collapses on access links. People like to talk when they are upset. Right after an emergency you don't want UDP streaming around the network.
There are potentially a lot of things IETF can do e.g., SIP, MEGACO, BW usage and availability.

Andy Smuller:
Prior to September 11 we did not have any hope that emergency service work would go anywhere. We need to be good citizens of our community.
We need to consider interworking more and not focus just on Internet issues

Don Choi:
MLPP
Multi Level Precedence and Preemption (MLPP) is a solution for support of mission critical issues. An Internet draft was submitted to the SIP
Working Group (WG). This is more than a SIP issue. Emergency services are beyond just one WG.
Issue: We need flexibility and interoperability to support preferential treatment.

Scott:
We need better access to support preferential treatment. We need adjudication in the access portion to support users who got there first.

Dave Crocker:
The IETF has experience. IEPS is interesting because there is an incredible range of issues.
The way to success in the IETF is to start simple and useful. What are the parameters for local, infrastructure, interworking, new technologies, and those technologies that require change? We will get bogged down if we don't look at the parameters in a useful sense.
Infrastructure Issues: Too much focus on congestion.
Recommendations: What simple focus can be done?
Special systems for special circumstances typically fail.

John Wroclawski:
Don't do anything special. Play to your strengths. Streaming media is an example that can be incorporated into planning.
Two things:
(1) Think about doing as little as possible.
(2) Think about what is likely to work.

Scott:
We need to work with someone dealing with E911. We probably need extra equipment.
Second, from an MLPP perspective, there is not any way to discriminate application "A" from application "B" during congestion.

Henry Sinnreich:
There has to be a code point for emergencies and how to get access during emergencies.
For example, there can be a DiffServe code point for emergencies.

Scott:
We need to address authentication for this potential code point.

Dave Allan:
Three points:
(1) Multiple independent loosely coupled systems, when a failure occurs other systems fill the void.
(2) Build resilience and technology independence.
MLPP confounds protocol design. This is a trap. Application layers on the phone are confounded.
(3) Whatever we do on access links is unavoidable. Providers are reluctant to deploy admission control or deny admission.

Aaron Falk:
We need to write an application document to figure out what we need. There are 250 governments in the world but only five levels of priority (in the ITU MLPP Recommendation).
We need to figure out what tools we already have. The government has to come in (with money) to the operators and tell what it needs.
The government should spread the boxes out.

Hal:
This emergency services effort is in close partnership with the telecom industry.

Scott:
It is also in conjunction with ITU work.

Fred:
The label or priority is put on a call. The operator applies the policy.

Don Choi:
The ITU Recommendation (an internationally approved Recommendation) on MLPP has five levels. The previous comment on MLPP with respect of the number levels and governments is misleading.

Dr. Ohno:
We need to introduce control of priority mechanisms. In Japan they are introducing metadata to do this type of control, for example. We have to consider potential control in application layers.
E911 is a very localized emergency service. Nobody in Japan understands
E911 or the numbers 911 because Japan uses 119.
The Transport Layer does not have problems. Let us consider how to internationalize.

Ross Callon:
Issues: Protection of Internet, and how to make the Internet useful in emergencies.
Keep the emergency service simple. We want emergency services and authentication. We worry about valid authentication protection. We need simple authentication mechanisms. One class of service is preferable.
Another question for consideration: How to operate an Internet emergency service without DNS?

Scott:
One class has problems because of different applications. Distributed denial of service attacks present problems that need to be solved.

Hal:
There are two different services, 911 and ETS.
There is a general public service to report an emergency. The service we are talking about is an authorized service to recover from a disaster.

Steve Blumenthal:
Protection of the infrastructure, is there a group addressing this? There is a concern about very highly coordinated attacks.
The independence and random nature of the Internet on September 11 was a real plus, because there is a lot of Internet decentralization.

Having GETS Emergency PINs (Personal Identification Numbers) for the Internet is difficult to do. Some ISP assets may not be owned or controlled by the ISPs.

Rohan Mahy:
We should encourage people who come to IETF to go through our process.

Hal:
We are working with the civil side of NATO. We are also working with ETSI.
This European standards organization recently established a body to address emergency telcom.

Scott:
Are regulations for best practices a good idea? We need folks to come here instead of trying to regulate from a distance.

Rohn Negan:
It is hard to go to a building and find a wire (network tap). Second, whom do you go to and then ask permission to work on the wire?

Andy Smoleth:
We do have the right set of protocols. We have to be careful to not exclude other protocols by other groups.
MLPP needs other protocols to function in a proper manner. We need a relationship with the people dealing with these to make MLPP work.
There are already a lot of basic tools, what do we have to do? Perhaps start with a filtering mechanism similar to SIP.

Dave Oran:
Two problems
(1) Response
What to do when someone is out to get you? You need credentials that are hard to forge. Planning is different. Perhaps we need two different WGs.
(2) Hacker protection
We need a security considerations section. Not just privacy, but how to defend against attacks.
Every time we do a protocol we take into account security.

Dr. Ohno:
In Japan, there is a centralized location for emergency communications.
We need interoperability, scalability, and protection from unauthorized users.

Bar Hipps:
Telephone lessons: We can't prepare for every emergency. It is a continuous process to conduct after actions to prepare better for the next emergency. In a 1989 California earthquake the entire east wall of a switching center collapsed because one bolt broke in a floor. We subsequently replaced existing bolts with bolts of better quality.

Andy Zontes:
We need to take on adult responsibilities in the Internet.

Peter Lothberg:
What can we do to make the network better (i.e., more secure). The problem is infinite. We already have rich connectivity.

Sean Donelan:
If somebody in a city gives network priority to city police this action will create gridlock. There is an IETF concern about having too many documents. We cannot solve all the world's problems in one RFC.
With respect to access out of the network, the far end is a problem, if you only have network access.

Karen Sollins:
What ever we do has to be part of everyday life. People cannot be expected to do something different in an emergency.
Is there a dichotomy between military and civilian response? Does FEMA and the military assume they have more priority over others?

Ran Atkinson:
Is anyone on IESG charting a WG on this topic?

Scott:
With respect to an IETF charter, yes there is consideration for a WG or WGs. Hal has composed a draft WG charter for an IETF WG.

Don Choi:
The space between military and civilians is another issue.

John Wroclawski:
Standards are developed to build bridges and use certain bolts.
There are two groups in this room.
(1) How the Internet can best meet the requirements for emergency services.
(2) The other group is an extension of the bolt concept.
If this process is brought to the IETF, first look at emergencies from hi level standpoint and ask an important question. Will this defer or impact other important work in the IETF?
We don't need people lecturing us on what to do, especially about what bolts to use.

James Polk:
This is not 911. Granularity is an issue at times of emergency. With respect to MLPP, Verizon recently put in a wavier to do preemption in their cellular networks.

Hal:
The government has ordered cellular priority in three cities before the end of 2001.
We have come to the IETF to define and work together to find a solution, given the expertise here in IETF. We are not dictating.

Dave Crocker:
With respect to a former experience with business requirements over E-Mail, it went nowhere!
We can first document what the existing system will do. How do we integrate? Will there be any standardization? How does the existing Internet not fulfill emergency requirements?
Let us try to find a way to have specific requirements that have immediate solutions.
Take existing GETS definitions (capabilities), then consider how can we adapt to these capabilities in the Internet.
A starting place, for example, is what is an existing system? What would make sense for us to emulate?

John Wroclawski:
The IETF does have the capability to convene hi level meetings to discuss issues like this.
What we need to do is consider, from the high level perspective, what the Internet can do best and still be useful.

Fred:
What does it take to place a call using GETS? The circuit switch network places your call ahead of other calls.
With respect to the MLPP discussion we need to consider authentication requirements.
We need emergency capabilities in a world where circuit switches do not exist.

Don Choi:
MLPP came up with technology neutral requirements. We are asking the IETF for assistance.

Hal:
Critical infrastructure is not part of our work here. We are not requesting this.

Scott:
Is there something for the IETF to do? And if so, what is it?

Fred:
We have SIP work and an informational RFC.

Dave Crocker:
There is technical work to do, but we are not sure what it is.
Hal walked in the IETF with prioritization. The Internet does not have QoS (Quality of Service) distinctions.
Recommendation: Write a document to tell a provider how to best focus on how to interwork with the PSTN.

Scott:
There is a signaling group called NSIS. It could address some issues.
Problem:
Denying service to other than emergency service people during an emergency.

What is being heard from the BOF?
It would be useful to have an impedance matching document to match requirements into what the IETF is doing now.

Brian Rosen:
SIP is doing 911 and discussing MLPP.

Dave Crocker:
We have a hammer to deliver specs, but we also have a screwdriver.
Suggestion: An IRTF effort to develop a range of goals to deal with things beyond us today.

Dr. Ohno:
What is the approach?

James Polk:
Recommend a place to designate a discussion in the IETF.

Richard Brennan
ETSI TIPHON
There is work in the ETSI TIPHON project on a requirements document (for emergency telcom) that would be useful to IETF.

Scott:
We will continue discussions from this BOF using E-Mail correspondence.

The BOF ended at 11:30 hours.

Slides

Internet Emergency Preference Scheme (IEPS) Overview