idnits 2.17.1 draft-barnes-atoca-delivery-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 date (October 31, 2011) is 4558 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-barnes-atoca-escape-00 == Outdated reference: A later version (-03) exists of draft-barnes-atoca-meta-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ATOCA R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Informational October 31, 2011 5 Expires: May 3, 2012 7 Lightweight Emergency Alerting Protocol (LEAP) 8 draft-barnes-atoca-delivery-01.txt 10 Abstract 12 Emergency alerts need to be delivered reliably from one source to 13 many recipients at once. TCP is unsuitable for this style of 14 delivery, because the large number of acknowledgements would likely 15 cause network congestion. This document defines a UDP-based protocol 16 for delivering alerts that supports fragmentation and retransmission 17 for reliability, and allows the sender of a datagram to control 18 whether acknowledgements are sent. 20 Please send feedback to the atoca@ietf.org mailing list. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 3, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Open Questions . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. URI Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Server Processing . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Client Processing . . . . . . . . . . . . . . . . . . . . . . . 6 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 Servers that provide emergency alerts to end hosts have two 74 conflicting requirements. They need to deliver alerts reliably to a 75 large number of hosts, but in a scalable fashion that does not cause 76 undue network congestion. In particular, TCP is unsuitable for 77 delivering alerts because of the overhead imposed by connection 78 establishment and acknowledgement messages [RFC0793]. Sending alerts 79 directly in a UDP datagram is not appropriate either, because of the 80 size limits imposed by link maximum transmission units (MTUs) 81 [RFC0768]. 83 This document defines the Light-weight Emergency Alerting Protocol 84 (LEAP) as a simple, UDP-based way to deliver emergency alerts. This 85 protocol defines a simple fragmentation layer over UDP, and 86 retransmission and reassembly algorithms that allow for reliable 87 transmission of alerts without a need for acknowledgements. We also 88 define a URI format for specifying alert sources, so that alert 89 servers can inform alert recipients about what sorts of alerts they 90 should accept over this protocol. 92 1.1. Open Questions 94 Should we randomize the order in which fragments are transmitted in 95 order to deal with correlated loss? 97 How should we manage UDP ports? Require that destination==source? 98 Require that destination==default? If there is any flexibility in 99 port selection, should the URI format allow these to be indicated? 101 2. Definitions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 3. Packet Format 109 LEAP transmits ESCAPE-encoded CAP alerts as a collection of fragments 110 [I-D.barnes-atoca-escape]. Alert servers divide alerts into 111 fragments that are small enough to fit into an MTU, and clients 112 reassmeble these fragments to obtain the complete alert. (See 113 Section 5 and Section 6 for details on the fragmentation and 114 reassembly processes. 116 LEAP payloads are encapsulated in UDP datagrams with source and 117 destination ports equal to XXX. Each datagram comprises a 4-octet 118 LEAP header, followed by alert data: 120 [[ Note to RFC Editor: Please replace the XXX above with the port 121 number assigned by IANA ]] 122 0 1 2 3 123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | alert-id | frag-count | frag-no | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | . 128 . Fragment Body . 129 . | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 The LEAP header has the following fields: 134 o alert-id: A 16-bit unsigned integer uniquely identifying this 135 alert among alerts sent from the server IP address and port for 136 this packet 138 o frag-count: An 8-bit unsigned integer describing the total number 139 of fragments in an alert 141 o frag-no: An 8-bit unsigned integer describing the position of this 142 payload in the sequence of alert fragments 144 The remainder of the UDP payload contains the body of the alert 145 fragment itself. The reassembled fragments of a LEAP-transmitted 146 alert MUST comprise a valid ESCAPE-formatted alert. Note that 147 because each alert can be split into at most 256 fragments, the total 148 size of the alert is still limited to a multiple of the MTU. If the 149 available payload size after IP, UDP, and LEAP headers is 1KB, then 150 the maximum alert that can be transmitted is 256KB. 152 4. URI Format 154 A LEAP URI describes an alert server that will transmit alerts using 155 LEAP. Clients can use these URIs to determine which LEAP messages 156 they should accept based on a list of authorized LEAP URIs. 158 [[ TODO: ABNF for URI format leap:[host/IP] ]] 160 5. Server Processing 162 An alert server transmits an ESCAPE-encoded alert according to the 163 following steps: 165 1. Choose a 16-bit pseudo-random alert ID. 167 2. Divide the alert into fragments that are sufficiently small that 168 they are likely to be less than the MTU on all links between the 169 server and end clients. A 512-octet maximum fragment size is 170 RECOMMENDED. 172 3. Attach to each fragment a LEAP header with the following values: 174 * alert-id: The 16-bit value chosen in step 1 176 * frag-count: The number of fragments generated in step 2 178 * frag-no: The index of this fragment in the sequence of 179 fragments, starting at zero 181 4. Transmit each fragment (with its header) in a UDP datagram to the 182 client(s) 184 5. Re-transmit the fragment sequence as necessary to achieve the 185 desired level of reliability 187 Servers increase the reliability of alert delivery by retransmitting 188 the sequence of alert fragments. Servers SHOULD compute the number 189 of retransmissions R based on three factors: 191 o p: The estimated probability of a packet successfully reaching the 192 client from the server (one minus the loss rate) 194 o q: The probability that a client receives all fragments 195 successfully 197 o F: The number of fragments in the alert 199 When clients apply the reassembly algorithm described below, the 200 probability of receiving an entire alert after R retransmissions is 201 given by the following formula: 203 q = ( 1 - (1-p)^R )^F 205 Solving this equation for R, the number of retransmissions required 206 to achieve a resiliency q is as follows: 208 R = log(1-q^(1/F)) / log(1-p) 210 For example, if the server estimates that there is a 10% loss rate to 211 clients (p=.9) and wishes to transmit a 10-fragment alert (F=10) with 212 99% reliability (q=.99), then it should transmit the entire sequence 213 of alert fragments at least 3 times (R=2.998). 215 6. Client Processing 217 LEAP clients reassemble alert fragments from alert servers in order 218 to obtain a complete alert. A LEAP client maintains a set of alert 219 buffers (possibly empty) to hold fragments of incomplete alerts. 220 Each buffer is identified by the IP address of the alert server and 221 the 16-bit alert ID of the alert being reassmbled. Each alert buffer 222 contains the following data elements: 224 o IP address of the alert server 226 o Alert ID for this alert 228 o Number of fragments in this alert 230 o List of fragment numbers that have been received 232 o List of fragment bodies that have been received 234 A LEAP client processes an incoming LEAP datagram according to the 235 following steps: 237 1. Search for an existing alert buffer that matches this datagram's 238 IP address and alert ID 240 2. If there is no current alert buffer, initialize one with the 241 following values: 243 * IP address: The source IP address of the incoming datagram 245 * Alert ID: The alert ID from the LEAP header in the incoming 246 datagram 248 * Number of fragments: The fragment count from the LEAP header 249 in the incoming datagram 251 * Received fragment number list: A one-element list containing 252 the fragment number from the LEAP header in the incoming 253 datagram 255 * Received fragment body list: A one-element list containing the 256 fragment body in the incoming datagram 258 3. If there is a current alert buffer, add this datagram to the 259 buffer: 261 A. If the fragment count field in the datagram differs from the 262 fragment count field in the buffer, discard the datagram 264 B. Add the fragment number from the incoming datagram to the 265 list of fragment numbers 267 C. Add the fragment body from the incoming datagram to the list 268 of fragment bodies 270 D. If all fragments have been received, re-assemble the fragment 271 bodies in order by fragment number and return the reassembled 272 alert 274 In order to limit the amount of state that needs to be stored, 275 clients SHOULD apply access controls before accepting incoming 276 datagrams and limit the time that an individual buffer is stored. 277 When a client has been configured with local alert servers (e.g., 278 using the Alert Metadata Protocol [I-D.barnes-atoca-meta]), then it 279 SHOULD only accept LEAP datagrams from configured servers. 281 Clients MUST apply a buffer timeout T1 to incoming alerts. If all 282 fragments for a buffer do not arrive within T1 milliseconds, then the 283 buffer is discarded. The RECOMMENDED default value for T1 is 5000 284 milliseconds. 286 Clients MAY also impose an absolute limit on the number of buffers 287 they will store at one time, although this may cause them to miss a 288 legitimate alert if an attacker sends many false alerts. If a client 289 wishes to limit the number of buffers stored, it SHOULD place limits 290 on a per-IP-address basis, rather than on a global basis. This will 291 prevent attackers from creating many buffers, but still allow a 292 legitimate alert server to transmit the few alerts that it needs to 293 get through. 295 7. IANA Considerations 297 [TODO: Request a default port number] 299 [TODO: Register URI scheme] 301 8. Security Considerations 303 The primary risk for alerting systems is the introduction of false 304 alert information, either by injecting false alerts or by modifying 305 valid alerts. This protocol addresses these risks by using the 306 authentication and integrity features of the ESCAPE alert format 307 [I-D.barnes-atoca-escape]. 309 The main security concern for this protocol is denial of service on 310 the client, both in the sense of resource exhaustion and in the sense 311 of preventing legitimate alerts from arriving. Clients are required 312 to maintain state, so there is a risk that this state will be 313 exhausted. Rejecting LEAP datagrams based on resource limits, 314 however, can lead to legitimate alert datagrams being dropped. 316 Several DOS mitigations are described in Section 6 above. The LEAP 317 protocol itself also imposes an absolute upper bound on the amount of 318 data stored per source IP address. Due to the limited set of alert 319 IDs and fragment numbers available, the worst-case amount of buffer 320 is 2^24 times the link MTU, for example 4GB for a 1KB MTU. An 321 attacker can only force a client to accept more data than this by 322 spoofing IP addresses or sending alerts from multiple hosts. 324 As discussed above, clients SHOULD apply resource constraints to 325 limit the amount of state that an attacker can require a client to 326 store. These resource contraints must be constructed so that 327 legitimate alerts are still likely to get through. Since there is no 328 authentication in LEAP, it is not possible to apply access controls 329 based on cryptographic credentials. But if alert server IP addresses 330 can be pre-provisioned, then the client can choose to accept 331 datagrams only from those IP addresses. Limiting resources on a per- 332 IP-address basis also increases the likelihood that legitimate alerts 333 will be received. While attackers may try to send many alerts 334 simultaneously in order to exhaust resources, real alert servers are 335 much more likely to only send a few alerts at any given time. 337 9. Acknowledgements 339 Thanks to Martin Thomson, Brian Rosen, Hannes Tshofenig for help in 340 developing and refining the ideas in this document. 342 10. References 343 10.1. Normative References 345 [I-D.barnes-atoca-escape] 346 Barnes, R., "Encoding of Secure Common Alert Protocol 347 Entities (ESCAPE)", draft-barnes-atoca-escape-00 (work in 348 progress), October 2011. 350 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 351 August 1980. 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, March 1997. 356 10.2. Informative References 358 [I-D.barnes-atoca-meta] 359 Barnes, R., "Alert Metadata Protocol (AMP)", 360 draft-barnes-atoca-meta-00 (work in progress), 361 October 2011. 363 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 364 RFC 793, September 1981. 366 Author's Address 368 Richard Barnes 369 BBN Technologies 370 9861 Broken Land Parkway 371 Columbia, MD 21046 372 US 374 Phone: +1 410 290 6169 375 Email: rbarnes@bbn.com