Last Modified: 2004-06-15
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.
Deliverables
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.
| 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. |
| RFC | Status | Title |
|---|---|---|
| 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 |
|
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 ). AGENDA: 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 draft-ietf-ieprep-framework-09.txt reviewed by IESG & were some comments Ken has them now (as of 5 minutes ago) Ken C: current efforts see slides summary 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: no 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: correct 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: right 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 janet: 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. question: 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. Question: 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. |