--- 1/draft-ietf-rmt-pi-alc-revised-09.txt 2009-11-09 23:12:07.000000000 +0100 +++ 2/draft-ietf-rmt-pi-alc-revised-10.txt 2009-11-09 23:12:07.000000000 +0100 @@ -1,105 +1,111 @@ Reliable Multicast Transport (RMT) Luby Working Group Watson Internet-Draft Vicisano Obsoletes: 3450 (if approved) Qualcomm Inc. -Intended status: Standards Track October 20, 2009 -Expires: April 23, 2010 +Intended status: Standards Track November 9, 2009 +Expires: May 13, 2010 Asynchronous Layered Coding (ALC) Protocol Instantiation - draft-ietf-rmt-pi-alc-revised-09 + draft-ietf-rmt-pi-alc-revised-10 + +Abstract + + This document describes the Asynchronous Layered Coding (ALC) + protocol, a massively scalable reliable content delivery protocol. + Asynchronous Layered Coding combines the Layered Coding Transport + (LCT) building block, a multiple rate congestion control building + block and the Forward Error Correction (FEC) building block to + provide congestion controlled reliable asynchronous delivery of + content to an unlimited number of concurrent receivers from a single + sender. This document obsoletes RFC3450. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. This document may contain material - from IETF Documents or IETF Contributions published or made publicly - available before November 10, 2008. The person(s) controlling the - copyright in some of this material may not have granted the IETF - Trust the right to allow modifications of such material outside the - IETF Standards Process. Without obtaining an adequate license from - the person(s) controlling the copyright in such materials, this - document may not be modified outside the IETF Standards Process, and - derivative works of it may not be created outside the IETF Standards - Process, except to format it for publication as an RFC or to - translate it into languages other than English. + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 23, 2010. + This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract + 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 + 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 BSD License. - This document describes the Asynchronous Layered Coding (ALC) - protocol, a massively scalable reliable content delivery protocol. - Asynchronous Layered Coding combines the Layered Coding Transport - (LCT) building block, a multiple rate congestion control building - block and the Forward Error Correction (FEC) building block to - provide congestion controlled reliable asynchronous delivery of - content to an unlimited number of concurrent receivers from a single - sender. This document obsoletes RFC3450. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Delivery service models . . . . . . . . . . . . . . . . . 5 - 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.3. Environmental Requirements and Considerations . . . . . . 6 - 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 7 - 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 8 - 2.2. Multiple rate congestion control building block . . . . . 10 - 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 11 - 2.4. Session Description . . . . . . . . . . . . . . . . . . . 12 - 2.5. Packet authentication building block . . . . . . . . . . . 14 - 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 15 - 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 16 - 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 16 - 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 17 - 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 18 - 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 18 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 - 5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 21 - 5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 21 - 5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 22 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 - 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 27 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 - 9.2. Informative references . . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Delivery service models . . . . . . . . . . . . . . . . . 4 + 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Environmental Requirements and Considerations . . . . . . 5 + 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 6 + 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7 + 2.2. Multiple rate congestion control building block . . . . . 9 + 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 10 + 2.4. Session Description . . . . . . . . . . . . . . . . . . . 11 + 2.5. Packet authentication building block . . . . . . . . . . . 12 + 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 13 + 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 14 + 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 14 + 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 15 + 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 16 + 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 16 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 19 + 5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 20 + 5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 21 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 + 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 25 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 9.1. Normative references . . . . . . . . . . . . . . . . . . . 26 + 9.2. Informative references . . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction This document describes a massively scalable reliable content delivery protocol, Asynchronous Layered Coding (ALC), for multiple rate congestion controlled reliable content delivery. The protocol is specifically designed to provide massive scalability using IP multicast as the underlying network service. Massive scalability in this context means the number of concurrent receivers for an object is potentially in the millions, the aggregate size of objects to be @@ -392,28 +398,31 @@ Congestion control MUST be applied to all packets within a session independently of which information about which object is carried in each packet. Multiple rate congestion control is specified because of its suitability to scale massively and because of its suitability for reliable content delivery. [RFC3738] specifies in-band Congestion Control Information (CCI) that MUST be carried in the CCI field of the LCT header. Alternative multiple rate congestion control building blocks MAY be - supported. The multiple rate congestion control building block MAY - specify more than one format for the CCI field, but it MUST specify - at most one format for each of the possible lengths 32, 64, 96 or 128 - bits. The value of C in the LCT header that determines the length of - the CCI field MUST correspond to one of the lengths for the CCI - defined in the multiple rate congestion control building block, this - length MUST be the same for all packets sent to a session, and the - CCI format that corresponds to the length as specified in the + supported, but only a single congestion control building block may be + used in a given ALC session. The congestion control building block + to be used in an ALC session is specified in the Session Description + (see Section 2.4). A multiple rate congestion control building block + MAY specify more than one format for the CCI field, but it MUST + specify at most one format for each of the possible lengths 32, 64, + 96 or 128 bits. The value of C in the LCT header that determines the + length of the CCI field MUST correspond to one of the lengths for the + CCI defined in the multiple rate congestion control building block, + this length MUST be the same for all packets sent to a session, and + the CCI format that corresponds to the length as specified in the multiple rate congestion control building block MUST be the format used for the CCI field in the LCT header. When using a multiple rate congestion control building block a sender sends packets in the session to several channels at potentially different rates. Then, individual receivers adjust their reception rate within a session by adjusting which set of channels they are joined to at each point in time depending on the available bandwidth between the receiver and the sender, but independent of other receivers. @@ -471,46 +480,20 @@ objects for which transmission has finished, or receivers may leave a session before some objects are even available within the session. In these cases, the FEC Object Transmission Information for each object may be dynamically communicated to receivers at or before the time packets for the object are received from the session. This may be accomplished using either an out-of-band mechanism, in-band using the Codepoint field or a Header Extension, or any combination of these methods. How the FEC Object Transmission Information is communicated to receivers is outside the scope of this document. - If packets for more than one object are transmitted within a session - then a Transmission Object Identifier (TOI) that uniquely identifies - objects within a session MUST appear in each packet header. Portions - of the FEC Object Transmission Information could be the same for all - objects in the session, in which case these portions can be - communicated to the receiver with an indication that this applies to - all objects in the session. These portions may be implicitly - determined based on the application, e.g., an application may use the - same FEC Encoding ID for all objects in all sessions. If there is a - portion of the FEC Object Transmission Information that may vary from - object to object and if this FEC Object Transmission Information is - communicated to a receiver out-of-band then the TOI for the object - MUST also be communicated to the receiver together with the - corresponding FEC Object Transmission Information, and the receiver - MUST use the corresponding FEC Object Transmission Information for - all packets received with that TOI. How the TOI and corresponding - FEC Object Transmission Information is communicated out-of-band to - receivers is outside the scope of this document. - - It is also possible that there is a portion of the FEC Object - Transmission Information that may vary from object to object that is - carried in-band, for example in the CodePoint field or in Header - Extensions. How this is done is outside the scope of this document. - In this case the FEC Object Transmission Information is associated - with the object identified by the TOI carried in the packet. - 2.4. Session Description Before a receiver can join an ALC session, the receiver needs to obtain a session description that contains the following information: o The multiple rate congestion control building block to be used for the session; o The sender IP address; @@ -645,25 +629,20 @@ length, conveyed by outer protocol headers (e.g., the IP or UDP header), enables receivers to detect the absence of the ALC payload and FEC Payload ID. For ALC the length of the TSI field within the LCT header is REQUIRED to be non-zero. This implies that the sender MUST NOT set both the LCT flags S and H to zero. 4.2. LCT Header-Extension Fields - All senders and receivers implementing ALC MUST support the EXT_NOP - Header Extension and MUST recognize EXT_AUTH, but are not required be - able to parse its content. The EXT_NOP and EXT_AUTH LCT Header - Extensions are defined in [RFC5651] - This specification defines a new LCT Header Extension, "EXT_FTI", for the purpose of communicating the FEC Object Transmission Information in association with data packets of an object. The LCT Header Extension Type for EXT_FTI is 64. The Header Extension Content (HEC) field of the EXT_FTI LCT Header Extension contains the encoded FEC Object Transmission Information as defined in [RFC5052]. The format of the encoded FEC Object Transmission Information is dependent on the FEC Scheme in use and so is outside the scope of this document. @@ -743,31 +722,20 @@ including interpreting the other header fields appropriately, and using the FEC Payload ID and the encoding symbol(s) in the payload to reconstruct the corresponding object. It is RECOMMENDED that packet authentication be used. If packet authentication is used then it is RECOMMENDED that the receiver immediately check the authenticity of a packet before proceeding with step (3) above. If immediate checking is possible and if the packet fails the check then the receiver MUST silently discard the packet. - Some packet authentication schemes such as TESLA - [I-D.ietf-msec-tesla-for-alc-norm] do not allow an immediate - authenticity check. In this case the receiver SHOULD check the - authenticity of a packet as soon as possible, and if the packet fails - the check then it MUST be silently discarded before step (5) above. - It is RECOMMENDED that if receivers detect many packets which fail - authentication checks within a session then the above procedure - should be modified for this session so that Step 3 is delayed until - after the authentication check and only performed if the check - succeeds. - 5. Security Considerations The same security consideration that apply to the LCT, FEC and the multiple rate congestion control building blocks also apply to ALC. ALC is especially vulnerable to denial- of-service attacks by attackers that try to send forged packets to the session which would prevent successful reconstruction or cause inaccurate reconstruction of large portions of the object by receivers. ALC is also particularly affected by such an attack because many receivers may @@ -816,20 +784,31 @@ rest of the network and other receivers. Thus, it is also RECOMMENDED that packet level authentication be used to protect against such attacks. TESLA [I-D.ietf-msec-tesla-for-alc-norm] can also be used to some extent to limit the damage caused by such attacks. However, with TESLA a receiver can only determine if a packet is authentic several seconds after it is received, and thus an attack against the congestion control protocol can be effective for several seconds before the receiver can react to slow down the session reception rate. + Some packet authentication schemes such as TESLA + [I-D.ietf-msec-tesla-for-alc-norm] do not allow an immediate + authenticity check. In this case the receiver SHOULD check the + authenticity of a packet as soon as possible, and if the packet fails + the check then it MUST be silently discarded before step (5) above. + It is RECOMMENDED that if receivers detect many packets which fail + authentication checks within a session then the above procedure + should be modified for this session so that Step 3 is delayed until + after the authentication check and only performed if the check + succeeds. + Reverse Path Forwarding checks SHOULD be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent injecting forged packets into the multicast tree data path. 5.1. Baseline Secure ALC Operation This section describes a baseline mode of secure ALC protocol operation based on application of the IPsec security protocol. This approach is documented here to provide a reference, interoperable @@ -1045,28 +1024,28 @@ Correction (FEC) Building Block", RFC 5052, August 2007. [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, October 2009. 9.2. Informative references [I-D.ietf-msec-tesla-for-alc-norm] Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in the ALC and NORM Protocols", - draft-ietf-msec-tesla-for-alc-norm-08 (work in progress), - September 2009. + draft-ietf-msec-tesla-for-alc-norm-10 (work in progress), + October 2009. [I-D.ietf-rmt-simple-auth-for-alc-norm] Roca, V., "Simple Authentication Schemes for the ALC and NORM Protocols", - draft-ietf-rmt-simple-auth-for-alc-norm-01 (work in - progress), March 2009. + draft-ietf-rmt-simple-auth-for-alc-norm-02 (work in + progress), October 2009. [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998. [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport