< draft-ietf-atoca-requirements-00.txt		draft-ietf-atoca-requirements-01.txt >
	ATOCA H. Schulzrinne		ATOCA H. Schulzrinne
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Informational S. Norreys		Intended status: Informational S. Norreys
	Expires: March 27, 2011 BT Group		Expires: July 19, 2011 BT Group
	B. Rosen		B. Rosen
	NeuStar, Inc.		NeuStar, Inc.
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	September 23, 2010		January 15, 2011
	Requirements, Terminology and Framework for Exigent Communications		Requirements, Terminology and Framework for Exigent Communications
	draft-ietf-atoca-requirements-00.txt		draft-ietf-atoca-requirements-01.txt
	Abstract		Abstract
	Before, during and after emergency situations various agencies need		Before, during and after emergency situations various agencies need
	to provide information to a group of persons or to the public within		to provide information to a group of persons or to the public within
	a geographical area. While many aspects of such systems are specific		a geographical area. While many aspects of such systems are specific
	to national or local jurisdictions, emergencies span such boundaries		to national or local jurisdictions, emergencies span such boundaries
	and notifications need to reach visitors from other jurisdictions.		and notifications need to reach visitors from other jurisdictions.
	This document provides terminology, requirements and an architectural		This document provides terminology, requirements and an architectural
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 27, 2011.		This Internet-Draft will expire on July 19, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Classical Early Warning Situations . . . . . . . . . . . . 3		1.1. Classical Early Warning Situations . . . . . . . . . . . . 3
	1.2. Exigent Communications . . . . . . . . . . . . . . . . . . 3		1.2. Exigent Communications . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 5		3. Alert Delivery Architecture . . . . . . . . . . . . . . . . . 5
	3.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Responsible Actor Roles . . . . . . . . . . . . . . . . . 5
	3.1.1. Author . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1.1. User Actors . . . . . . . . . . . . . . . . . . . . . 5
	3.1.2. Recipient . . . . . . . . . . . . . . . . . . . . . . 5		3.1.2. Message Handling Service (MHS) Actors . . . . . . . . 6
	3.1.3. Mediator . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Message Handling Service (MHS) Actors . . . . . . . . . . 6
	3.2.1. Originator . . . . . . . . . . . . . . . . . . . . . . 7
	3.2.2. Relay . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2.3. Gateway . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2.4. Receiver . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1. Requirements for a Alert Subscription Communication		4.1. Requirements for Alert Subscription . . . . . . . . . . . 9
	Model . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. Requirements for Alert Message Delivery . . . . . . . . . 9
	4.2. Requirements for a Alert Push Communication Model . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Security considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	1.1. Classical Early Warning Situations		1.1. Classical Early Warning Situations
	During large-scale emergencies, public safety authorities need to		During large-scale emergencies, public safety authorities need to
	reliably communicate with citizens in the affected areas, to provide		reliably communicate with citizens in the affected areas, to provide
	warnings, indicate whether citizens should evacuate and how, and to		warnings, indicate whether citizens should evacuate and how, and to
	dispel misinformation. Accurate information can reduce the impact of		dispel misinformation. Accurate information can reduce the impact of
	such emergencies.		such emergencies.
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	An alert message (or warning message) is a cautionary advice about		An alert message (or warning message) is a cautionary advice about
	something imminent (especially imminent danger or other		something imminent (especially imminent danger or other
	unpleasantness). In the context of exigent communication such an		unpleasantness). In the context of exigent communication such an
	alert message refers to a future, ongoing or past event as the		alert message refers to a future, ongoing or past event as the
	signaling exchange itself may relate to different stages of the		signaling exchange itself may relate to different stages of the
	lifecycle of the event. The alert message itself, and not the		lifecycle of the event. The alert message itself, and not the
	signaling protocol that convey it, provides sufficient context		signaling protocol that convey it, provides sufficient context
	about the specific state of the lifecycle the alert message refers		about the specific state of the lifecycle the alert message refers
	to.		to.
	There are two types of basic communication models utilized for the		Communication typically occurs in two phases:
	distribution of alert messages and relevant for this document:
	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).
	Alert Subscription Communication The alert distribution in this		Subscription: In this step Recipients express their interest to
	category assumes that the Recipient has indicated interest in		receive certain types of alerts and happens prior to the actual
	receiving certain type of alerts using a protocol mechanism (for		delivery of the alert. This expression of interest may be in form
	example, a subscribe event). This opt-in subscription model		of an explicit communication step by having the Receiver sending a
	allows Recipients to sign-up for receiving alerts independently of		subscription message potentially with an indication of the type of
	their current geographical location. For example, parents may		alerts they are interested in, the duration of the subscription
	want to be alerted of emergencies affecting the school attended by		and a number of other indicators. 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		their children and adult children may need to know about
	emergencies affecting elderly parents.		emergencies affecting elderly parents. The subscription step may,
			however, also happen outside the Internet communication
			infrastructure but rather by the Recipient signing a contract and
			thereby agreeing to receive certain alerts. Additionally, certain
			subscriptions may happen without the Recipient's explicit consent
			and without the Receiver sending a subscription. For example, a
			Tsunami flood alert may be delievered to Recipients in case they
			are located in a specific geographical area.
	Note that the Receivers of the alerts may not necessarily be the		It is important to note that a protocol interaction initiated by
	typical end devices humans carry around, such as mobile phones,		the Receiver may need to take place to subscribe to certain types
	Internet tablets, or laptops. Instead, alert distribution may well		of alerts. In some other cases the subscription does not require
	directly communicate with displays in subway stations, or electronic		such interaction from the Receiver. Orthogonal to the need to
	bill boards. When a Receiver obtains such an alert then it may not		have a protocol interaction is the question of opt-in vs. opt-out.
	necessarily need to interact with a human (as the Recipient) but may		This is a pure policy decision and largely outside the scope of a
	instead use the alert as input to another process to trigger		technical specification.
	automated behaviors, such as closing vents during a chemical spill or
	activating sirens or other warning systems in commercial buildings.		Alert Delivery In this step the alert message is distributed to one
			or multiple Receivers. The Receiver as a software module then
			presents the alert message to the Receipient. The alert encoding
			is accomplished via the Common Alerting Protocol (CAP) and such an
			alert message contains useful information needed for dealing with
			the imminent danger.
			Note that alert Receivers as software modules may not necessarily
			only be executed on end devices humans typically 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.
	This document provides terminology, requirements and an architectural		This document provides terminology, requirements and an architectural
	description. To avoid the bias towards a specific communication		description. Note that the requirements focus on the communication
	model or technology this documents utilizes the EMail architecture		protocols for subscription and alert delivery rather than on the
	terminology from [RFC5598].		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.
	2. Terminology		2. Terminology
	The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119], with the		document are to be interpreted as described in [RFC2119], with the
	important qualification that, unless otherwise stated, these terms		important qualification that, unless otherwise stated, these terms
	apply to the design of a protocol conveying warning messages, not its		apply to the design of a protocol conveying warning messages, not its
	implementation or application.		implementation or application.
	This document reuses the terminology from [RFC5598]. For editorial		3. Alert Delivery Architecture
	and consistency reasons parts of the text are repeated in this
	document and modified as appropriate.
	3. Responsible Actor Roles		This section illustrates the roles useful for alert delivery.
			3.1. Responsible Actor Roles
	The communication system used for the dissemination of alert messages		The communication system used for the dissemination of alert messages
	builds on top of existing communication infrastructure. At the time		builds on top of existing communication infrastructure. At the time
	of writing this underlying communication infrastructure is the		of writing this underlying communication infrastructure is the
	Session Initiation Protocol (SIP) and the Extensible Messaging and		Session Initiation Protocol (SIP) and the Extensible Messaging and
	Presence Protocol (XMPP). These distributed services consist of a		Presence Protocol (XMPP). These distributed services consist of a
	variety of actors playing different roles. On a high level we		variety of actors playing different roles. On a high level we
	differentiate between the User, and the Message Handling Service		differentiate between the User, and the Message Handling Service
	(MHS) actors. We will describe them in more detail below.		(MHS) actors. We will describe them in more detail below.
	3.1. User Actors		3.1.1. User Actors
	Users are the sources and sinks of alert messages. Users can be		Users are the sources and sinks of alert messages. We differentiate
	people, organizations, or processes. There are three types of Users:		between two types of users:
	o Authors		o Authors
	o Recipients		o Recipients
	o Mediators
	From the user perspective, all alert message transfer activities are		From the user perspective, all alert message transfer activities are
	performed by a monolithic Message Handling Service (MHS), even though		performed by a monolithic Message Handling Service (MHS), even though
	the actual service can be provided by many independent organizations.		the actual service can be provided by many independent organizations.
	3.1.1. Author		3.1.1.1. Author
	The Author is responsible for creating the alert message, its		The Author is a human responsible for creating the alert message, its
	contents, and its intended recipients, even though the exact list of		contents, and its intended recipients, even though the exact list of
	recipients may be unknown to the Author at the time of writing the		recipients may be unknown to the Author at the time of writing the
	alert message. The MHS transfers the alert message from the Author		alert message. The MHS transfers the alert message from the Author
	and delivers it to the Recipients. The MHS has an Originator role		and delivers it to the Recipients.
	that correlates with the Author role.
	For most use cases the Author is a human creating a message.
	3.1.2. Recipient
	The Recipient is a consumer of the delivered alert message. The MHS
	has a Receiver role that correlates with the Recipient role.
	For most use cases the Recipient is a human reading a message.
	3.1.3. Mediator
	A Mediator receives, aggregates, reformulates, and redistributes
	alert messages among
	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.
	A Mediator's role is complex and contingent, for example, modifying		3.1.1.2. Recipient
	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.
	A Gateway is a particularly interesting form of Mediator. It is a		The Recipient is a consumer of the delivered alert message. It is a
	hybrid of User and Relay that connects to other communication		human reading the alert message.
	systems. Its purpose is to emulate a Relay.
	3.2. Message Handling Service (MHS) Actors		3.1.2. Message Handling Service (MHS) Actors
	The Message Handling Service (MHS) performs a single end-to-end		The Message Handling Service (MHS) performs a single end-to-end
	transfer of warning messages on behalf of the Author to reach the		transfer of warning messages on behalf of the Author to reach the
	Recipient addresses. As a pragmatic heuristic MHS actors actors		Recipient. As a pragmatic heuristic MHS actors actors generate,
	generate, modify or look at only transfer data, rather than the		modify or look at only transfer data, rather than the entire message.
	entire message.
	Figure 1 shows the relationships among transfer participants.		Figure 1 shows the relationships among transfer participants.
	Although it shows the Originator as distinct from the Author and		Although it shows the Originator as distinct from the Author and
	Receiver as distinct from Recipient, each pair of roles usually has		Receiver as distinct from Recipient, each pair of roles usually has
	the same actor. Transfers typically entail one or more Relays.		the same actor. Transfers typically entail one or more Relays.
	However, direct delivery from the Originator to Receiver is possible.		However, direct delivery from the Originator to Receiver is possible.
	Delivery of warning messages within a single administrative boundary		Delivery of warning messages within a single administrative boundary
	usually only involve a single Relay.		usually only involve a single Relay.
	++==========++ ++===========++		++==========++ ++===========++
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 37 ¶
	| +---------+ |		| +---------+ |
	| | Gateway +--> |		| | Gateway +--> |
	| +---------+ |		| +---------+ |
	\-------------------------------------------------------/		\-------------------------------------------------------/
	Legend: === and || lines indicate primary (possibly		Legend: === and || lines indicate primary (possibly
	indirect) transfers or roles		indirect) transfers or roles
	Figure 1: Relationships Among MHS Actors		Figure 1: Relationships Among MHS Actors
	3.2.1. Originator		3.1.2.1. Originator
	The Originator ensures that a warning message is valid for transfer		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		and then submits it to a Relay. A message is valid if it conforms to
	both communication and warning message encapsulation standards and		both communication and warning message encapsulation standards and
	local operational policies. The Originator can simply review the		local operational policies. The Originator can simply review the
	message for conformance and reject it if it finds errors, or it can		message for conformance and reject it if it finds errors, or it can
	create some or all of the necessary information.		create some or all of the necessary information.
	The Originator serves the Author and can be the same entity. But its		The Originator serves the Author and can be the same entity in
	role in assuring validity means that it also represents the local		absence of a human crafting alert messages.
	operator of the MHS, that is, the local ADministrative Management
	Domain (ADMD).
	The Originator also performs any post-submission, Author-related		The Originator also performs any post-submission, Author-related
	administrative tasks associated with message transfer and delivery.		administrative tasks associated with message transfer and delivery.
	Notably, these tasks pertain to sending error and delivery notices,		Notably, these tasks pertain to sending error and delivery notices,
	enforcing local policies, and dealing with messages from the Author		enforcing local policies, and dealing with messages from the Author
	that prove to be problematic for the Internet. The Originator is		that prove to be problematic for the Internet. The Originator is
	accountable for the message content, even when it is not responsible		accountable for the message content, even when it is not responsible
	for it. The Author creates the message, but the Originator handles		for it. The Author creates the message, but the Originator handles
	any transmission issues with it.		any transmission issues with it.
	3.2.2. Relay		3.1.2.2. Relay
	The Relay performs MHS-level transfer-service routing and store-and-		The Relay performs MHS-level transfer-service routing and store-and-
	forward, by transmitting or retransmitting the message to its		forward, by transmitting or retransmitting the message to its
	Recipients. The Relay may add history information (e.g., as		Recipients. The Relay may add history information (e.g., as
	available with SIP History Info [RFC4244]) or security related		available with SIP History Info [RFC4244]) or security related
	protection (e.g., as available with SIP Identity [RFC4474]) but does		protection (e.g., as available with SIP Identity [RFC4474]) but does
	not modify the envelope information or the message content semantics.		not modify the envelope information or the message content semantics.
	A Message Handling System (MHS) network consists of a set of Relays.		A Message Handling System (MHS) network consists of a set of Relays.
	This network is above any underlying packet-switching network that		This MHS network is above any underlying packet-switching network
	might be used and below any Gateways or other Mediators.		that might be used and below any Gateways.
	3.2.3. Gateway		3.1.2.3. Gateway
	A Gateway is a hybrid of User and Relay that connects heterogeneous		A Gateway is a hybrid of User and Relay that connects heterogeneous
	communication infrastructures. Its purpose is to emulate a Relay and		communication infrastructures. Its purpose is to emulate a Relay and
	the closer it comes to this, the better. A Gateway operates as a		the closer it comes to this, the better. A Gateway operates as a
	User when it needs the ability to modify message content.		User when it needs the ability to modify message content.
	Differences between the different communication systems can be as		Differences between the different communication systems can be as
	small as minor syntax variations, but they usually encompass		small as minor syntax variations, but they usually encompass
	significant, semantic distinctions. Hence, the Relay function in a		significant, semantic distinctions. Hence, the Relay function in a
	Gateway presents a significant design challenge, if the resulting		Gateway presents a significant design challenge, if the resulting
	performance is to be seen as nearly seamless. The challenge is to		performance is to be seen as nearly seamless. The challenge is to
	ensure user-to-user functionality between the communication services,		ensure user-to-user functionality between the communication services,
	despite differences in their syntax and semantics.		despite differences in their syntax and semantics.
	The basic test of Gateway design is whether an Author on one side of		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		a Gateway can send a useful warning message to a Recipient on the
	other side, without requiring changes to any components in the		other side, without requiring changes to any components in the
	Author's or Recipient's communication service other than adding the		Author's or Receiver's communication service other than adding the
	Gateway. To each of these otherwise independent services, the		Gateway. To each of these otherwise independent services, the
	Gateway appears to be a native participant.		Gateway appears to be a native participant.
	3.2.4. Receiver		3.1.2.4. Receiver
	The Receiver performs final delivery or sends the warning message to		The Receiver performs final delivery or sends the warning message to
	an alternate address. In case of warning messages it is typically		an alternate address. In case of warning messages it is typically
	responsible for ensuring that the appropriate user interface		responsible for ensuring that the appropriate user interface
	interactions are triggered.		interactions are triggered to interact with the Recipient.
	4. Requirements		4. Requirements
	Requirements that relate to the encoding and the content of alert		4.1. Requirements for Alert Subscription
	messages are outside the scope of this document. This document
	focuses on the protocols utilized to convey alert messages only.
	The requirements for the two main communication models are different
	and reflected in separate sub-sections. For the Alert Push
	commnication model Section 4.2 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 Section 4.1 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.
	Req-G1:
	The protocol solution MUST allow delivery of messages
	simultaneously to a large audience.
	Req-G2:
	The protocol solution MUST be independent of the underlying link
	layer technology.
	Req-G3:
	The protocol solution MUST allow targeting notifications to
	specific individuals and to groups of individuals.
	Req-R4:
	The protocol solution MUST allow a Recipient to learn the identity
	of the Author of the alert message.
	4.1. Requirements for a Alert Subscription Communication Model
	The requirements listed below largely relate to the subscription		The requirements listed below refer to the alert subscription phase.
	phase when the potential recipient of alert messages indicates
	preferences regarding the type of alerts.
	Req-S1:		Req-S1:
	The protocol solution MUST allow a potential Recipient to indicate		The protocol solution MUST allow a potential Recipient to indicate
	the language used by alert messages.		the language used by alert messages.
	Req-S2:		Req-S2:
	The protocol solution MUST allow a potential Recipient to express		The protocol solution MUST allow a potential Recipient to express
	the geographical area it wants to receive alerts about.		the geographical area it wants to receive alerts about.
	skipping to change at page 10, line 28 ¶		skipping to change at page 9, line 34 ¶
	preferences about the type of alerts it wants to receive.		preferences about the type of alerts it wants to receive.
	Req-S4:		Req-S4:
	The protocol solution MUST allow a potential Recipient to express		The protocol solution MUST allow a potential Recipient to express
	preference for certain media types. The support for different		preference for certain media types. The support for different
	media types depends on the content of the warning message but also		media types depends on the content of the warning message but also
	impacts the communication protocol. This functionality is, for		impacts the communication protocol. This functionality is, for
	example, useful for hearing and vision impaired persons.		example, useful for hearing and vision impaired persons.
	4.2. Requirements for a Alert Push Communication Model		4.2. Requirements for Alert Message Delivery
	Req-P1:		The requirements listed below refer to the delivery of alerts.
			Req-D1:
	The protocol solution MUST allow delivery of alerts by utilizing		The protocol solution MUST allow delivery of alerts by utilizing
	he lower layer infrastructure ensuring congestion control being		the lower layer infrastructure ensuring congestion control being
	considered. Network layer multicast, anycast or broadcast		considered. Note that congestion does not only focus on over-
			utilization of a network caused by a large number of alerts but
			also in relationship with other traffic not related to exigent
			communication. Network layer multicast, anycast or broadcast
	mechanisms may be utilized. The topological network structure may		mechanisms may be utilized. The topological network structure may
	be used for efficient alert distribution.		be used for efficient alert distribution.
			Req-D2:
			The protocol solution MUST allow delivery of messages
			simultaneously to a large audience.
			Req-D3:
			The protocol solution MUST be independent of the underlying link
			layer technology.
			Req-D4:
			The protocol solution MUST allow targeting notifications to
			specific individuals and to groups of individuals.
			Req-D5:
			The protocol solution MUST allow a Recipient to learn the identity
			of the Author of the alert message.
	5. IANA Considerations		5. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	6. Security considerations		6. Security Considerations
	With the distribution of alert messages a number of security threats		Figure 1 shows the actors for delivering an alert message assuming
	need to be addressed. Because of the nature of alerts it is quite		that a prior subscription has taken place already. The desired
	likely that end device implementations will want to provide user		security properties of an MHS for conveying alerts will depend on the
	interface enhancements to get the attention whenever an alert		number of administrative domains involved. Each administrative
	arrives. This creates additional attractiveness for adversaries to		domain can have vastly different operating policies and trust-based
	exploit an alert Message Handling System. We list the most important		decision-making. One obvious example is the distinction between
	threats below that any solution will have to deal with.		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:
			o Reliability
			o Access control
			o Accountability
			o Content evaluation, adaptation, and modification
			Many communication system 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.
	Originator Impersonation:		Originator Impersonation:
	An attacker could then conceivably attempt to impersonate the		An attacker could then conceivably attempt to impersonate the
	Originator of an alert message. This threat is particularly		Originator of an alert message. This threat is particularly
	applicable to those deployment environments where authorization		applicable to those deployment environments where authorization
	decisions are based on the identity of the Originator.		decisions are based on the identity of the Originator.
	Alert Message Forgery:		Alert Message Forgery:
	skipping to change at page 11, line 40 ¶		skipping to change at page 12, line 19 ¶
	avoid accepting messages that are injected by malicious entities		avoid accepting messages that are injected by malicious entities
	with the potential desire to at least get the immediate attention		with the potential desire to at least get the immediate attention
	of the Recipient.		of the Recipient.
	Amplification Attack:		Amplification Attack:
	An attacker may use the Message Handling System to inject a single		An attacker may use the Message Handling System to inject a single
	alert message for distribution that may then be instantly turned		alert message for distribution that may then be instantly turned
	into potentially millions of alert messages for distribution.		into potentially millions of alert messages for distribution.
	One important security challenge worth mentioning is related to		One important security challenge is related to authorization. When
	authorization. When an alert message arrives at a Receiver, a		an alert message arrives at the Receiver then certain security checks
	software module at a host, then certain security checks can be		may need to be performed to ensure that the alert message meets
	performed to ensure that the message meets certain criteria. The		certain criteria. The final consumer of the alert message is,
	final consumer of the alert message is, however, the Recipient, which		however, the Recipient - a human. From a security point of view the
	in many cases is a human. From a security point of view the work		work split between the Recipient and the Receiver for making the
	split between the Recipient and the Receiver for making the		authorization decision is important, particularly when an alert
	authorization decision is important and the clarification of when to		message is rejected due to a failed security verfication by the
	drop a message due to a failed security verfication by the Receiver.		Receiver. False positives may be fatal but accepting every alert
	False positives may be fatal but accepting every alert message lowers		message lowers the trustworthiness in the overall system.
	the trustworthiness in the overall system.
	7. Acknowledgments		7. Acknowledgments
	This document re-uses a lot of text from [RFC5598]. The authors		This document re-uses text from [RFC5598]. The authors would like to
	would like to thank Dave Crocker for his work.		thank Dave Crocker for his work.
	The authors would like to thank Martin Thomson, Carl Reed, and Tony		The authors would like to thank Martin Thomson, Carl Reed, Leopold
	Rutkowski for their comments.		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.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,		[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
	July 2009.		July 2009.
End of changes. 46 change blocks.
	187 lines changed or deleted		183 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/