2.8.5 Internet Emergency Preparedness (ieprep)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-15

Scott Bradner <sob@harvard.edu>
Kimberly King <kimberly.s.king@saic.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Mailing Lists:
General Discussion: ieprep@ietf.org
To Subscribe: ieprep-request@ietf.org
In Body: subscribe ieprep
Archive: http://www.ietf.org/mail-archive/web/ieprep/index.html
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:
Done  Submit initial I-D of Requirements
Done  Submit initial I-D of Framework
Done  Submit initial I-D of Recommendations BCP
Done  Submit Requirements I-D to IESG for publication as an Informational RFC.
Done  Submit Framework I-D to IESG for publication as an Informational RFC.
Dec 03  Submit Recommendations I-D to IESG for publication as a BCP.
  • - draft-ietf-ieprep-framework-09.txt
  • - draft-ietf-ieprep-domain-req-01.txt
  • - draft-ietf-ieprep-domain-frame-01.txt
  • Request For Comments:
    RFC3487 I Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)
    RFC3523 I Internet Emergency Preparedness (IEPREP)Telephony Topology Terminology
    RFC3690 I IP Telephony Requirements for Emergency Telecommunication Service
    RFC3689 I General Requirements for Emergency Telecommunication Service

    Current Meeting Report

    Internet Emergency Preparedness WG (ieprep)

    Wednesday, August 4 at 1530-1730 PDT

    CHAIRS: Scott Bradner <sob@harvard.edu>
    Kimberly King <kimberly.s.king@saic.com>

    MINUTES: These minutes were created by Scott combining notes taken by Andrew Thiessen with the session jabber log (the jabber scribe was Lisa ).


    I: Agenda Bashing: Chair

    No agenda changes requested

    Scott Bradner: introduces agenda

    II: Ken Carlberg's presentation:

    Ken C:
    status update
    RFC 3689
    RFC 3690
    both completed

    Jon Peterson:
    AD comments on status of documents
    reviewed by IESG & were some comments
    Ken has them now (as of 5 minutes ago)

    Ken C:
    current efforts
    see slides

    single domain drafts
    things have just been cleaned up
    nothing on the list when the old version came out
    wants to wrap it up

    Scott Bradner: any comments? (none)
    will do a chair review and then a last call

    II: Fred Baker's presentation:
    Fred B - background of this talk is a combination of many meetings.

    On March 24th visited NCS they asked a lot of questions, working with the Air Force.

    On April 2nd had a meeting with Pete Fonash (sp?) - context of the meeting: interested in voice and video over IP, instant messaging and prioritized mail in a military context. Need maximum delay of 7 minutes guaranteed in both the civilian and military Internet.

    Col. Tim Gibson has been giving money for research. He wants to launch a missile and download the missile data over a satellite link and using TCP in a predictable fashion before launch.

    slides (applications)

    note well: talking about elastic services not real-time services

    Wouldn't it be nice if we could simply use diffserv? A little more to it than that. How do we keep script kiddies off of the network?

    two approaches slides
    proposals on the table with SPAWAR
    16 apps going into 12 queues using drop preference

    also talking with military in other than US countries

    drop precedence effects (slides)
    gives example of admiral controlling a fleet
    wants on demand bandwidth
    drop precedence doesn't really accomplish what the admiral wants, and its not predictable

    effects of a class definition slides
    see slide
    has the ability to make a guarantee to a lower bound
    allows to discriminate between various classes

    building preferential classes
    (see slide)
    military models are looking at between 5-7 classes total
    big problem: how do we keep the script kiddies from using

    identification, authentication, and authorization must authenticate the user after he requests the service

    Steve Norreys:
    are we talking about two networks here, or one Internet network where we have a GETS policy available to everyone

    Fred Baker:
    in a military network you can treat it as one network

    authenticate the user slide many ways to do it, someone must make a decision need appropriately strong credentials to make it work properly (crypto)

    Alex Trevenik:
    which protocol do you intend to use between the user and the network

    Fred Baker:
    we can discuss that

    Scott Bradner:
    asked Fred to talk about the philosophy and the concepts not a particular implementation

    Alex Trevenik:
    the selection of the choice of protocol between the end user and the network will be the most difficult

    are you starting with link layer?

    Fred Baker:
    going to have to go end to end
    access a database that is somewhere else
    needs to be able to scale
    needs to be able to identify people or people in a class
    anonymous access
    appropriate authentication, not individual

    shivar (??):
    wouldn't the AAA precedence need to be given to other protocols

    Fred Baker:
    not necessarily, it could become a DOS attack

    authorize the usage slide:
    talking about having some kind of limited access, that you cant get in unless you are authorized

    Steve Norreys:
    do you have to have location information?

    Fred Baker:
    those are questions that are specific to the authorization service

    Scott B:
    geopriv working group is working the location issue

    Bora Akyol:
    since the public network doesn't care about the DSCP code point does the service extend from the secure or whatever network, all the way to the end users hotspot?

    Fred Baker:
    it will have to be done contractually

    Bora Akyol:
    some networks may not allow you to come in with a specific DSCP codepoint

    Fred Baker:
    they still have to authenticate first before getting access to the network
    - once an IP address is authenticated, not every service being run from that IP needs the precedence missles and porn example

    Scott Bradner:
    note that diffserv design is that the code point can be overwritten

    Janet Gunn:
    the grey network is what's been contracted with the white network is Starbucks - if it goes through borders in Starbucks, the DSCP codepoint could be stripped off

    Fred Baker:

    Voice at the back:
    Preferentially, we want to have all gray, but we can't have it we must have a patchwork grey

    Scott B:
    Best case, but unlikely case.

    Fred Baker:

    let him/her request the service slide:

    If we let the user request the service, we could RSVP for a TCP session on a given port, with DSCP -- but we don't necessarily know the port - There be dragons here. "Traditionally", what a bandwidth broker does is different on every broker.

    Chris Christian (??):
    is the bandwidth broker doing admission control and assigning resources, or just authentication

    Fred Baker:
    just authentication

    Scott Bradner:
    In fact, if you know the sum total of the requests would exceed the capacity, something will have to be decided

    Fred Baker:
    reiterate must scale - anything that is IP, that is elastic, will get bandwidth in the network

    file transfer is particularly part of this slide: to have predictable TCP behavior, need something new - gives example from Amsterdam to Alaska

    Interesting work done recently by a guy named Case - Case has a computer on a network, 622 megabit network, he's the only one on it. He thinks he should be able to actually get 622 megabit, but he doesn't, he only gets 70 megabits. Case is happier, but not happy, after Cisco upgrade, when he gets 400 megabits. Problem is TCP. TCP has an averaging behavior, and ran into problems

    Australian defense slide:
    ship to shore radio, high BER - uses iterative process of sending datagrams and acking each datagram. Unless the error rate approaches 1, we're eventually going to get the file across. Throughput rate = effective-window / round-trip-time. RFC2581 and a CalTech FAST TCP project have different measurements Is there a way I could measure capacity and choose an appropriate window to maximize throughput rate? Srinivasan was figuring out how to send two packets across a link to have a micro-measurement of the rate of the link. That's one data point. Can we generate a filtered mean rate? That allows us to send at a more optimal rate to get high throughput. Next-generation SACK procedures can increase the effective window. I can keep transmitting at the calculated rate and pick up the retransmissions later. Now I can deliver a whole file at a predictable time. Electronic mail could be a privileged service, attempting to deliver each email in a finite known time. But how can this work, when I asserted an identity only known to the first domain in the email delivery? Today, when I connect to my email server and start downloading mail, I have to download them all before seeing one of them is super important. We're going to have to apply priorities every step of the way: from me to my SMTP server, from that SMTP serer to the ISP, and so on to the end machine. Another thing we need is quick failure. If something's going to take an hour rather than 7 minutes, don't just leave it in the queue, let me know.

    Janet Gunn:
    How do we prevent the spammers from putting priority on their messages?

    Fred Baker:
    don't authorize them

    what if they authorize themselves?

    Fred Baker:
    I don't know that answer, it's going to have to be addressed.

    Kimberley King:
    is the military saying that they want an end to end solution? satcom has some interesting capabilities if its not encrypted

    Fred Baker:
    US Navy is in fact looking for E2E solutions including undersea cable hops. They drew a picture of a ship on the way to Bahrain from Norfolk - The message had to go undersea cable to Italy, in air to ship, with a hop to Bahrain in there. But to authenticate it, it had to go to Norfolk. It ended up with a 2 sec roundtrip delay.

    Steve Norreys:
    I'm stuck on the differences between the military solution, where there's a hierarchy of overrides, with the civilian emergency case. Compare the CEO and the cleaner, trying to use the emergency services, where the cleaner is actually the important person communicating with emergency services.

    Fred Baker:
    right, We can't just take all the routine traffic and put it in the dumpster. At the beginning, I was saying that we do not want to assign priorities. Priority, as a scheduling algorithm, is a way to reduce jitter. So yes, you actually want to reserve traffic for *each* traffic class, not bump the lowest priorities right off. You could use round-robin to allocate for each for the classes. If some class isn't using its bandwidth, it's proportionally allocated to the other classes. So normally that means that routine traffic gets 100% of bandwidth.

    Aaron Falk:
    1) want the slides
    2) likelihood that you will have small stream with big files over big delay links are a corner case - not sure that there is a problem that needs to be solved here
    3) when you started talking about the bandwidth broker, flag set off.

    Fred Baker:
    because none work

    Aaron Falk:
    you are taking something that doesn't work, and making it more complicated

    Fred Baker:
    This isn't the Internet2 bandwidth broker; it's not mosaic.

    Ken Carlberg:
    In the last slide, you had two items, priority and smptauth Three years ago a fellow submitted a draft on prioritized SMTP. It's expired but maybe good background reading, including the list discussion at that time.

    Bora Akyol:
    Do you expect somebody from the agency to authenticate themselves to their NAS server, then use that to access a server in some enterprise?

    Fred Baker:
    You'd have to talk to the government, but I wouldn't have them going to a single-point-of-failure server to do that. I'd want an instance of that server in each of UUNet's datacenters, for example. In the military probably one auth throughout. When you talk to GETS (?) it's different

    Janet Gunn:
    This is a response to Steve: to the extent this corresponds to what's done in WPS and GETS, this needs to be available to everybody, and you don't know who's going to be important ahead of time. That's different from the emergency preparedness where we know who needs the special service.

    what class will be used for an elastic service?

    Fred Baker:
    elastic traffic will need a class

    IV - Scott Bradner:
    where do we go from here is next on the agenda? We have one more item on our charter, a recommendations I-D, recommending to service providers, ISPs, how to do something using available technology. We were hoping to use the ID Fred did before to meet that milestone since he covered the gamut of things assumed to be required in emergency cases. I think some of these things are potentially important, some we can do something with, but not all of them. How we can constrain the problem if ieprep to something we can deal with. Some of the work has limited applicability to a single domain with unified authentication

    Aaron Falk:
    The individual pieces have a lot in common with a lot of other stuff going on maybe a needs statement should be sent out

    Scott Bradner:
    The first thing this group did was develop requirements for SIP resource priority headers, then shifted that work to SIP WG to actually do the work. We give the requirements, not how to do it. I would propose to interact with the IESG to extend the charter to work on the things Baker describes here - but as requirements, not as solutions.

    Steve Norreys:
    The requirements need to be very clear that this is not ETS we're talking about here. To me, ETS as been defined in ITU and so forth is the 999, 911 services.

    Scott Bradner:
    just to clarify ETS is not 911

    Steve Norreys:
    lets just make that clear in the charter

    Jon Peterson:
    there is a design team in SIP addressing 911

    Scott Bradner:
    two big issues with E911 in VoIP - where are you and where is the PSAP?

    Jon Peterson:
    Some high level architecture would be useful for the industry.

    Scott Bradner:
    Important work, just not in the charter of this WG.

    Aaron Falk:
    I found that many people making design decisions are not people you'd typically find at an IETF meeting though many are in this room. I chaired TCP over Satellite WG,.. people don't necessarily know the right combination of RFCs to use to put the network It may be useful not only to make requirements to other WGs, but also to explain what services providers should use to put together ETS services. ETS == Emergency Telecommunication

    Ken Carlberg:
    RFC 3889 provides some examples.

    Scott Bradner:
    This working group is about non-911 emergency communications. But if you're saying that clue exists outside the IETF, I definitely want to encourage input, etc.

    Is this more for the Internet or for military or private networks has this WG been mainly involved with the public internet not private?

    Scott Bradner:
    the IETF has had a schism for a long time about whether something that is specific to a private internet is out of scope for the IETF but this WG is to look at the public internet, but those technologies are not turned off on private networks.

    Does anybody think it's a bad idea to pursue charter change with the IESG and IAB?
    (no pushback)
    Any other issues?

    Andy Thiessen:
    I work with a government sponsored program named SafeCom, we work with fire, police and EMS. (www.safecomprogram.gov) When you look at first-responder infrastructure, it's owned by the states and locals themselves. This work is certainly of interest to SafeConn and first responders. We want to liaise with IETF to see how we can best use the good work done here. I've done this before, an "easy reading guide" for this.

    Scott Bradner:
    It would be great if you could do this as a I-D

    Ken Carlberg:
    question about name spaces with the SIP RP header - who handles it?

    Scott Bradner:
    Once we handed the priority headers to SIPPING, that's their bailywick. It's not our responsibility any more. You can join that list and discuss the topic there.


    Preferential Elastic Services