One document matched: draft-ietf-atoca-requirements-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC4474 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml'>
<!ENTITY RFC4244 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4244.xml'>
<!ENTITY RFC5598 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5598.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="info" docName="draft-ietf-atoca-requirements-00.txt"
ipr="trust200902">
<front>
<title abbrev="Exigent Communications">Requirements, Terminology and Framework for Exigent
Communications</title>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs+ecrit@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author fullname="Steve Norreys" initials="S." surname="Norreys">
<organization>BT Group</organization>
<address>
<postal>
<street>1 London Road</street>
<city>Brentwood</city>
<region>Essex</region>
<code>CM14 4QP</code>
<country>UK</country>
</postal>
<phone>+44 1277 32 32 20</phone>
<email>steve.norreys@bt.com</email>
</address>
</author>
<author initials="B." surname="Rosen" fullname="Brian Rosen">
<organization>NeuStar, Inc. </organization>
<address>
<postal>
<street>470 Conrad Dr</street>
<city>Mars</city>
<region> PA </region>
<code>16046 </code>
<country>US </country>
</postal>
<phone> </phone>
<email>br@brianrosen.net
</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschhofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<date year="2010"/>
<area>RAI</area>
<workgroup>ATOCA</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Emergency</keyword>
<keyword>Early Warning</keyword>
<keyword>Exigent Communications</keyword>
<abstract>
<t>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.</t>
<t>This document provides
terminology, requirements and an architectural description for protocols exchanging alerts between IP-based end points.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<section title="Classical Early Warning Situations">
<t> 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. </t>
<t> 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. </t>
<t> This problem has been illustrated by the London underground bombing on July 7, 2006, as
described in a government report <xref target="July2005"/>. The UK authorities could only
use broadcast media and could not, for example, easily announce to the "walking wounded"
where to assemble. </t>
</section>
<section title="Exigent Communications">
<t>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 re-define the
actors that participate in the messaging communication. More precisely, exigent
communications is defined as: </t>
<t>
<list style="empty">
<t> Communication that requirs immediate action or remedy. Information about the reason
for action and details about the steps that have to be taken are provided in the alert
message.<vspace blankLines="1"/>
</t>
<t>An alert message (or warning message) is a cautionary advice about something imminent
(especially imminent danger or other unpleasantness). In the context of exigent
communication such an alert message refers to a future, ongoing or past event as the
signaling exchange itself may relate to different stages of the lifecycle of the
event. The alert message itself, and not the signaling protocol that convey it, provides sufficient
context about the specific state of the lifecycle the alert message refers to.</t>
</list>
</t>
<t>There are two types of basic communication models utilized for the distribution of alert messages and relevant for this document:</t>
<t>
<list style="hanging">
<t hangText="Alert Push Communication:">With this alert communication paradigm alert messages are sent to typically many Recipients without a prior explicit communication exchange soliciting the desire to receive the alerts. Typically, the criteria for becoming a Recipient are based on current location of the Recipient itself since alerts are targeted to a specific geographical region (an area immediately relevant to the emergency event). <vspace blankLines="1"/></t>
<t hangText="Alert Subscription Communication">The alert distribution in this category assumes that the
Recipient has indicated interest in receiving certain type of alerts using a protocol mechanism (for example, a subscribe event).
This opt-in subscription model allows Recipients to sign-up for receiving alerts independently of their current geographical location.
For example, parents may want to be alerted of emergencies
affecting the school attended by their children and adult children may need to know
about emergencies affecting elderly parents.
</t>
</list>
</t>
<t>
Note that the Receivers of the alerts may not necessarily be the typical end devices humans carry around, such as
mobile phones, Internet tablets, or laptops. Instead, alert distribution may well directly communicate with
displays in subway stations, or electronic bill boards. When a Receiver obtains such an alert then it may not necessarily
need to interact with a human (as the Recipient) but may instead use the alert 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.
</t>
<t>This document provides
terminology, requirements and an architectural description.
To avoid the bias towards a specific communication model or technology this documents utilizes the EMail architecture terminology from <xref
target="RFC5598"/>.</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="terminology" title="Terminology">
<t>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
<xref target="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. </t>
<t>This document reuses the terminology from <xref target="RFC5598"/>. For
editorial and consistency reasons parts of the text are repeated in this document and
modified as appropriate.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Responsible Actor Roles">
<t>The communication system used for the dissemination of alert messages builds on top of
existing communication infrastructure. At the time of writing this underlying communication
infrastructure is the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).
These distributed services consist of a variety of
actors playing different roles. On a high level we differentiate between the User, and the Message Handling Service (MHS) actors.
We will describe them in more detail below.
</t>
<section title="User Actors">
<t> Users are the sources and sinks of alert messages. Users can be people, organizations,
or processes. There are three types of Users:</t>
<t>
<list style="symbols">
<t> Authors </t>
<t> Recipients </t>
<t> Mediators </t>
</list>
</t>
<t>From the user 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. </t>
<section title="Author">
<t> The Author is responsible for creating the alert message, its contents, and its
intended recipients, even though the exact list of recipients may be unknown to the
Author at the time of writing the alert message. The MHS transfers the alert message
from the Author and delivers it to the Recipients. The MHS has an Originator role that
correlates with the Author role. </t>
<t>For most use cases the Author is a human creating a message.</t>
</section>
<section title="Recipient">
<t> The Recipient is a consumer of the delivered alert message. The MHS has a Receiver
role that correlates with the Recipient role.</t>
<t>For most use cases the Recipient is a human reading a message.</t>
</section>
<section title="Mediator">
<t> A Mediator receives, aggregates, reformulates, and redistributes alert messages among
</t>
<t> A Mediator attempts to preserve the original Author's information in the message it
reformulates but is permitted to make meaningful changes to the message content or
envelope. The MHS sees a new message, but users receive a message that they interpret as
being from, or at least initiated by, the Author of the original message. The role of a
Mediator is not limited to merely connecting other participants; the Mediator is
responsible for the new message. </t>
<t> A Mediator's role is complex and contingent, for example, modifying and adding content
or regulating which users are allowed to participate and when. The common example of
this role is an aggregator that accepts alert messages from a set of Originators and
distributes them to a potentially large set of Recipients. This functionality is similar
to a multicast, or even a broadcast. Recipients might have also indicated their interest
to receive certain type of alerts messages or they might implicitly get entitled to
receive specific alerts purely by their presence in a specific geographical region.
Hence, a Mediator might have additional information about the Recipients context and
might therefore be able to make a decision whether the Recipient is interested in
receiving a particular alert message. </t>
<t> A Gateway is a particularly interesting form of Mediator. It is a hybrid of User and
Relay that connects to other communication systems. Its purpose is to emulate a Relay.
</t>
</section>
</section>
<section title="Message Handling Service (MHS) Actors">
<t> The Message Handling Service (MHS) performs a single end-to-end transfer of warning
messages on behalf of the Author to reach the Recipient addresses.
As a pragmatic heuristic MHS actors actors generate, modify or look at only
transfer data, rather than the entire message. </t>
<t>
<xref target="actors-figure"/> shows the relationships among transfer participants.
Although it shows the Originator as distinct from the Author and Receiver as distinct from
Recipient, each pair of roles usually has the same actor. Transfers typically entail one
or more Relays. However, direct delivery from the Originator to Receiver is possible.
Delivery of warning messages within a single administrative boundary usually only involve
a single Relay. </t>
<t>
<figure anchor="actors-figure" title="Relationships Among MHS Actors">
<artwork>
<![CDATA[
++==========++ ++===========++
|| Author || || Recipient ||
++====++====++ ++===========++
|| /\
|| ||
\/ ||
+----------+ +---++----+
| | | |
/-+----------+----------------------------+---------+---\
| | | Message Handling | | |
| |Originator| System (MHS) |Receiver | |
| | | | | |
| +---++-----+ +---------+ |
| || /\ |
| || || |
| \/ || |
| +---------+ +---------+ +-+--++---+ |
| | Relay +======-=>| Relay +=======>| Relay | |
| +---------+ +----++---+ +---------+ |
| || |
| || |
| \/ |
| +---------+ |
| | Gateway +--> |
| +---------+ |
\-------------------------------------------------------/
Legend: === and || lines indicate primary (possibly
indirect) transfers or roles
]]></artwork>
</figure>
</t>
<section title="Originator">
<t> 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. </t>
<t> The Originator serves the Author and can be the same
entity. But its role in assuring validity means that it also represents the local
operator of the MHS, that is, the local ADministrative Management Domain (ADMD). </t>
<t> 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, enforcing local policies, and dealing with messages from the
Author that prove to be problematic for the Internet. The Originator is accountable for
the message content, even when it is not responsible for it. The Author creates the
message, but the Originator handles any transmission issues with it. </t>
</section>
<section title="Relay">
<t> 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., as available with SIP History Info <xref
target="RFC4244"/>) or security related protection (e.g., as available with SIP
Identity <xref target="RFC4474"/>) but does not modify the envelope information or the
message content semantics. </t>
<t> A Message Handling System (MHS) network consists of a set of Relays. This network is
above any underlying packet-switching network that might be used and below any Gateways
or other Mediators. </t>
</section>
<section title="Gateway">
<t> A Gateway is a hybrid of User and Relay that connects heterogeneous communication
infrastructures. Its purpose is to emulate a Relay and the closer it comes to this, the
better. A Gateway operates as a User when it needs the ability to modify message
content. </t>
<t> 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
user-to-user functionality between the communication services, despite differences in
their syntax and semantics. </t>
<t> The basic test of Gateway design is whether an Author on one side of a Gateway can
send a useful warning message to a Recipient on the other side, without requiring
changes to any components in the Author's or Recipient's communication service other
than adding the Gateway. To each of these otherwise independent services, the Gateway
appears to be a native participant. </t>
</section>
<section title="Receiver">
<t> The Receiver performs final delivery or sends the warning message to an alternate
address. In case of warning messages it is typically responsible for ensuring that the
appropriate user interface interactions are triggered. </t>
</section>
</section>
<!--
<section title="Administrative Actors">
<t> Administrative actors can be associated with different organizations, each with its own
administrative authority. This operational independence, coupled with the need for
interaction between groups, provides the motivation to distinguish among ADministrative
Management Domains (ADMDs). Each ADMD can have vastly different operating policies and
trust-based decision-making. One obvious example is the distinction between warning
messages that are exchanged within an closed group (such as alert messages received by
parents affecting the school attended by their children) and warning messages that
exchanged between independent organizations (e.g., in case of large scale disasters). The
rules for handling both types of traffic tend to be quite different. That difference
requires defining the boundaries of each, and this requires the ADMD construct. </t>
<t> Operation of communication systems that are used to convey alert messages are typically
carried out by different providers (or operators). Each can be an independent ADMD. The
benefit of the ADMD construct is to facilitate discussion about designs, policies and
operations that need to distinguish between internal issues and external ones. Most
significant is that the entities communicating across ADMD boundaries typically have the
added burden of enforcing organizational policies concerning external communications. At a
more mundane level, routing mail between ADMDs can be an issue, such as needing to route
alert messages between organizational partners over specially trusted paths. </t>
<t> The interactions of ADMD components are subject to the policies of that domain, which
cover concerns such as these:</t>
<t>
<list style="symbols">
<t>Reliability</t>
<t>Access control</t>
<t>Accountability</t>
<t>Content evaluation, adaptation, and modification</t>
</list>
</t>
</section>
-->
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Requirements" toc="default">
<t>Requirements that relate to the encoding and the content of alert messages are outside the
scope of this document. This document focuses on the protocols utilized to convey alert
messages only.</t>
<t>The requirements for the two main communication models are different and reflected in
separate sub-sections. For the Alert Push commnication model <xref target="push"/> the assumption is that the potential recipient's consent to provide alerts has been obtained a-priori and the message customization has externally been defined. There is no separate protocol exchange to indicate preferences. The consent may have been waived by law or has been provided when the receipient has registered for a service. As an alternative approach, the Alert Subscription communication model <xref target="sub"/> allows the potential alert receipient to indicate preferences about the type of alerts it is interested in. This mechanism to express interest is provided as part of the protocol exchange, namely via a subscription.</t>
<t>
<list style="hanging">
<t hangText="Req-G1:">
<vspace blankLines="1"/>The protocol solution MUST allow delivery of messages
simultaneously to a large audience. <vspace blankLines="1"/></t>
<t hangText="Req-G2:"><vspace blankLines="1"/>The protocol solution MUST be independent
of the underlying link layer technology. <vspace blankLines="1"/>
</t>
<t hangText="Req-G3:">
<vspace blankLines="1"/>The protocol solution MUST allow targeting notifications to
specific individuals and to groups of individuals.<vspace blankLines="1"/></t>
<t hangText="Req-R4:"><vspace blankLines="1"/>The protocol solution MUST allow a
Recipient to learn the identity of the Author of the alert message. <vspace blankLines="1"/></t>
</list>
</t>
<section anchor="sub" title="Requirements for a Alert Subscription Communication Model">
<t>The requirements listed below largely relate to the subscription phase when the potential recipient of alert messages
indicates preferences regarding the type of
alerts. </t>
<t>
<list style="hanging">
<t hangText="Req-S1:"><vspace blankLines="1"/>The protocol solution MUST allow a potential Recipient to
indicate the
language used by alert messages.
<vspace blankLines="1"/>
</t>
<t hangText="Req-S2:"><vspace blankLines="1"/>The protocol solution MUST allow a potential Recipient to
express the geographical area it wants to receive alerts about.<vspace blankLines="1"/></t>
<t hangText="Req-S3:"><vspace blankLines="1"/>The protocol solution MUST allow a potential Recipient to
indicate preferences about the type of alerts it wants to receive.<vspace
blankLines="1"/></t>
<t hangText="Req-S4:"><vspace blankLines="1"/>The protocol solution MUST allow a potential Recipient to
express preference for certain media types. The support for different media types depends
on the content of the warning message but also impacts the communication protocol.
This functionality is, for example, useful for hearing and vision impaired persons.<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section anchor="push" title="Requirements for a Alert Push Communication Model">
<t> </t>
<t>
<list style="hanging">
<t hangText="Req-P1:"><vspace blankLines="1"/>The protocol solution MUST allow delivery of alerts by utilizing he lower
layer infrastructure ensuring congestion control being considered. Network
layer multicast, anycast or broadcast mechanisms may be utilized. The topological network structure may be used for efficient alert distribution.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="IANA Considerations" toc="default">
<t>This document does not require actions by IANA.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Security considerations" toc="default" anchor="section-security">
<t>With the distribution of alert messages a number of security threats need to be addressed. Because of the nature of alerts it is quite likely that end device implementations will want to provide user interface enhancements to get the attention whenever an alert arrives. This creates additional attractiveness for adversaries to exploit an alert Message Handling System. We list the most important threats below that any solution will have to deal with.
</t>
<t>
<list style="hanging">
<t hangText="Originator Impersonation:">
<vspace blankLines="1"/> An attacker could then conceivably attempt to impersonate
the Originator of an alert message. This threat is particularly applicable to those deployment environments where authorization decisions are based on the identity of the Originator.<vspace
blankLines="1"/>
</t>
<t hangText="Alert Message Forgery:">
<vspace blankLines="1"/> An attacker could forge or alter an alert message in order
to convey custom messages to Recipients to get their immediate attention.<vspace
blankLines="1"/>
</t>
<t hangText="Replay:">
<vspace blankLines="1"/>An attacker could obtain previously distributed alert messages and to replay them at a later time in the hope that Recipients could be tricked into believing they are fresh. <vspace blankLines="1"/></t>
<t hangText="Unauthorized Distribution:">
<vspace blankLines="1"/> When a Receiver receives an alert message it has to determine
whether the Author distributing the alert messages is genuine to avoid accepting
messages that are injected by malicious entities with the potential desire to at least
get the immediate attention of the Recipient.<vspace blankLines="1"/></t>
<t hangText="Amplification Attack:">
<vspace blankLines="1"/>An attacker may use the Message Handling System to inject a single alert message for distribution that may then be instantly turned into potentially millions of alert messages for distribution.
</t>
</list>
</t>
<t>One important security challenge worth mentioning is related to authorization. When an alert message arrives at a Receiver, a software module at a host, then certain security checks can be performed to ensure that the message meets certain criteria. The final consumer of the alert message is, however, the Recipient, which in many cases is a human. From a security point of view the work split between the Recipient and the Receiver for making the authorization decision is important and the clarification of when to drop a message due to a failed security verfication by the Receiver. False positives may be fatal but accepting every alert message lowers the trustworthiness in the overall system.
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Acknowledgments" toc="default">
<!--
<t>This document reuses requirements captured outside the IETF, namely ETSI (with <xref
target="ETSI-TS-102-182"/>), and the 3GPP (with <xref target="3GPP-TR-22.968"/>). We would
like to thank the authors of these specifications for their work. Note, however, that only a
small subset of the requirements have been reflected that do not relate to specific
deployments, user interface aspects, detailed regulatory requirements, management and
operational considerations, and non-IP specific technologies.</t>
<t>We would like to thank Leopold Murhammer for his review in July 2007.</t>
-->
<t>This document re-uses a lot of text from <xref target="RFC5598"/>. The
authors would like to thank Dave Crocker for his work.</t>
<t>The authors would like to thank Martin Thomson, Carl Reed, and Tony Rutkowski for their comments.</t>
</section>
</middle>
<back>
<references title="Normative References"> &RFC2119; &RFC5598; </references>
<references title="Informative References"> &RFC4244; &RFC4474; <reference
anchor="July2005">
<front>
<title>Report of the 7 July Review Committee, ISBN 1 85261 878 7</title>
<author fullname="Greater London Authority" initials=" " surname=" ">
<organization>www.london.gov.uk</organization>
</author>
<date month="June" year="2006"/>
</front>
<seriesInfo name="(PDF document),"
value="http://www.london.gov.uk/assembly/reports/7july/report.pdf"/>
</reference>
<!-- <reference anchor="ETSI-TS-102-182">
<front>
<title>ETSI TS 102 182, V1.2.1 (2006-12), Technical Specification, Emergency
Communications (EMTEL); Requirements for communications from authorities/organizations
to individuals, groups or the general public during emergencies</title>
<author fullname=" " initials=" " surname=" ">
<organization>ETSI</organization>
</author>
<date month="December" year="2006"/>
</front>
<format target="" type="PDF"/>
</reference>
<reference anchor="3GPP-TR-22.968">
<front>
<title>3GPP TR 22.968, V1.0.0 (2007-04), 3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; Study for requirements for a Public
Warning System (PWS) Service (Release 8) </title>
<author fullname=" " initials=" " surname=" ">
<organization>ETSI</organization>
</author>
<date month="December" year="2006"/>
</front>
<format target="" type="PDF"/>
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 10:25:06 |