[Ieprep] draft ieprep minutes

[Scott Bradner <[e-mail]>]

please take a look at these draft ieprep minutes and send in comments
(yor name is wrong, you did not say that etc) before friday at 8pm EST)

tnx

Scott

----
Notes of the IETF 52 Internet Emergency Preparedness BOF

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?"

Erin 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. 
Contend 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:
IAA
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 Sollens:
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 Cenrick???:
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 Allen:
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.

Erin 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 119.
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 Bloomingthol:
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.

Rohn Negan:
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 Sollens:
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.
 

_______________________________________________
Ieprep mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep