idnits 2.17.1 draft-ietf-atoca-requirements-00.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 (September 23, 2010) is 4936 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: March 27, 2011 BT Group 6 B. Rosen 7 NeuStar, Inc. 8 H. Tschofenig 9 Nokia Siemens Networks 10 September 23, 2010 12 Requirements, Terminology and Framework for Exigent Communications 13 draft-ietf-atoca-requirements-00.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 March 27, 2011. 44 Copyright Notice 46 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 5 66 3.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1.1. Author . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1.2. Recipient . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1.3. Mediator . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. Message Handling Service (MHS) Actors . . . . . . . . . . 6 71 3.2.1. Originator . . . . . . . . . . . . . . . . . . . . . . 7 72 3.2.2. Relay . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.2.3. Gateway . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.2.4. Receiver . . . . . . . . . . . . . . . . . . . . . . . 8 75 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1. Requirements for a Alert Subscription Communication 77 Model . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.2. Requirements for a Alert Push Communication Model . . . . 10 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 1.1. Classical Early Warning Situations 91 During large-scale emergencies, public safety authorities need to 92 reliably communicate with citizens in the affected areas, to provide 93 warnings, indicate whether citizens should evacuate and how, and to 94 dispel misinformation. Accurate information can reduce the impact of 95 such emergencies. 97 Traditionally, emergency alerting has used church bells, sirens, 98 loudspeakers, radio and television to warn citizens and to provide 99 information. However, techniques, such as sirens and bells, provide 100 limited information content; loud speakers cover only very small 101 areas and are often hard to understand, even for those not hearing 102 impaired or fluent in the local language. Radio and television offer 103 larger information volume, but are hard to target geographically and 104 do not work well to address the "walking wounded" or other 105 pedestrians. Both are not suitable for warnings, as many of those 106 needing the information will not be listening or watching at any 107 given time, particularly during work/school and sleep hours. 109 This problem has been illustrated by the London underground bombing 110 on July 7, 2006, as described in a government report [July2005]. The 111 UK authorities could only use broadcast media and could not, for 112 example, easily announce to the "walking wounded" where to assemble. 114 1.2. Exigent Communications 116 With the usage of the term 'Exigent Communications' this document 117 aims to generalize the concept of conveying alerts to IP-based 118 systems and at the same time to re-define the actors that participate 119 in the messaging communication. More precisely, exigent 120 communications is defined as: 122 Communication that requirs immediate action or remedy. 123 Information about the reason for action and details about the 124 steps that have to be taken are provided in the alert message. 126 An alert message (or warning message) is a cautionary advice about 127 something imminent (especially imminent danger or other 128 unpleasantness). In the context of exigent communication such an 129 alert message refers to a future, ongoing or past event as the 130 signaling exchange itself may relate to different stages of the 131 lifecycle of the event. The alert message itself, and not the 132 signaling protocol that convey it, provides sufficient context 133 about the specific state of the lifecycle the alert message refers 134 to. 136 There are two types of basic communication models utilized for the 137 distribution of alert messages and relevant for this document: 139 Alert Push Communication: With this alert communication paradigm 140 alert messages are sent to typically many Recipients without a 141 prior explicit communication exchange soliciting the desire to 142 receive the alerts. Typically, the criteria for becoming a 143 Recipient are based on current location of the Recipient itself 144 since alerts are targeted to a specific geographical region (an 145 area immediately relevant to the emergency event). 147 Alert Subscription Communication The alert distribution in this 148 category assumes that the Recipient has indicated interest in 149 receiving certain type of alerts using a protocol mechanism (for 150 example, a subscribe event). This opt-in subscription model 151 allows Recipients to sign-up for receiving alerts independently of 152 their current geographical location. For example, parents may 153 want to be alerted of emergencies affecting the school attended by 154 their children and adult children may need to know about 155 emergencies affecting elderly parents. 157 Note that the Receivers of the alerts may not necessarily be the 158 typical end devices humans carry around, such as mobile phones, 159 Internet tablets, or laptops. Instead, alert distribution may well 160 directly communicate with displays in subway stations, or electronic 161 bill boards. When a Receiver obtains such an alert then it may not 162 necessarily need to interact with a human (as the Recipient) but may 163 instead use the alert as input to another process to trigger 164 automated behaviors, such as closing vents during a chemical spill or 165 activating sirens or other warning systems in commercial buildings. 167 This document provides terminology, requirements and an architectural 168 description. To avoid the bias towards a specific communication 169 model or technology this documents utilizes the EMail architecture 170 terminology from [RFC5598]. 172 2. Terminology 174 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119], with the 177 important qualification that, unless otherwise stated, these terms 178 apply to the design of a protocol conveying warning messages, not its 179 implementation or application. 181 This document reuses the terminology from [RFC5598]. For editorial 182 and consistency reasons parts of the text are repeated in this 183 document and modified as appropriate. 185 3. Responsible Actor Roles 187 The communication system used for the dissemination of alert messages 188 builds on top of existing communication infrastructure. At the time 189 of writing this underlying communication infrastructure is the 190 Session Initiation Protocol (SIP) and the Extensible Messaging and 191 Presence Protocol (XMPP). These distributed services consist of a 192 variety of actors playing different roles. On a high level we 193 differentiate between the User, and the Message Handling Service 194 (MHS) actors. We will describe them in more detail below. 196 3.1. User Actors 198 Users are the sources and sinks of alert messages. Users can be 199 people, organizations, or processes. There are three types of Users: 201 o Authors 202 o Recipients 203 o Mediators 205 From the user perspective, all alert message transfer activities are 206 performed by a monolithic Message Handling Service (MHS), even though 207 the actual service can be provided by many independent organizations. 209 3.1.1. Author 211 The Author is responsible for creating the alert message, its 212 contents, and its intended recipients, even though the exact list of 213 recipients may be unknown to the Author at the time of writing the 214 alert message. The MHS transfers the alert message from the Author 215 and delivers it to the Recipients. The MHS has an Originator role 216 that correlates with the Author role. 218 For most use cases the Author is a human creating a message. 220 3.1.2. Recipient 222 The Recipient is a consumer of the delivered alert message. The MHS 223 has a Receiver role that correlates with the Recipient role. 225 For most use cases the Recipient is a human reading a message. 227 3.1.3. Mediator 229 A Mediator receives, aggregates, reformulates, and redistributes 230 alert messages among 232 A Mediator attempts to preserve the original Author's information in 233 the message it reformulates but is permitted to make meaningful 234 changes to the message content or envelope. The MHS sees a new 235 message, but users receive a message that they interpret as being 236 from, or at least initiated by, the Author of the original message. 237 The role of a Mediator is not limited to merely connecting other 238 participants; the Mediator is responsible for the new message. 240 A Mediator's role is complex and contingent, for example, modifying 241 and adding content or regulating which users are allowed to 242 participate and when. The common example of this role is an 243 aggregator that accepts alert messages from a set of Originators and 244 distributes them to a potentially large set of Recipients. This 245 functionality is similar to a multicast, or even a broadcast. 246 Recipients might have also indicated their interest to receive 247 certain type of alerts messages or they might implicitly get entitled 248 to receive specific alerts purely by their presence in a specific 249 geographical region. Hence, a Mediator might have additional 250 information about the Recipients context and might therefore be able 251 to make a decision whether the Recipient is interested in receiving a 252 particular alert message. 254 A Gateway is a particularly interesting form of Mediator. It is a 255 hybrid of User and Relay that connects to other communication 256 systems. Its purpose is to emulate a Relay. 258 3.2. Message Handling Service (MHS) Actors 260 The Message Handling Service (MHS) performs a single end-to-end 261 transfer of warning messages on behalf of the Author to reach the 262 Recipient addresses. As a pragmatic heuristic MHS actors actors 263 generate, modify or look at only transfer data, rather than the 264 entire message. 266 Figure 1 shows the relationships among transfer participants. 267 Although it shows the Originator as distinct from the Author and 268 Receiver as distinct from Recipient, each pair of roles usually has 269 the same actor. Transfers typically entail one or more Relays. 270 However, direct delivery from the Originator to Receiver is possible. 271 Delivery of warning messages within a single administrative boundary 272 usually only involve a single Relay. 274 ++==========++ ++===========++ 275 || Author || || Recipient || 276 ++====++====++ ++===========++ 277 || /\ 278 || || 279 \/ || 280 +----------+ +---++----+ 281 | | | | 282 /-+----------+----------------------------+---------+---\ 283 | | | Message Handling | | | 284 | |Originator| System (MHS) |Receiver | | 285 | | | | | | 286 | +---++-----+ +---------+ | 287 | || /\ | 288 | || || | 289 | \/ || | 290 | +---------+ +---------+ +-+--++---+ | 291 | | Relay +======-=>| Relay +=======>| Relay | | 292 | +---------+ +----++---+ +---------+ | 293 | || | 294 | || | 295 | \/ | 296 | +---------+ | 297 | | Gateway +--> | 298 | +---------+ | 299 \-------------------------------------------------------/ 301 Legend: === and || lines indicate primary (possibly 302 indirect) transfers or roles 304 Figure 1: Relationships Among MHS Actors 306 3.2.1. Originator 308 The Originator ensures that a warning message is valid for transfer 309 and then submits it to a Relay. A message is valid if it conforms to 310 both communication and warning message encapsulation standards and 311 local operational policies. The Originator can simply review the 312 message for conformance and reject it if it finds errors, or it can 313 create some or all of the necessary information. 315 The Originator serves the Author and can be the same entity. But its 316 role in assuring validity means that it also represents the local 317 operator of the MHS, that is, the local ADministrative Management 318 Domain (ADMD). 320 The Originator also performs any post-submission, Author-related 321 administrative tasks associated with message transfer and delivery. 323 Notably, these tasks pertain to sending error and delivery notices, 324 enforcing local policies, and dealing with messages from the Author 325 that prove to be problematic for the Internet. The Originator is 326 accountable for the message content, even when it is not responsible 327 for it. The Author creates the message, but the Originator handles 328 any transmission issues with it. 330 3.2.2. Relay 332 The Relay performs MHS-level transfer-service routing and store-and- 333 forward, by transmitting or retransmitting the message to its 334 Recipients. The Relay may add history information (e.g., as 335 available with SIP History Info [RFC4244]) or security related 336 protection (e.g., as available with SIP Identity [RFC4474]) but does 337 not modify the envelope information or the message content semantics. 339 A Message Handling System (MHS) network consists of a set of Relays. 340 This network is above any underlying packet-switching network that 341 might be used and below any Gateways or other Mediators. 343 3.2.3. Gateway 345 A Gateway is a hybrid of User and Relay that connects heterogeneous 346 communication infrastructures. Its purpose is to emulate a Relay and 347 the closer it comes to this, the better. A Gateway operates as a 348 User when it needs the ability to modify message content. 350 Differences between the different communication systems can be as 351 small as minor syntax variations, but they usually encompass 352 significant, semantic distinctions. Hence, the Relay function in a 353 Gateway presents a significant design challenge, if the resulting 354 performance is to be seen as nearly seamless. The challenge is to 355 ensure user-to-user functionality between the communication services, 356 despite differences in their syntax and semantics. 358 The basic test of Gateway design is whether an Author on one side of 359 a Gateway can send a useful warning message to a Recipient on the 360 other side, without requiring changes to any components in the 361 Author's or Recipient's communication service other than adding the 362 Gateway. To each of these otherwise independent services, the 363 Gateway appears to be a native participant. 365 3.2.4. Receiver 367 The Receiver performs final delivery or sends the warning message to 368 an alternate address. In case of warning messages it is typically 369 responsible for ensuring that the appropriate user interface 370 interactions are triggered. 372 4. Requirements 374 Requirements that relate to the encoding and the content of alert 375 messages are outside the scope of this document. This document 376 focuses on the protocols utilized to convey alert messages only. 378 The requirements for the two main communication models are different 379 and reflected in separate sub-sections. For the Alert Push 380 commnication model Section 4.2 the assumption is that the potential 381 recipient's consent to provide alerts has been obtained a-priori and 382 the message customization has externally been defined. There is no 383 separate protocol exchange to indicate preferences. The consent may 384 have been waived by law or has been provided when the receipient has 385 registered for a service. As an alternative approach, the Alert 386 Subscription communication model Section 4.1 allows the potential 387 alert receipient to indicate preferences about the type of alerts it 388 is interested in. This mechanism to express interest is provided as 389 part of the protocol exchange, namely via a subscription. 391 Req-G1: 393 The protocol solution MUST allow delivery of messages 394 simultaneously to a large audience. 396 Req-G2: 398 The protocol solution MUST be independent of the underlying link 399 layer technology. 401 Req-G3: 403 The protocol solution MUST allow targeting notifications to 404 specific individuals and to groups of individuals. 406 Req-R4: 408 The protocol solution MUST allow a Recipient to learn the identity 409 of the Author of the alert message. 411 4.1. Requirements for a Alert Subscription Communication Model 413 The requirements listed below largely relate to the subscription 414 phase when the potential recipient of alert messages indicates 415 preferences regarding the type of alerts. 417 Req-S1: 419 The protocol solution MUST allow a potential Recipient to indicate 420 the language used by alert messages. 422 Req-S2: 424 The protocol solution MUST allow a potential Recipient to express 425 the geographical area it wants to receive alerts about. 427 Req-S3: 429 The protocol solution MUST allow a potential Recipient to indicate 430 preferences about the type of alerts it wants to receive. 432 Req-S4: 434 The protocol solution MUST allow a potential Recipient to express 435 preference for certain media types. The support for different 436 media types depends on the content of the warning message but also 437 impacts the communication protocol. This functionality is, for 438 example, useful for hearing and vision impaired persons. 440 4.2. Requirements for a Alert Push Communication Model 442 Req-P1: 444 The protocol solution MUST allow delivery of alerts by utilizing 445 he lower layer infrastructure ensuring congestion control being 446 considered. Network layer multicast, anycast or broadcast 447 mechanisms may be utilized. The topological network structure may 448 be used for efficient alert distribution. 450 5. IANA Considerations 452 This document does not require actions by IANA. 454 6. Security considerations 456 With the distribution of alert messages a number of security threats 457 need to be addressed. Because of the nature of alerts it is quite 458 likely that end device implementations will want to provide user 459 interface enhancements to get the attention whenever an alert 460 arrives. This creates additional attractiveness for adversaries to 461 exploit an alert Message Handling System. We list the most important 462 threats below that any solution will have to deal with. 464 Originator Impersonation: 466 An attacker could then conceivably attempt to impersonate the 467 Originator of an alert message. This threat is particularly 468 applicable to those deployment environments where authorization 469 decisions are based on the identity of the Originator. 471 Alert Message Forgery: 473 An attacker could forge or alter an alert message in order to 474 convey custom messages to Recipients to get their immediate 475 attention. 477 Replay: 479 An attacker could obtain previously distributed alert messages and 480 to replay them at a later time in the hope that Recipients could 481 be tricked into believing they are fresh. 483 Unauthorized Distribution: 485 When a Receiver receives an alert message it has to determine 486 whether the Author distributing the alert messages is genuine to 487 avoid accepting messages that are injected by malicious entities 488 with the potential desire to at least get the immediate attention 489 of the Recipient. 491 Amplification Attack: 493 An attacker may use the Message Handling System to inject a single 494 alert message for distribution that may then be instantly turned 495 into potentially millions of alert messages for distribution. 497 One important security challenge worth mentioning is related to 498 authorization. When an alert message arrives at a Receiver, a 499 software module at a host, then certain security checks can be 500 performed to ensure that the message meets certain criteria. The 501 final consumer of the alert message is, however, the Recipient, which 502 in many cases is a human. From a security point of view the work 503 split between the Recipient and the Receiver for making the 504 authorization decision is important and the clarification of when to 505 drop a message due to a failed security verfication by the Receiver. 506 False positives may be fatal but accepting every alert message lowers 507 the trustworthiness in the overall system. 509 7. Acknowledgments 511 This document re-uses a lot of text from [RFC5598]. The authors 512 would like to thank Dave Crocker for his work. 514 The authors would like to thank Martin Thomson, Carl Reed, and Tony 515 Rutkowski for their comments. 517 8. References 519 8.1. Normative References 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 525 July 2009. 527 8.2. Informative References 529 [July2005] 530 , ., "Report of the 7 July Review Committee, ISBN 1 531 85261 878 7", (PDF document), http://www.london.gov.uk/ 532 assembly/reports/7july/report.pdf, June 2006. 534 [RFC4244] Barnes, M., "An Extension to the Session Initiation 535 Protocol (SIP) for Request History Information", RFC 4244, 536 November 2005. 538 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 539 Authenticated Identity Management in the Session 540 Initiation Protocol (SIP)", RFC 4474, August 2006. 542 Authors' Addresses 544 Henning Schulzrinne 545 Columbia University 546 Department of Computer Science 547 450 Computer Science Building 548 New York, NY 10027 549 US 551 Phone: +1 212 939 7004 552 Email: hgs+ecrit@cs.columbia.edu 553 URI: http://www.cs.columbia.edu 554 Steve Norreys 555 BT Group 556 1 London Road 557 Brentwood, Essex CM14 4QP 558 UK 560 Phone: +44 1277 32 32 20 561 Email: steve.norreys@bt.com 563 Brian Rosen 564 NeuStar, Inc. 565 470 Conrad Dr 566 Mars, PA 16046 567 US 569 Phone: 570 Email: br@brianrosen.net 572 Hannes Tschhofenig 573 Nokia Siemens Networks 574 Linnoitustie 6 575 Espoo 02600 576 Finland 578 Phone: +358 (50) 4871445 579 Email: Hannes.Tschofenig@gmx.net 580 URI: http://www.tschofenig.priv.at