ATOCA R. Barnes Internet-Draft BBN Technologies Intended status: Informational October 31, 2011 Expires: May 3, 2012 Lightweight Emergency Alerting Protocol (LEAP) draft-barnes-atoca-delivery-01.txt Abstract Emergency alerts need to be delivered reliably from one source to many recipients at once. TCP is unsuitable for this style of delivery, because the large number of acknowledgements would likely cause network congestion. This document defines a UDP-based protocol for delivering alerts that supports fragmentation and retransmission for reliability, and allows the sender of a datagram to control whether acknowledgements are sent. Please send feedback to the atoca@ietf.org mailing list. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Barnes Expires May 3, 2012 [Page 1] Internet-Draft ESCAPE October 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Open Questions . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. URI Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Server Processing . . . . . . . . . . . . . . . . . . . . . . . 5 6. Client Processing . . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Barnes Expires May 3, 2012 [Page 2] Internet-Draft ESCAPE October 2011 1. Introduction Servers that provide emergency alerts to end hosts have two conflicting requirements. They need to deliver alerts reliably to a large number of hosts, but in a scalable fashion that does not cause undue network congestion. In particular, TCP is unsuitable for delivering alerts because of the overhead imposed by connection establishment and acknowledgement messages [RFC0793]. Sending alerts directly in a UDP datagram is not appropriate either, because of the size limits imposed by link maximum transmission units (MTUs) [RFC0768]. This document defines the Light-weight Emergency Alerting Protocol (LEAP) as a simple, UDP-based way to deliver emergency alerts. This protocol defines a simple fragmentation layer over UDP, and retransmission and reassembly algorithms that allow for reliable transmission of alerts without a need for acknowledgements. We also define a URI format for specifying alert sources, so that alert servers can inform alert recipients about what sorts of alerts they should accept over this protocol. 1.1. Open Questions Should we randomize the order in which fragments are transmitted in order to deal with correlated loss? How should we manage UDP ports? Require that destination==source? Require that destination==default? If there is any flexibility in port selection, should the URI format allow these to be indicated? 2. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Packet Format LEAP transmits ESCAPE-encoded CAP alerts as a collection of fragments [I-D.barnes-atoca-escape]. Alert servers divide alerts into fragments that are small enough to fit into an MTU, and clients reassmeble these fragments to obtain the complete alert. (See Section 5 and Section 6 for details on the fragmentation and reassembly processes. LEAP payloads are encapsulated in UDP datagrams with source and Barnes Expires May 3, 2012 [Page 3] Internet-Draft ESCAPE October 2011 destination ports equal to XXX. Each datagram comprises a 4-octet LEAP header, followed by alert data: [[ Note to RFC Editor: Please replace the XXX above with the port number assigned by IANA ]] 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | alert-id | frag-count | frag-no | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . Fragment Body . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LEAP header has the following fields: o alert-id: A 16-bit unsigned integer uniquely identifying this alert among alerts sent from the server IP address and port for this packet o frag-count: An 8-bit unsigned integer describing the total number of fragments in an alert o frag-no: An 8-bit unsigned integer describing the position of this payload in the sequence of alert fragments The remainder of the UDP payload contains the body of the alert fragment itself. The reassembled fragments of a LEAP-transmitted alert MUST comprise a valid ESCAPE-formatted alert. Note that because each alert can be split into at most 256 fragments, the total size of the alert is still limited to a multiple of the MTU. If the available payload size after IP, UDP, and LEAP headers is 1KB, then the maximum alert that can be transmitted is 256KB. 4. URI Format A LEAP URI describes an alert server that will transmit alerts using LEAP. Clients can use these URIs to determine which LEAP messages they should accept based on a list of authorized LEAP URIs. [[ TODO: ABNF for URI format leap:[host/IP] ]] Barnes Expires May 3, 2012 [Page 4] Internet-Draft ESCAPE October 2011 5. Server Processing An alert server transmits an ESCAPE-encoded alert according to the following steps: 1. Choose a 16-bit pseudo-random alert ID. 2. Divide the alert into fragments that are sufficiently small that they are likely to be less than the MTU on all links between the server and end clients. A 512-octet maximum fragment size is RECOMMENDED. 3. Attach to each fragment a LEAP header with the following values: * alert-id: The 16-bit value chosen in step 1 * frag-count: The number of fragments generated in step 2 * frag-no: The index of this fragment in the sequence of fragments, starting at zero 4. Transmit each fragment (with its header) in a UDP datagram to the client(s) 5. Re-transmit the fragment sequence as necessary to achieve the desired level of reliability Servers increase the reliability of alert delivery by retransmitting the sequence of alert fragments. Servers SHOULD compute the number of retransmissions R based on three factors: o p: The estimated probability of a packet successfully reaching the client from the server (one minus the loss rate) o q: The probability that a client receives all fragments successfully o F: The number of fragments in the alert When clients apply the reassembly algorithm described below, the probability of receiving an entire alert after R retransmissions is given by the following formula: q = ( 1 - (1-p)^R )^F Solving this equation for R, the number of retransmissions required to achieve a resiliency q is as follows: Barnes Expires May 3, 2012 [Page 5] Internet-Draft ESCAPE October 2011 R = log(1-q^(1/F)) / log(1-p) For example, if the server estimates that there is a 10% loss rate to clients (p=.9) and wishes to transmit a 10-fragment alert (F=10) with 99% reliability (q=.99), then it should transmit the entire sequence of alert fragments at least 3 times (R=2.998). 6. Client Processing LEAP clients reassemble alert fragments from alert servers in order to obtain a complete alert. A LEAP client maintains a set of alert buffers (possibly empty) to hold fragments of incomplete alerts. Each buffer is identified by the IP address of the alert server and the 16-bit alert ID of the alert being reassmbled. Each alert buffer contains the following data elements: o IP address of the alert server o Alert ID for this alert o Number of fragments in this alert o List of fragment numbers that have been received o List of fragment bodies that have been received A LEAP client processes an incoming LEAP datagram according to the following steps: 1. Search for an existing alert buffer that matches this datagram's IP address and alert ID 2. If there is no current alert buffer, initialize one with the following values: * IP address: The source IP address of the incoming datagram * Alert ID: The alert ID from the LEAP header in the incoming datagram * Number of fragments: The fragment count from the LEAP header in the incoming datagram * Received fragment number list: A one-element list containing the fragment number from the LEAP header in the incoming datagram Barnes Expires May 3, 2012 [Page 6] Internet-Draft ESCAPE October 2011 * Received fragment body list: A one-element list containing the fragment body in the incoming datagram 3. If there is a current alert buffer, add this datagram to the buffer: A. If the fragment count field in the datagram differs from the fragment count field in the buffer, discard the datagram B. Add the fragment number from the incoming datagram to the list of fragment numbers C. Add the fragment body from the incoming datagram to the list of fragment bodies D. If all fragments have been received, re-assemble the fragment bodies in order by fragment number and return the reassembled alert In order to limit the amount of state that needs to be stored, clients SHOULD apply access controls before accepting incoming datagrams and limit the time that an individual buffer is stored. When a client has been configured with local alert servers (e.g., using the Alert Metadata Protocol [I-D.barnes-atoca-meta]), then it SHOULD only accept LEAP datagrams from configured servers. Clients MUST apply a buffer timeout T1 to incoming alerts. If all fragments for a buffer do not arrive within T1 milliseconds, then the buffer is discarded. The RECOMMENDED default value for T1 is 5000 milliseconds. Clients MAY also impose an absolute limit on the number of buffers they will store at one time, although this may cause them to miss a legitimate alert if an attacker sends many false alerts. If a client wishes to limit the number of buffers stored, it SHOULD place limits on a per-IP-address basis, rather than on a global basis. This will prevent attackers from creating many buffers, but still allow a legitimate alert server to transmit the few alerts that it needs to get through. 7. IANA Considerations [TODO: Request a default port number] [TODO: Register URI scheme] Barnes Expires May 3, 2012 [Page 7] Internet-Draft ESCAPE October 2011 8. Security Considerations The primary risk for alerting systems is the introduction of false alert information, either by injecting false alerts or by modifying valid alerts. This protocol addresses these risks by using the authentication and integrity features of the ESCAPE alert format [I-D.barnes-atoca-escape]. The main security concern for this protocol is denial of service on the client, both in the sense of resource exhaustion and in the sense of preventing legitimate alerts from arriving. Clients are required to maintain state, so there is a risk that this state will be exhausted. Rejecting LEAP datagrams based on resource limits, however, can lead to legitimate alert datagrams being dropped. Several DOS mitigations are described in Section 6 above. The LEAP protocol itself also imposes an absolute upper bound on the amount of data stored per source IP address. Due to the limited set of alert IDs and fragment numbers available, the worst-case amount of buffer is 2^24 times the link MTU, for example 4GB for a 1KB MTU. An attacker can only force a client to accept more data than this by spoofing IP addresses or sending alerts from multiple hosts. As discussed above, clients SHOULD apply resource constraints to limit the amount of state that an attacker can require a client to store. These resource contraints must be constructed so that legitimate alerts are still likely to get through. Since there is no authentication in LEAP, it is not possible to apply access controls based on cryptographic credentials. But if alert server IP addresses can be pre-provisioned, then the client can choose to accept datagrams only from those IP addresses. Limiting resources on a per- IP-address basis also increases the likelihood that legitimate alerts will be received. While attackers may try to send many alerts simultaneously in order to exhaust resources, real alert servers are much more likely to only send a few alerts at any given time. 9. Acknowledgements Thanks to Martin Thomson, Brian Rosen, Hannes Tshofenig for help in developing and refining the ideas in this document. 10. References Barnes Expires May 3, 2012 [Page 8] Internet-Draft ESCAPE October 2011 10.1. Normative References [I-D.barnes-atoca-escape] Barnes, R., "Encoding of Secure Common Alert Protocol Entities (ESCAPE)", draft-barnes-atoca-escape-00 (work in progress), October 2011. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.barnes-atoca-meta] Barnes, R., "Alert Metadata Protocol (AMP)", draft-barnes-atoca-meta-00 (work in progress), October 2011. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. Author's Address Richard Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US Phone: +1 410 290 6169 Email: rbarnes@bbn.com Barnes Expires May 3, 2012 [Page 9]