| ATOCA | H. Schulzrinne |
| Internet-Draft | Columbia University |
| Intended status: Informational | S. Norreys |
| Expires: September 11, 2012 | BT Group |
| B. Rosen | |
| NeuStar, Inc. | |
| H. Tschofenig | |
| Nokia Siemens Networks | |
| March 12, 2012 |
Requirements, Terminology and Framework for Exigent Communications
draft-ietf-atoca-requirements-03.txt
Before, during and after emergency situations various agencies need to provide information to a group of persons or to the public within a geographical area. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions.
This document provides terminology, requirements and an architectural description for protocols exchanging alerts between IP-based end points.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
During large-scale emergencies, public safety authorities need to reliably communicate with citizens in the affected areas, to provide warnings, indicate whether citizens should evacuate and how, and to dispel misinformation. Accurate information can reduce the impact of such emergencies.
Traditionally, emergency alerting has used church bells, sirens, loudspeakers, radio and television to warn citizens and to provide information. However, techniques, such as sirens and bells, provide limited information content; loud speakers cover only very small areas and are often hard to understand, even for those not hearing impaired or fluent in the local language. Radio and television offer larger information volume, but are hard to target geographically and do not work well to address the “walking wounded” or other pedestrians. Both are not suitable for warnings, as many of those needing the information will not be listening or watching at any given time, particularly during work/school and sleep hours.
This problem has been illustrated by the London underground bombing on July 7, 2006, as described in a government report [July2005]. The UK authorities could only use broadcast media and could not, for example, easily announce to the "walking wounded" where to assemble.
With the usage of the term 'Exigent Communications' this document aims to generalize the concept of conveying alerts to IP-based systems and at the same time to describe the actors that participate in the messaging communication. More precisely, exigent communications is defined as:
On a high level the communication occurs in two phases with the subscription phase sometimes being implicit:
Note that an alert receiver software modules may not necessarily only be executed on end devices humans typically carry around, such as mobile phones, Internet tablets, or laptops. Instead, alerts may well be directly sent to displays in subway stations, or electronic bill boards. Furthermore, a software module that obtains an alert may not necessarily need to interact with a human (as the Recipient) but may instead use it as input to another process to trigger automated behaviors, such as closing vents during a chemical spill or activating sirens or other warning systems in commercial buildings.
This document provides terminology, requirements and an architectural description. Note that the requirements focus on the communication protocols for subscription and alert delivery rather than on the content of the alert message itself. With the usage of CAP these alert message content requirements are delegated to the Authors and Originators of alerts.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], with the important qualification that, unless otherwise stated, these terms apply to the design of a protocol conveying warning messages, not its implementation or application.
Alert messages are typically produced by humans and consumed by users, Authors and Recipients in our system, are the sources and sinks of alert messages.
The Author is a human responsible for creating the content of the alert message, and to make a decision about the intended recipients, even though the exact list of recipients may be unknown to the Author at the time of writing the alert message. Instead, the recipients may, for example, be described in terms of a geographical region, or recipients with interest in a specific alert type.
The Recipient is a consumer of the delivered alert message. It is a human reading the alert message.
From the user's perspective, all alert message transfer activities are performed by a monolithic Message Handling Service (MHS), even though the actual service can be provided by many independent organizations. The Message Handling Service (MHS) performs a single end-to-end transfer of warning messages on behalf of the Author to reach the Recipients.
Figure 1 shows the relationships among transfer participants. Transfers typically entail one or more Relays. However, direct delivery from the Originator to Receiver is possible.
++==========++ ++===========++
|| Author || || Recipient ||
++====++====++ ++===========++
|| /\
|| ||
\/ ||
+----------+ +---++----+
| | | |
/-+----------+----------------------------+---------+---\
| | | Message Handling | | |
| |Originator| System (MHS) |Receiver | |
| | | | | |
| +---++-----+ +---------+ |
| || /\ |
| || || |
| \/ || |
| +---------+ +---------+ +-+--++---+ |
| | Relay +======-=>| Relay +=======>| Relay | |
| +---------+ +----++---+ +---------+ |
| || |
| || |
| \/ |
| +---------+ |
| | Gateway +--> |
| +---------+ |
\-------------------------------------------------------/
Legend: === and || lines indicate primary (possibly
indirect) transfers or roles
The Originator ensures that a warning message is valid for transfer and then submits it to a Relay. A message is valid if it conforms to both communication and warning message encapsulation standards and local operational policies. The Originator can simply review the message for conformance and reject it if it finds errors, or it can create some or all of the necessary information.
The Originator serves the Author and can be the same entity in absence of a human crafting alert messages.
The Originator also performs any post-submission, Author-related administrative tasks associated with message transfer and delivery. Notably, these tasks pertain to sending error and delivery notices, and enforcing local policies. The Author creates the message, but the Originator handles any transmission issues with it.
The Relay performs MHS-level transfer-service routing and store-and-forward, by transmitting or retransmitting the message to its Recipients. The Relay may add history information (e.g., the SIP History Info [RFC4244] serves as a good example of the type of information that may be conveyed) or security related protection (e.g., as available with SIP Identity [RFC4474]) but does not modify the envelope information or the message content semantics.
A Message Handling System (MHS) network consists of a set of Relays. This MHS network is typically above any underlying IP network but may involve technologies like IP multicast.
A Gateway connects heterogeneous communication infrastructures and its purpose is to emulate a Relay and the closer it comes to this, the better. A Gateway needs the ability to modify message content.
Differences between the different communication systems can be as small as minor syntax variations, but they usually encompass significant, semantic distinctions. Hence, the Relay function in a Gateway presents a significant design challenge, if the resulting performance is to be seen as nearly seamless. The challenge is to ensure end-to-end communication between the communication services, despite differences in their syntax and semantics.
The Receiver performs final delivery and is typically responsible for ensuring that the appropriate user interface rendering is executed to interact with the Recipient.
Section 1 describes the basic two steps that are involved with the alert message handling, namely subscription and alert delivery. From an architectural point of view there are, however, a few variations possible depending on the characteristics of the subscription process and the style of message delivery. This section offers more details on the communication architecture. Note that this document does not mandate a specific deployment architecture. Instead it aims to illustrate how various different protocol components fit together to present the reader with the 'big picture'.
We start our description with the so-called "school closed" example where school authorities send alerts to all parents to notify them about the fact that their children cannot attend school. Parents subscribe to these events when their children start attending the school and unsubscribe when they are finished with a particular school. The subscription procedures establishes some form of group communication by requiring an initial registration procedure. Typically, alert messages stay within the closed group and are not shared with others and alert message delivery is point-to-point with whatever communication protocol is most suitable. This also means that the alerts reach those who have subscribed rather than those who are in the vicinity of the school. The number of Recipients is typically rather small, in the order of hundreds to several thousands.
A variation of the "school closed" example is an explicit subscription model where no closed group pattern exists. The main difference to the former case is in the authorization model. Consider a traveler who would like to receive weather alerts about a specific geographical region. He may have to manually search for how to subscribe to alerts for the desired region, potentially looking a different subscription points for different types of alerts. As an automated version of this procedure some form of discovery may help to find these subscription servers. The approach described in [I-D.rosen-ecrit-lost-early-warning] is one possible way to discovery such alert subscription servers. The number of alert message Recipients is much larger than in the previous school example but will typically stay below the millions.
These alert delivery examples are supported by a number of standardized communication protocols, such as SIP, XMPP, eMail, or RSS feeds.
Note that there are optimizations for application layer alert delivery that mimic a multicast delivery with the help of Relays. However, a subscription is still necessary by the Receiver and the last-hop delivery of the alert is still done using unicast transmission.
While these two examples are important for many deployments they are not in focus of the ATOCA working group.
With the next category we move to a scenario where large number of Recipients shall be notified but the subscription itself is implicit, as it is the case when persons are within a specific region that can easily be reached by making use of broadcast link layer technologies. The placement of the actors from Figure 1 is thereby important. An Originator distributes the alert message to Relays within the geographically affected area. Those Relays are located within Internet Service Providers so that multicast and broadcast communication protocols can be utilized for efficient distribution to a large number of Recipients within the affected area. When the alert message delivery has to be accomplished at the network layer then various requirements, such as the ability to traverse NATs and firewalls, have to be met by such a protocol. In this scenario the number of alert message Recipients is very large, potentially in the millions.
As a variation of the previously described model consider an alert distribution with subscriptions to the alerts. Figure 2 shows the architecture.
A discovery server ensures that Receivers are able to learn the local alert distribution servers. Once a Receiver had discovered a local alert distribution server it sends a subscribe message to it. As a response, it will receive information about the security credentials the alert distribution server is going to use for subsequent alert delivery.
When an Author creates an alert for distribution the affected region will be indicated and so the alert will be sent to a Relay within the realm of the local alert distribution server and a notification will be sent to all the subscribed Receivers.
,-----------.
| Discovery |
| Server |
`...........'
:
:
,''''''''''''''''''''''''\ :
| Local ,------. | :
| Alert | Local| | : ...................
| Distribution | Relay|.|..: Alert | +------+ Author |
| Server `......'-+<------------------+-|Sender| O |
| | | Notification | | | /|\ |
'`'''''''''''''''''+'''''' | +------+ / \ |
^ Alert | `-----------------'
Subscr. +---------+
| | Notification
| |
| V
.....................
| +------+ Recipient|
| |Recvr | O |
| | | /|\ |
| +------+ / \ |
`-------------------'
The requirements listed below focus on the goal of mass alert distribution, which has to utilize multicast/broadcast communication for scalability reasons. The requirements for point-to-point alert delivery are shown in Appendix Appendix A for completeness reasons only since the focus of the IETF ATOCA working group is on the multicast/broadcast alert delivery.
This document does not require actions by IANA.
Figure 1 shows the actors for delivering an alert message assuming that a prior subscription has taken place already. The desired security properties of an MHS for conveying alerts will depend on the number of administrative domains involved. Each administrative domain can have vastly different operating policies and trust-based decision-making. One obvious example is the distinction between alert messages that are exchanged within an closed group (such as alert messages received by parents affecting the school attended by their children) and alert messages that are exchanged between independent organizations (e.g., in case of large scale disasters). The rules for handling both types of communication architectures tend to be quite different. That difference requires defining the boundaries of each.
Operation of communication systems that are used to convey alert messages are typically carried out by different providers (or operators). Since each be in operated in an independent administrative domain it is useful to consider administrative domain boundaries in the description to facilitate discussion about designs, policies and operations that need to distinguish between internal issues and external entities. Most significant is that the entities communicating across administrative boundaries typically have the added burden of enforcing organizational policies concerning external communications. For example, routing alerts between administrative domains can create requirements, such as needing to route alert messages between organizational partners over specially trusted paths.
The communication interactions are subject to the policies of that domain, which cover concerns such as these:
Many communication systems make the distinction of administrative domains since they impact the requirements on security solutions. However, with the distribution of alert messages a number of additional security threats need to be addressed. Due to the nature of alerts it is quite likely that end device implementations will offer user interface enhancements to get the Recipients attention whenever an alert arrives, which is an attractive property for adversaries to exploit. Below we list the most important threats any solution will have to deal with.
One important security challenge is related to authorization. When an alert message arrives at the Receiver then certain security checks may need to be performed to ensure that the alert message meets certain criteria. The final consumer of the alert message is, however, the Recipient - a human. From a security point of view the work split between the Recipient and the Receiver for making the authorization decision is important, particularly when an alert message is rejected due to a failed security verification by the Receiver. False positives may be fatal but accepting every alert message lowers the trustworthiness in the overall system.
This document re-uses text from [RFC5598]. The authors would like to thank Dave Crocker for his work.
The authors would like to thank Martin Thomson, Carl Reed, Leopold Murhammer, and Tony Rutkowski for their comments.
At IETF#79 the following persons provided feedback leading to changes in this document: Keith Drage, Scott Bradner, Ken Carberg, Keeping Li, Martin Thomson, Igor Faynberg, Mark Wood, Peter Saint-Andre.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5598] | Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. |
| [RFC4244] | Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. |
| [RFC4474] | Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. |
| [RFC5582] | Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009. |
| [I-D.rosen-ecrit-lost-early-warning] | Rosen, B, Schulzrinne, H and H Tschofenig, "A Uniform Resource Name (URN) for Early Warning Emergency Services and Location-to-Service Translation (LoST) Protocol Usage", Internet-Draft draft-rosen-ecrit-lost-early-warning-01, July 2009. |
| [July2005] | , , "Report of the 7 July Review Committee, ISBN 1 85261 878 7", (PDF document), http://www.london.gov.uk/assembly/reports/7july/report.pdf, June 2006. |
The requirements listed below refer to the alert subscription phase as it is used to tailor alert message delivery in a point-to-point alert delivery scenario. As noted in the main part of the document these requirements are not the main focus of the ATOCA work.