idnits 2.17.1 draft-ietf-atoca-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 15, 2011) is 4843 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ATOCA H. Schulzrinne 3 Internet-Draft Columbia University 4 Intended status: Informational S. Norreys 5 Expires: July 19, 2011 BT Group 6 B. Rosen 7 NeuStar, Inc. 8 H. Tschofenig 9 Nokia Siemens Networks 10 January 15, 2011 12 Requirements, Terminology and Framework for Exigent Communications 13 draft-ietf-atoca-requirements-01.txt 15 Abstract 17 Before, during and after emergency situations various agencies need 18 to provide information to a group of persons or to the public within 19 a geographical area. While many aspects of such systems are specific 20 to national or local jurisdictions, emergencies span such boundaries 21 and notifications need to reach visitors from other jurisdictions. 23 This document provides terminology, requirements and an architectural 24 description for protocols exchanging alerts between IP-based end 25 points. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 19, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Classical Early Warning Situations . . . . . . . . . . . . 3 63 1.2. Exigent Communications . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Alert Delivery Architecture . . . . . . . . . . . . . . . . . 5 66 3.1. Responsible Actor Roles . . . . . . . . . . . . . . . . . 5 67 3.1.1. User Actors . . . . . . . . . . . . . . . . . . . . . 5 68 3.1.2. Message Handling Service (MHS) Actors . . . . . . . . 6 69 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1. Requirements for Alert Subscription . . . . . . . . . . . 9 71 4.2. Requirements for Alert Message Delivery . . . . . . . . . 9 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 1.1. Classical Early Warning Situations 84 During large-scale emergencies, public safety authorities need to 85 reliably communicate with citizens in the affected areas, to provide 86 warnings, indicate whether citizens should evacuate and how, and to 87 dispel misinformation. Accurate information can reduce the impact of 88 such emergencies. 90 Traditionally, emergency alerting has used church bells, sirens, 91 loudspeakers, radio and television to warn citizens and to provide 92 information. However, techniques, such as sirens and bells, provide 93 limited information content; loud speakers cover only very small 94 areas and are often hard to understand, even for those not hearing 95 impaired or fluent in the local language. Radio and television offer 96 larger information volume, but are hard to target geographically and 97 do not work well to address the "walking wounded" or other 98 pedestrians. Both are not suitable for warnings, as many of those 99 needing the information will not be listening or watching at any 100 given time, particularly during work/school and sleep hours. 102 This problem has been illustrated by the London underground bombing 103 on July 7, 2006, as described in a government report [July2005]. The 104 UK authorities could only use broadcast media and could not, for 105 example, easily announce to the "walking wounded" where to assemble. 107 1.2. Exigent Communications 109 With the usage of the term 'Exigent Communications' this document 110 aims to generalize the concept of conveying alerts to IP-based 111 systems and at the same time to re-define the actors that participate 112 in the messaging communication. More precisely, exigent 113 communications is defined as: 115 Communication that requirs immediate action or remedy. 116 Information about the reason for action and details about the 117 steps that have to be taken are provided in the alert message. 119 An alert message (or warning message) is a cautionary advice about 120 something imminent (especially imminent danger or other 121 unpleasantness). In the context of exigent communication such an 122 alert message refers to a future, ongoing or past event as the 123 signaling exchange itself may relate to different stages of the 124 lifecycle of the event. The alert message itself, and not the 125 signaling protocol that convey it, provides sufficient context 126 about the specific state of the lifecycle the alert message refers 127 to. 129 Communication typically occurs in two phases: 131 Subscription: In this step Recipients express their interest to 132 receive certain types of alerts and happens prior to the actual 133 delivery of the alert. This expression of interest may be in form 134 of an explicit communication step by having the Receiver sending a 135 subscription message potentially with an indication of the type of 136 alerts they are interested in, the duration of the subscription 137 and a number of other indicators. For example, parents may want 138 to be alerted of emergencies affecting the school attended by 139 their children and adult children may need to know about 140 emergencies affecting elderly parents. The subscription step may, 141 however, also happen outside the Internet communication 142 infrastructure but rather by the Recipient signing a contract and 143 thereby agreeing to receive certain alerts. Additionally, certain 144 subscriptions may happen without the Recipient's explicit consent 145 and without the Receiver sending a subscription. For example, a 146 Tsunami flood alert may be delievered to Recipients in case they 147 are located in a specific geographical area. 149 It is important to note that a protocol interaction initiated by 150 the Receiver may need to take place to subscribe to certain types 151 of alerts. In some other cases the subscription does not require 152 such interaction from the Receiver. Orthogonal to the need to 153 have a protocol interaction is the question of opt-in vs. opt-out. 154 This is a pure policy decision and largely outside the scope of a 155 technical specification. 157 Alert Delivery In this step the alert message is distributed to one 158 or multiple Receivers. The Receiver as a software module then 159 presents the alert message to the Receipient. The alert encoding 160 is accomplished via the Common Alerting Protocol (CAP) and such an 161 alert message contains useful information needed for dealing with 162 the imminent danger. 164 Note that alert Receivers as software modules may not necessarily 165 only be executed on end devices humans typically carry around, such 166 as mobile phones, Internet tablets, or laptops. Instead, alert 167 distribution may well directly communicate with displays in subway 168 stations, or electronic bill boards. When a Receiver obtains such an 169 alert then it may not necessarily need to interact with a human (as 170 the Recipient) but may instead use the alert as input to another 171 process to trigger automated behaviors, such as closing vents during 172 a chemical spill or activating sirens or other warning systems in 173 commercial buildings. 175 This document provides terminology, requirements and an architectural 176 description. Note that the requirements focus on the communication 177 protocols for subscription and alert delivery rather than on the 178 content of the alert message itself. With the usage of CAP these 179 alert message content requirements are delegated to the authors and 180 originators of alerts. 182 2. Terminology 184 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119], with the 187 important qualification that, unless otherwise stated, these terms 188 apply to the design of a protocol conveying warning messages, not its 189 implementation or application. 191 3. Alert Delivery Architecture 193 This section illustrates the roles useful for alert delivery. 195 3.1. Responsible Actor Roles 197 The communication system used for the dissemination of alert messages 198 builds on top of existing communication infrastructure. At the time 199 of writing this underlying communication infrastructure is the 200 Session Initiation Protocol (SIP) and the Extensible Messaging and 201 Presence Protocol (XMPP). These distributed services consist of a 202 variety of actors playing different roles. On a high level we 203 differentiate between the User, and the Message Handling Service 204 (MHS) actors. We will describe them in more detail below. 206 3.1.1. User Actors 208 Users are the sources and sinks of alert messages. We differentiate 209 between two types of users: 211 o Authors 212 o Recipients 214 From the user perspective, all alert message transfer activities are 215 performed by a monolithic Message Handling Service (MHS), even though 216 the actual service can be provided by many independent organizations. 218 3.1.1.1. Author 220 The Author is a human responsible for creating the alert message, its 221 contents, and its intended recipients, even though the exact list of 222 recipients may be unknown to the Author at the time of writing the 223 alert message. The MHS transfers the alert message from the Author 224 and delivers it to the Recipients. 226 3.1.1.2. Recipient 228 The Recipient is a consumer of the delivered alert message. It is a 229 human reading the alert message. 231 3.1.2. Message Handling Service (MHS) Actors 233 The Message Handling Service (MHS) performs a single end-to-end 234 transfer of warning messages on behalf of the Author to reach the 235 Recipient. As a pragmatic heuristic MHS actors actors generate, 236 modify or look at only transfer data, rather than the entire message. 238 Figure 1 shows the relationships among transfer participants. 239 Although it shows the Originator as distinct from the Author and 240 Receiver as distinct from Recipient, each pair of roles usually has 241 the same actor. Transfers typically entail one or more Relays. 242 However, direct delivery from the Originator to Receiver is possible. 243 Delivery of warning messages within a single administrative boundary 244 usually only involve a single Relay. 246 ++==========++ ++===========++ 247 || Author || || Recipient || 248 ++====++====++ ++===========++ 249 || /\ 250 || || 251 \/ || 252 +----------+ +---++----+ 253 | | | | 254 /-+----------+----------------------------+---------+---\ 255 | | | Message Handling | | | 256 | |Originator| System (MHS) |Receiver | | 257 | | | | | | 258 | +---++-----+ +---------+ | 259 | || /\ | 260 | || || | 261 | \/ || | 262 | +---------+ +---------+ +-+--++---+ | 263 | | Relay +======-=>| Relay +=======>| Relay | | 264 | +---------+ +----++---+ +---------+ | 265 | || | 266 | || | 267 | \/ | 268 | +---------+ | 269 | | Gateway +--> | 270 | +---------+ | 271 \-------------------------------------------------------/ 273 Legend: === and || lines indicate primary (possibly 274 indirect) transfers or roles 276 Figure 1: Relationships Among MHS Actors 278 3.1.2.1. Originator 280 The Originator ensures that a warning message is valid for transfer 281 and then submits it to a Relay. A message is valid if it conforms to 282 both communication and warning message encapsulation standards and 283 local operational policies. The Originator can simply review the 284 message for conformance and reject it if it finds errors, or it can 285 create some or all of the necessary information. 287 The Originator serves the Author and can be the same entity in 288 absence of a human crafting alert messages. 290 The Originator also performs any post-submission, Author-related 291 administrative tasks associated with message transfer and delivery. 292 Notably, these tasks pertain to sending error and delivery notices, 293 enforcing local policies, and dealing with messages from the Author 294 that prove to be problematic for the Internet. The Originator is 295 accountable for the message content, even when it is not responsible 296 for it. The Author creates the message, but the Originator handles 297 any transmission issues with it. 299 3.1.2.2. Relay 301 The Relay performs MHS-level transfer-service routing and store-and- 302 forward, by transmitting or retransmitting the message to its 303 Recipients. The Relay may add history information (e.g., as 304 available with SIP History Info [RFC4244]) or security related 305 protection (e.g., as available with SIP Identity [RFC4474]) but does 306 not modify the envelope information or the message content semantics. 308 A Message Handling System (MHS) network consists of a set of Relays. 309 This MHS network is above any underlying packet-switching network 310 that might be used and below any Gateways. 312 3.1.2.3. Gateway 314 A Gateway is a hybrid of User and Relay that connects heterogeneous 315 communication infrastructures. Its purpose is to emulate a Relay and 316 the closer it comes to this, the better. A Gateway operates as a 317 User when it needs the ability to modify message content. 319 Differences between the different communication systems can be as 320 small as minor syntax variations, but they usually encompass 321 significant, semantic distinctions. Hence, the Relay function in a 322 Gateway presents a significant design challenge, if the resulting 323 performance is to be seen as nearly seamless. The challenge is to 324 ensure user-to-user functionality between the communication services, 325 despite differences in their syntax and semantics. 327 The basic test of Gateway design is whether an Author on one side of 328 a Gateway can send a useful warning message to a Recipient on the 329 other side, without requiring changes to any components in the 330 Author's or Receiver's communication service other than adding the 331 Gateway. To each of these otherwise independent services, the 332 Gateway appears to be a native participant. 334 3.1.2.4. Receiver 336 The Receiver performs final delivery or sends the warning message to 337 an alternate address. In case of warning messages it is typically 338 responsible for ensuring that the appropriate user interface 339 interactions are triggered to interact with the Recipient. 341 4. Requirements 343 4.1. Requirements for Alert Subscription 345 The requirements listed below refer to the alert subscription phase. 347 Req-S1: 349 The protocol solution MUST allow a potential Recipient to indicate 350 the language used by alert messages. 352 Req-S2: 354 The protocol solution MUST allow a potential Recipient to express 355 the geographical area it wants to receive alerts about. 357 Req-S3: 359 The protocol solution MUST allow a potential Recipient to indicate 360 preferences about the type of alerts it wants to receive. 362 Req-S4: 364 The protocol solution MUST allow a potential Recipient to express 365 preference for certain media types. The support for different 366 media types depends on the content of the warning message but also 367 impacts the communication protocol. This functionality is, for 368 example, useful for hearing and vision impaired persons. 370 4.2. Requirements for Alert Message Delivery 372 The requirements listed below refer to the delivery of alerts. 374 Req-D1: 376 The protocol solution MUST allow delivery of alerts by utilizing 377 the lower layer infrastructure ensuring congestion control being 378 considered. Note that congestion does not only focus on over- 379 utilization of a network caused by a large number of alerts but 380 also in relationship with other traffic not related to exigent 381 communication. Network layer multicast, anycast or broadcast 382 mechanisms may be utilized. The topological network structure may 383 be used for efficient alert distribution. 385 Req-D2: 387 The protocol solution MUST allow delivery of messages 388 simultaneously to a large audience. 390 Req-D3: 392 The protocol solution MUST be independent of the underlying link 393 layer technology. 395 Req-D4: 397 The protocol solution MUST allow targeting notifications to 398 specific individuals and to groups of individuals. 400 Req-D5: 402 The protocol solution MUST allow a Recipient to learn the identity 403 of the Author of the alert message. 405 5. IANA Considerations 407 This document does not require actions by IANA. 409 6. Security Considerations 411 Figure 1 shows the actors for delivering an alert message assuming 412 that a prior subscription has taken place already. The desired 413 security properties of an MHS for conveying alerts will depend on the 414 number of administrative domains involved. Each administrative 415 domain can have vastly different operating policies and trust-based 416 decision-making. One obvious example is the distinction between 417 alert messages that are exchanged within an closed group (such as 418 alert messages received by parents affecting the school attended by 419 their children) and alert messages that are exchanged between 420 independent organizations (e.g., in case of large scale disasters). 421 The rules for handling both types of communication architectures tend 422 to be quite different. That difference requires defining the 423 boundaries of each. 425 Operation of communication systems that are used to convey alert 426 messages are typically carried out by different providers (or 427 operators). Since each be in operated in an independent 428 administrative domain it is useful to consider administrative domain 429 boundaries in the description to facilitate discussion about designs, 430 policies and operations that need to distinguish between internal 431 issues and external entities. Most significant is that the entities 432 communicating across administrative boundaries typically have the 433 added burden of enforcing organizational policies concerning external 434 communications. For example, routing alerts between administrative 435 domains can create requirements, such as needing to route alert 436 messages between organizational partners over specially trusted 437 paths. 439 The communication interactions are subject to the policies of that 440 domain, which cover concerns such as these: 442 o Reliability 443 o Access control 444 o Accountability 445 o Content evaluation, adaptation, and modification 447 Many communication system make the distinction of administrative 448 domains since they impact the requirements on security solutions. 449 However, with the distribution of alert messages a number of 450 additional security threats need to be addressed. Due to the nature 451 of alerts it is quite likely that end device implementations will 452 offer user interface enhancements to get the Recipients attention 453 whenever an alert arrives, which is an attractive property for 454 adversaries to exploit. Below we list the most important threats any 455 solution will have to deal with. 457 Originator Impersonation: 459 An attacker could then conceivably attempt to impersonate the 460 Originator of an alert message. This threat is particularly 461 applicable to those deployment environments where authorization 462 decisions are based on the identity of the Originator. 464 Alert Message Forgery: 466 An attacker could forge or alter an alert message in order to 467 convey custom messages to Recipients to get their immediate 468 attention. 470 Replay: 472 An attacker could obtain previously distributed alert messages and 473 to replay them at a later time in the hope that Recipients could 474 be tricked into believing they are fresh. 476 Unauthorized Distribution: 478 When a Receiver receives an alert message it has to determine 479 whether the Author distributing the alert messages is genuine to 480 avoid accepting messages that are injected by malicious entities 481 with the potential desire to at least get the immediate attention 482 of the Recipient. 484 Amplification Attack: 486 An attacker may use the Message Handling System to inject a single 487 alert message for distribution that may then be instantly turned 488 into potentially millions of alert messages for distribution. 490 One important security challenge is related to authorization. When 491 an alert message arrives at the Receiver then certain security checks 492 may need to be performed to ensure that the alert message meets 493 certain criteria. The final consumer of the alert message is, 494 however, the Recipient - a human. From a security point of view the 495 work split between the Recipient and the Receiver for making the 496 authorization decision is important, particularly when an alert 497 message is rejected due to a failed security verfication by the 498 Receiver. False positives may be fatal but accepting every alert 499 message lowers the trustworthiness in the overall system. 501 7. Acknowledgments 503 This document re-uses text from [RFC5598]. The authors would like to 504 thank Dave Crocker for his work. 506 The authors would like to thank Martin Thomson, Carl Reed, Leopold 507 Murhammer, and Tony Rutkowski for their comments. 509 At IETF#79 the following persons provided feedback leading to changes 510 in this document: Keith Drage, Scott Bradner, Ken Carberg, Keeping 511 Li, Martin Thomson, Igor Faynberg, Mark Wood, Peter Saint-Andre. 513 8. References 515 8.1. Normative References 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, March 1997. 520 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 521 July 2009. 523 8.2. Informative References 525 [July2005] 526 , ., "Report of the 7 July Review Committee, ISBN 1 527 85261 878 7", (PDF document), http://www.london.gov.uk/ 528 assembly/reports/7july/report.pdf, June 2006. 530 [RFC4244] Barnes, M., "An Extension to the Session Initiation 531 Protocol (SIP) for Request History Information", RFC 4244, 532 November 2005. 534 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 535 Authenticated Identity Management in the Session 536 Initiation Protocol (SIP)", RFC 4474, August 2006. 538 Authors' Addresses 540 Henning Schulzrinne 541 Columbia University 542 Department of Computer Science 543 450 Computer Science Building 544 New York, NY 10027 545 US 547 Phone: +1 212 939 7004 548 Email: hgs+ecrit@cs.columbia.edu 549 URI: http://www.cs.columbia.edu 551 Steve Norreys 552 BT Group 553 1 London Road 554 Brentwood, Essex CM14 4QP 555 UK 557 Phone: +44 1277 32 32 20 558 Email: steve.norreys@bt.com 559 Brian Rosen 560 NeuStar, Inc. 561 470 Conrad Dr 562 Mars, PA 16046 563 US 565 Phone: 566 Email: br@brianrosen.net 568 Hannes Tschhofenig 569 Nokia Siemens Networks 570 Linnoitustie 6 571 Espoo 02600 572 Finland 574 Phone: +358 (50) 4871445 575 Email: Hannes.Tschofenig@gmx.net 576 URI: http://www.tschofenig.priv.at