RFC 5775
Asynchronous Layered Coding (ALC) Protocol Instantiation
RFC 5775 💖 Asynchronous Layered Coding (ALC) Protocol Instantiation
okay so this is RFC 5775 ✨, called "Asynchronous Layered Coding (ALC) Protocol Instantiation." It was written by M. Luby, M. Watson, and L. Vicisano, all at Qualcomm, Inc. 💅 It's a Standards Track document from April 2010, and it obsoletes RFC 3450 🙈 (so that one's been retired). It doesn't update anything, and its ISSN is 2070-1721 🎀.
Abstract 🌸
okay the big idea: this doc describes ALC, a massively scalable reliable content delivery protocol 🚀. ALC mixes three building blocks: the Layered Coding Transport (LCT) one, a multiple rate congestion control one, and the Forward Error Correction (FEC) one 🧚. Together they deliver content reliably and asynchronously, with congestion control, to an unlimited number of concurrent receivers coming from a single sender 💜. This document obsoletes RFC 3450.
Status of This Memo 🦋
this is an Internet Standards Track document ✨.
it's a product of the Internet Engineering Task Force (IETF) 💖. it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 📚.
for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5775 🔗.
Copyright Notice 🎀
Copyright (c) 2010 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) as in effect on the date of publication. please actually read these, because they spell out your rights and restrictions for this document 🫶. any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💅.
this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. 🙈 The people who control the copyright in some of that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. so unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside it. the one exception is formatting it for publication as an RFC or translating it into languages other than English 🌈.
Table of Contents 📖
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Delivery Service Models . . . . . . . . . . . . . . . . . 4
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Environmental Requirements and Considerations . . . . . . 5
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . 12
4. Functionality Definition . . . . . . . . . . . . . . . . . . . 13
4.1. Packet Format Used by ALC . . . . . . . . . . . . . . . . 13
4.2. LCT Header Extension Fields . . . . . . . . . . . . . . . 14
4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 15
4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 18
5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 18
5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. Changes from RFC 3450 . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 231. Introduction ✨
okay so this doc describes a massively scalable reliable content delivery protocol, Asynchronous Layered Coding (ALC) 🚀, for multiple rate congestion controlled reliable content delivery 💖. it's built to scale massively by using IP multicast as the underlying network service 🌸. "massively scalable" here means the number of concurrent receivers for an object could reach the millions 🤯. the total size of objects delivered in a session can range from hundreds of kilobytes to hundreds of gigabytes 📦. each receiver can start receiving an object whenever it wants (asynchronously) ⏰. each receiver's reception rate is the maximum fair bandwidth between it and the sender 🦋. and all of that can run off a single sender 👑.
ALC is all about reliable delivery, so the goal is to get objects to every receiver as fast as possible while still being network friendly to competing traffic 🫶. so the congestion control used with ALC should try to make the most of the bandwidth between receivers and the sender, and back off aggressively when there's competing traffic 💅.
on the sender side, ALC generates packets from the objects being delivered in the session, then sends the properly formatted packets at the right rates to the channels associated with the session 📤. on the receiver side, it joins the right channels for the session, does congestion control by adjusting which joined channels it's in based on detected congestion, and uses the packets to reliably rebuild objects 🧩. in an ALC session, all the information flow is data packets sent by a single sender to channels that receivers join 🎀.
ALC does specify the Session Description that receivers need before they join a session, but how receivers actually get that info is outside ALC's scope 🙈. an application using ALC might want receivers to report reception statistics back to the sender, but how they report that is also outside ALC's scope 💜. basically, ALC is designed to be a minimal protocol instantiation that gives reliable content delivery without unnecessary limits on the scalability of the basic protocol 🧚.
this document is a product of the IETF RMT WG and follows the general guidelines in [RFC3269] 🌈.
an earlier version was published in the "Experimental" category as [RFC3450], and this document obsoletes it 🙈.
this Proposed Standard specification is based on, and backwards compatible with, the protocol in [RFC3450], updated based on accumulated experience and the protocol's growing maturity since it was first published 🌟. that experience applies both to this spec itself and to the congestion control strategies used with it 🔥.
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 BCP 14, [RFC2119] 💅.
1.1. Delivery Service Models 🦋
ALC can support several different reliable content delivery service models, as described in [RFC5651] ✨.
1.2. Scalability 🌸
massive scalability is a main design goal for ALC 👑. IP multicast is inherently massively scalable, but the best effort service it provides doesn't do session management, congestion control, or reliability 🙈. ALC adds all of that on top of IP multicast without giving up any of multicast's inherent scalability 🫶. ALC has these properties:
- to each receiver, it looks like there's a dedicated session from the sender to that receiver, where the reception rate adjusts to congestion along the path from sender to receiver 💖.
- to the sender, there's no difference in load or outgoing rate whether one receiver or a million (or any number) are joined to the session, no matter when they join or leave 📈.
- no feedback packets are required from receivers to the sender 🙅♀️.
- almost all packets in the session that pass through a bottleneck link are used by downstream receivers, and the session shares the link fairly with competing flows, in proportion to their utility ⚖️.
so, all in all, ALC gives you a massively scalable content delivery transport that's network friendly 💜.
ALC intentionally leaves out any application-specific features that could limit its scalability 🧚. by doing that, it stays a minimal protocol that's massively scalable 🌈. applications can be built on top of ALC to add features that might limit the application's scalability, but those applications are outside the scope of this document 🎀.
1.3. Environmental Requirements and Considerations 🌊
all the environmental requirements and considerations that apply to the LCT building block [RFC5651], the FEC building block [RFC5052], the multiple rate congestion control building block, and any other building blocks ALC uses also apply to ALC 💅.
the IP multicast model defined in [RFC1112] is commonly called Any-Source Multicast (ASM), which is different from Source-Specific Multicast (SSM), defined in [RFC3569] 🔍. one ASM-specific issue for ALC is how the multiple rate congestion control building block interacts with ASM 😬. that building block may use the measured time between when a join to a channel is sent and when the first packet from that channel arrives to figure out the receiver reception rate ⏱️. it may also use packet sequence numbers per channel to measure losses, and those are also used to figure out the reception rate 🧮.
these features raise two concerns with ASM 🚨. first, the time between sending the join to a channel and the first packet arriving can be significant, because of Rendezvous Points (RPs) and the Multicast Source Discovery Protocol (MSDP) [RFC3618] 🐢. second, packets can be lost during the switch from the (*,G) join to the RP and the (S,G) join directly to the sender 📉. either of these could substantially degrade receivers' reception rates 😭. to ease these concerns, it is recommended during deployment to make sure the RP is as close to the sender as possible 📍. SSM doesn't have these same concerns 🫶. for a fuller look at these issues, check the multiple rate congestion control building block 💜.
2. Architecture Definition ✨
okay bestie, so ALC uses the LCT building block [RFC5651] for in-band session management 🎀. For congestion control it uses a multiple rate congestion control building block that's compliant with [RFC2357], and it's feedback free 🦋 which means no feedback needed! Receivers pick their own rate by joining and leaving the channels in the session 🌸. For reliability, ALC uses the FEC building block [RFC5052] 🛡️. The sender makes encoding symbols from the object using FEC codes and sends them in packets to the session's channels. Receivers just wait until enough packets arrive and then rebuild the object. Nobody asks for missed packets to be resent, so the packets and the sending rate don't depend on how many receivers there are or what each one is going through 🫶.
A session in ALC is defined the same way as in LCT. An ALC session is multiple channels coming from one sender, used for some stretch of time to carry packets about one or more objects that receivers might want 👑. Congestion control runs over the total of packets sent to all the channels in a session. Being limited to one sender doesn't stop you from receiving packets for the same objects from multiple senders, but each sender sends to a different session, and each session gets its own congestion control 💜. Receiving from several sessions at once is allowed, but how an application handles that is outside the scope of this document 🙈.
ALC is a protocol instantiation as defined in [RFC3048] ✨. This document describes version 1 of ALC, which MUST use version 1 of LCT described in [RFC5651]. Like LCT, ALC is built for the IP multicast network service. This specification defines ALC as a payload of the UDP transport protocol [RFC0768] that supports IP multicast delivery of packets 🌈.
Here's how the ALC packet is laid out in Figure 1 💖. An ALC packet header comes right after the IP/UDP header. It's made of the default LCT header from [RFC5651], followed by the FEC Payload ID from [RFC5052]. The Congestion Control Information field inside the LCT header carries the Congestion Control Information required by the multiple rate congestion control building block compliant with [RFC2357]. The packet payload after the ALC packet header is made of encoding symbols, which are identified by the FEC Payload ID as described in [RFC5052].
+----------------------------------------+
| IP Header |
+----------------------------------------+
| UDP Header |
+----------------------------------------+
| LCT Header |
+----------------------------------------+
| FEC Payload Id |
+----------------------------------------+
| Encoding Symbols |
+----------------------------------------+
Figure 1: ALC Packet FormatEach receiver is required to get a Session Description before joining an ALC session 📝. As we'll see later, the Session Description holds the out-of-band info needed by the LCT, FEC, and multiple rate congestion control building blocks. The FEC Object Transmission Information from the FEC building block [RFC5052] that a receiver needs for each object can reach it either out-of-band or in-band using a Header Extension. How the Session Description and the FEC Object Transmission Information get to a receiver is outside the scope of this document 🙈.
2.1. LCT Building Block
LCT requires receivers to be able to uniquely identify and demultiplex packets for an LCT session, and ALC inherits this requirement and makes it stronger 💪. A Transport Session Identifier (TSI) MUST be associated with each session and MUST be carried in the LCT header of each ALC packet. The TSI is scoped by the sender IP address, and the (sender IP address, TSI) pair MUST uniquely identify the session 🔑.
The LCT header has a Congestion Control Information (CCI) field that MUST be used to carry the Congestion Control Information from the specified multiple rate congestion control protocol. There's a field in the LCT header that says how long the CCI field is, and the multiple rate congestion control building block MUST uniquely identify a CCI field format that matches that length 📏.
The LCT header also has a Codepoint field that MAY be used to tell a receiver the settings for information that can change during a session 🎨. If it's used, the mapping between settings and Codepoint values is communicated in the Session Description, and that mapping is outside the scope of this document. For example, the FEC Encoding ID, which is part of the FEC Object Transmission Information from the FEC building block [RFC5052], could change for each object in the session. The Codepoint value could then be used to communicate which FEC Encoding ID to use for each object. The mapping between FEC Encoding IDs and Codepoints could be, for example, the identity mapping 🧚.
If more than one object is carried within a session, then the Transmission Object Identifier (TOI) MUST be used in the LCT header to identify which packets go with which objects 🧩. In this case, the receiver MUST use the TOI to associate received packets with objects. The TOI is scoped by the sender's IP address and the TSI, which means it's scoped by the session. The TOI for each object is REQUIRED to be unique within a session, but it is not required to be unique across sessions. On top of that, the same object MAY have a different TOI in different sessions. The mapping between TOIs and objects carried in a session is outside the scope of this document 💅.
If only one object is carried within a session, then the TOI MAY be omitted from the LCT header 🌸.
The LCT header from version 1 of the LCT building block [RFC5651] MUST be used 🎀.
The LCT Header includes a two-bit Protocol Specific Indication (PSI) field in bits 6 and 7 of the first word of the LCT header ✨. ALC uses these two bits like this:
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
+-+-+
...|X|Y|...
+-+-+
Figure 2: PSI Bits within LCT HeaderPSI bit X - Source Packet Indicator (SPI)
PSI bit Y - ReservedThe Source Packet Indicator is used with systematic FEC Schemes, which define one FEC Payload ID format for packets with only source data and a different one for packets with repair data 🧁. For those FEC Schemes, the SPI MUST be set to 1 when the FEC Payload ID format for packets with only source data is used, and the SPI MUST be set to zero when the FEC Payload ID for packets with repair data is used. For FEC Schemes that define only a single FEC Payload ID format, the SPI MUST be set to zero by the sender and MUST be ignored by the receiver 🙌.
Supporting two FEC Payload ID formats lets FEC Payload ID info that only matters when FEC decoding is happening go in the repair-data format. Receivers that don't do FEC decoding (either because none is needed or because the receiver doesn't support it) don't have to process that info 🫶.
2.2. Multiple Rate Congestion Control Building Block
At a minimum, implementations of ALC MUST support [RFC3738] 🔥. Heads up though: [RFC3738] was published in the "Experimental" category, so it has a lower maturity level than this document. Caution should be used, since it may be less stable than this document 💀.
Congestion control MUST be applied to all packets within a session, no matter what information about which object is carried in each packet 🚦. Multiple rate congestion control is specified because it's really good at scaling massively and really good 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, but only a single congestion control building block may be used in a given ALC session 🦋. The congestion control building block for 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 sets 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. That length MUST be the same for all packets sent to a session, and the CCI format that matches 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 changing which set of channels they're joined to at each point in time, depending on the available bandwidth between the receiver and the sender. They do this independently of other receivers 💜.
2.3. FEC Building Block 🧩
okay so the FEC building block [RFC5052] is what gives you reliable object delivery inside an ALC session 💖 Every object sent in the session gets encoded on its own using FEC codes, and [RFC3453] goes much deeper on how FEC codes work in reliable content delivery protocols if you want the full nerdy tour 🤓 Every packet in an ALC session MUST carry an FEC Payload ID that matches the FEC Scheme being used ✨ That ID uniquely identifies the encoding symbols inside each packet's payload, and the receiver MUST use it to figure out how those symbols were generated from the object 🔍 That's the whole vibe of the FEC building block!
As described in [RFC5052], a receiver is REQUIRED to get the FEC Object Transmission Information for each object whose data packets it receives from the session 📦 For ALC, that FEC Object Transmission Information includes:
- The FEC Encoding ID.
- If an Under-Specified FEC Encoding ID is used, then the FEC Instance ID associated with that FEC Encoding ID.
- For each object in the session, the transfer length of the object in bytes.
Depending on which FEC Scheme you're using (the one identified by the FEC Encoding ID), you might need even more FEC Object Transmission Information 🎀
Some of the FEC Object Transmission Information MAY be implicit, based on the FEC Scheme and/or the implementation 🌸 Like, source block lengths could be worked out with a fixed algorithm from the object length 🧮 Or all the source blocks might be the same length, and that's the value passed out-of-band to the receiver 📬 Another option: the full-sized source block length gets provided, and it's used for every source block except the last one, whose length is calculated from the full source block length and the object length 🧠 And honestly, the same FEC Encoding ID and FEC Instance ID could always be used for a particular application, which means they're implicitly defined. Iconic behaviour 💅
Sometimes the objects in a session are totally known before a receiver joins, in which case the FEC Object Transmission Information for all of them can be communicated before anyone joins 🗓️ Other times it's messier! The objects may not be known when the session starts, receivers might join a session already in progress and skip objects that finished sending, or they might leave before some objects even show up 🙃 In those cases, the FEC Object Transmission Information for each object can be sent dynamically to receivers at or before the moment packets for that object arrive 🚀 This can happen out-of-band, in-band using the Codepoint field or a Header Extension, or any mix of those 🦋 How the FEC Object Transmission Information gets to receivers is outside the scope of this document, so that's a different story 📖
2.4. Session Description 📜
Before a receiver can join an ALC session, it needs to obtain a Session Description with the following information:
- The multiple rate congestion control building block to be used for the session;
- The sender IP address;
- The number of channels in the session;
- The address and port number used for each channel in the session;
- The Transport Session ID (TSI) to be used for the session;
- An indication of whether or not the session carries packets for more than one object;
- If Header Extensions are to be used, the format of these Header Extensions.
- Enough information to determine the packet authentication scheme being used, if one is being used.
How the Session Description gets communicated to receivers is outside the scope of this document 🙌
The Codepoint field within the LCT portion of the header can be used to communicate some of the dynamically changing information within a session, in-band ✨ To make that work, a mapping between Codepoint values and the different dynamic settings MUST be included within the Session Description 🗺️ Then the settings to use are communicated by putting the Codepoint value into each packet 💜 For example, multiple objects could be delivered in the same session with a different FEC encoding algorithm for each type of object, so the Session Description could hold the mapping between Codepoint values and FEC Encoding IDs 🧁 Another example: different packets sent to the session might use different packet authentication schemes, so the mapping between those schemes and Codepoint values could go in the Session Description 🔐 You can even map combinations of settings to Codepoint values. Like, one specific combo of a FEC Encoding ID and a packet authentication scheme could get its own Codepoint value 🎯
The Session Description could also include, but isn't limited to:
- The mappings between combinations of settings and Codepoint values;
- The data rates used for each channel;
- The length of the packet payload;
- Any information that is relevant to each object being transported, such as the Object Transmission Information for each object, when the object will be available within the session, and for how long.
The Session Description could be in a form like the Session Description Protocol (SDP) as defined in [RFC4566], XML metadata as defined in [RFC3023], or HTTP/MIME headers as defined in [RFC2616], etc. 🌈 It might be carried in a session announcement protocol such as SAP as defined in [RFC2974], obtained using a proprietary session control protocol, located on a web page with scheduling info, or passed along via email or other out-of-band methods 📨 Talking about Session Description formats and how they get to receivers is beyond the scope of this document, so we're leaving that one alone 🫶
2.5. Packet Authentication Building Block 🔐
okay this one's a big deal 😤 It is RECOMMENDED that implementors of ALC use some packet authentication scheme to protect the protocol from attacks 🛡️ Suitable schemes are described in [RFC5776] and [RMT-SIMPLE], so go check those out, bestie 💅
3. Conformance Statement 📋
This Protocol Instantiation document, together with the LCT building block [RFC5651], the FEC building block [RFC5052], and [RFC3738], completely specifies a working reliable multicast transport protocol that conforms to the requirements described in [RFC2357] 🏆 That's the full package, no missing pieces!
4. Functionality Definition ⚙️
This section describes the format and functionality of the data packets carried in an ALC session, plus what the sender and receiver do during a session 🎬
4.1. Packet Format Used by ALC 📦
The packet format used by ALC is the UDP header, then the LCT header, then the FEC Payload ID, then the packet payload 🧱 The LCT header is defined in the LCT building block [RFC5651], and the FEC Payload ID is described in the FEC building block [RFC5052] 🔗 The Congestion Control Information field in the LCT header holds the required Congestion Control Information described in whichever multiple rate congestion control building block is in use 📊 The packet payload contains encoding symbols generated from an object 🎁 If more than one object is carried in the session, then the Transmission Object ID (TOI) within the LCT header MUST be used to identify which object the encoding symbols came from 🆔 Within the scope of an object, the encoding symbols in the packet payload are identified by the FEC Payload ID, as described in the FEC building block 🔎
The version number of ALC specified in this document is 1 ✌️ The version number field of the LCT header MUST be interpreted as the ALC version number field 💫 This version of ALC implicitly uses version 1 of the LCT building block defined in [RFC5651] 🦋
The overall ALC packet format is shown in Figure 3 📐 The packet is an IP packet, either IPv4 or IPv6, and the IP header comes before the UDP header 🌐 The ALC packet format doesn't depend on the IP version number at all, which is so chill 😎
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| LCT Header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Overall ALC Packet Format
In some special cases, an ALC sender may need to produce ALC packets that don't contain any payload 🫥 This might be needed, for example, to signal the end of a session or to convey congestion control information 📣 These data-less packets don't contain the FEC Payload ID either, only the LCT header fields 🪶 The total datagram length, given by the outer protocol headers (e.g., the IP or UDP header), lets receivers detect that the ALC payload and FEC Payload ID are absent 🕵️♀️
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 🚫 No cap, this one matters!
4.2. LCT Header Extension Fields 🧩
This specification defines a brand-new LCT Header Extension, "EXT_FTI" 🎉 Its purpose is communicating the FEC Object Transmission Information in association with an object's data packets 📮 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 that encoded information depends on the FEC Scheme in use, so it's outside the scope of this document 🌷
4.3. Sender Operation 📤
okay bestie, so the sender side of ALC is basically the LCT building block [RFC5651], the FEC building block [RFC5052], and the multiple rate congestion control building block all stacked together. ✨ That means every single point those building blocks make about sender operation applies here too 💅
A sender using ALC should make available the required Session Description as described in Section 2.4. A sender should also make available the required FEC Object Transmission Information as described in Section 2.3. 🎀
Within a session, a sender sends a sequence of packets to the channels linked to the session 🦋 The ALC sender MUST obey the rules for filling in the CCI field in the packet headers, and it MUST send packets at the right rates to the channels for the session, as dictated by the multiple rate congestion control building block. no skipping the rules, periodt 💀
The ALC sender MUST use the same TSI for all packets in the session 🌸 Several objects MAY be delivered within the same ALC session. If you're delivering more than one object in a session, then the sender MUST use the TOI field. Each object MUST be identified by a unique TOI within the session, and the sender MUST use the matching TOI for all packets about the same object. The FEC Payload ID MUST correspond to the encoding symbol(s) for the object carried in the packet's payload. 👑
It is RECOMMENDED that packet authentication be used. If packet authentication is used, then the Header Extensions described in Section 4.2 MAY be used to carry the authentication. 🔐
4.4. Receiver Operation 📥
the receiver side is giving the same energy 🫶 The receiver operation, when using ALC, includes all the points made about the receiver operation when using the LCT building block [RFC5651], the FEC building block [RFC5052], and the multiple rate congestion control building block. so again, all of those apply!
To be able to join a session, a receiver needs to get the required Session Description listed in Section 2.4. How receivers get a Session Description is outside the scope of this document, so that's a different story 🙈
As described in Section 2.3, a receiver needs to get the required FEC Object Transmission Information for each object it receives and processes packets for. 🧚
Upon receipt of each packet, the receiver goes through the following steps, in the order listed. this part is so important, pay attention 👀
- The receiver MUST parse the packet header and verify that it is a valid header. If it is not valid, then the packet MUST be discarded without further processing. 💅
- The receiver MUST verify that the sender IP address together with the
TSIcarried in the header matches one of the (sender IP address,TSI) pairs that was received in a Session Description and to which the receiver is currently joined. If there is not a match, then the packet MUST be silently discarded without further processing. The remaining steps are performed within the scope of the (sender IP address,TSI) session of the received packet. 🦋 - The receiver MUST process and act on the
CCIfield in accordance with the multiple rate congestion control building block. ⭐ - If more than one object is carried in the session, the receiver MUST verify that the
TOIcarried in the LCT header is valid. If theTOIis not valid, the packet MUST be discarded without further processing. 🌈 - The receiver SHOULD process the remainder of the packet, 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 the packet fails the check, then the receiver MUST silently discard the packet. 🔥
5. Security Considerations 🚨
okay this section is SERIOUS, bestie, so lock in 🔒 The same security considerations that apply to the LCT, FEC, and multiple rate congestion control building blocks also apply to ALC. no escape, they all come along for the ride 💀
ALC is especially vulnerable to denial-of-service attacks by attackers who try to send forged packets to the session. That would stop successful reconstruction or cause inaccurate reconstruction of large parts of the object for receivers 😭 ALC is also hit extra hard by this kind of attack because many receivers may get the same forged packet. There are two ways to protect against it, one at the application level and one at the packet level. It is RECOMMENDED that prevention be provided at both levels. 🛡️
At the application level, it is RECOMMENDED that an integrity check on the entire received object be done once the object is reconstructed, to make sure it's the same as the sent object. Moreover, to get strong cryptographic integrity protection, a digital signature that the receiver can verify SHOULD be used to provide this application-level integrity check. However, if even one corrupted or forged packet is used to reconstruct the object, the received object will likely be reconstructed incorrectly. That will properly make the integrity check fail, and in this case the inaccurately reconstructed object SHOULD be discarded. So, accepting a single forged packet can be an effective denial-of-service attack against distributing objects, but an object integrity check at least stops inaccurately reconstructed objects from being used by accident. Specifying an application-level integrity check of the received object is outside the scope of this document. 🙃
At the packet level, it is RECOMMENDED that packet-level authentication be used to make sure each received packet is authentic and uncorrupted, and that it contains data for the object arriving from the specified sender. Packet-level authentication has the advantage that corrupt or forged packets can be discarded one by one, and the received authenticated packets can still be used to accurately reconstruct the object. So the effect of a denial-of-service attack that injects forged packets only scales with the number of forged packets, not with the object size. 📈 [RMT-SIMPLE]and [RFC5776] described packet-level authentication schemes that can be used with the ALC protocol. 🧁
On top of protecting against inaccurate objects, packet-level authentication can also give some protection against denial-of-service attacks on the multiple rate congestion control. Attackers can try to inject forged packets with incorrect congestion control information into the multicast stream. That could adversely affect network elements and receivers downstream of the attack, and much less significantly the rest of the network and other receivers. So it is also RECOMMENDED that packet-level authentication be used to protect against such attacks. ⚠️ Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC5776] can also be used, to some extent, to limit the damage from such attacks. However, with TESLA, a receiver can only tell if a packet is authentic several seconds after receiving it. So an attack against the congestion control protocol can work for several seconds before the receiver can react and slow down the session reception rate. 😤
Some packet authentication schemes, such as TESLA [RFC5776], don't 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 that fail authentication checks within a session, 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. This limits the chance 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 applying the IPsec security protocol. It's documented here as a reference for an interoperable secure mode of operation. However, additional approaches to ALC security, including other forms of IPsec application, MAY be specified in the future. For example, using the EXT_AUTH Header Extension could let ALC-specific authentication or security encapsulation headers, similar to those of IPsec, be specified and inserted into the ALC/LCT protocol message headers. That would allow header compression techniques to be applied to IP and ALC protocol headers when needed, in a similar way to RTP [RFC3550] and as preserved in the specification for Secure Real Time Protocol (SRTP) [RFC3711]. 🌟
The baseline approach described is applicable to ALC operation configured for SSM (or SSM-like) operation, where there is a single sender. The receiver set would maintain a single IPsec Security Association (SA) for each ALC sender. 🫧
5.1.1. IPsec Approach 🔐
Okay so, to get this baseline secure ALC one-to-many SSM vibe going, every node SHALL be configured with a transport mode IPsec Security Association and a matching Security Policy Database (SPD) entry 💖. That entry handles sender-to-group multicast packet authentication and, optionally, encryption.
The ALC sender SHALL use an IPsec SA set up for Encapsulating Security Payload (ESP) protocol [RFC4303] operation, with the data origination authentication option turned on ✨. It's also RECOMMENDED that this ESP SA be configured to provide confidentiality protection for IP packets carrying ALC protocol messages. This is suggested to make complex replay attacks way harder to pull off 🙈. The encryption key for this SA SHALL be preplaced at the sender and receiver(s) before ALC protocol operation starts. Automated key management is RECOMMENDED, because a rekey SHALL be required before the sequence space for the SA runs out 🔄. This is necessary so receivers can use the built-in IPsec replay attack protection that's possible for an IPsec SA with a single source (the ALC sender). So the receivers SHALL enable replay attack protection for this SA used to secure ALC sender traffic 🛡️. The sender's IPsec SPD entry MUST be configured to process outbound packets to the destination address and UDP port number of the applicable ALC session.
The ALC receiver(s) MUST be configured with the SA and SPD entry so they can properly process the IPsec-secured packets from the sender 📦. Note that using ESP confidentiality, as RECOMMENDED, for secure ALC protocol operation makes it harder for adversaries to run effective replay attacks that could mislead receivers about what content they receive 🕵️♀️. This baseline approach can be used for ALC protocol sessions with multiple senders, as long as a distinct SA is established for each sender 🌈.
In early deployments of this baseline approach to ALC security, key management is expected to happen out-of-band with respect to ALC protocol operation 🧚. For ALC unidirectional operation, receivers may be able to fetch keying information from a central server through out-of-band (with respect to ALC) communication whenever they need it, or they can handle group key updates with a similar centralized approach. However, with some key management schemes, rekey messages may be sent to the group as a message or transport object within the ALC reliable transfer session 📬. An additional specification is necessary to define an in-band key management scheme for ALC sessions, perhaps using the mechanisms of the automated group key management specifications cited in this document 💜.
5.1.2. IPsec Requirements 🧩
In order to implement this secure mode of ALC protocol operation, the following IPsec capabilities are required 📝.
5.1.2.1. Selectors
The implementation MUST be able to use the source address, destination address, protocol (UDP), and UDP port numbers as selectors in the SPD 🎯.
5.1.2.2. Mode
IPsec in transport mode MUST be supported. Using IPsec [RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED, so that unauthenticated packets never reach the ALC protocol implementation 🚫.
5.1.2.3. Key Management
An automated key management scheme for group key distribution and rekeying, such as the Group Domain of Interpretation (GDOI) [RFC3547], Group Secure Association Key Management Protocol (GSAKMP) [RFC4535], or Multimedia Internet KEYing (MIKEY) [RFC3830], SHOULD be used 🔑. Relatively short-lived ALC sessions MAY be able to use Manual Keying with a single, preplaced key, particularly if Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec implementation being used 🦋. It should also be noted that key update messages (e.g., the GDOI GROUPKEY-PUSH message) may be included in the ALC application reliable data transmission as transport objects, if appropriate interfaces are available between the ALC application and the key management daemon 🫶.
5.1.2.4. Security Policy
Receivers SHOULD accept connections only from the designated, authorized sender(s) 🚧. It is expected that appropriate key management will provide encryption keys only to receivers authorized to take part in a designated session. The approach outlined here lets receiver sets be controlled on a per-sender basis 🎀.
5.1.2.5. Authentication and Encryption
Large ALC group sizes may call for some form of key management that relies on shared secrets 🍓. The GDOI and GSAKMP protocols mentioned here allow for certificate-based authentication. These certificates SHOULD use IP addresses for authentication. However, it's likely that available group key management implementations won't be ALC-specific 🤷♀️.
5.1.2.6. Availability
The IPsec requirements profile outlined here is commonly available on many potential ALC hosts 🌸. The main issue is that configuring and operating IPsec typically requires privileged user authorization 👑. Automated key management implementations are typically configured with the privileges needed to allow the required system IPsec configuration.
6. IANA Considerations 🗂️
This specification registers one value in the LCT Header Extensions Types namespace as follows:
+-------+---------+--------------------+
| Value | Name | Reference |
+-------+---------+--------------------+
| 64 | EXT_FTI | This specification |
+-------+---------+--------------------+7. Acknowledgments 🫶
This specification is substantially based on RFC 3450 [RFC3450], so credit for the authorship of this document goes primarily to the authors of RFC 3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano, Luigi Rizzo, and Jon Crowcroft 🏆. Vincent Roca, Justin Chapweske, and Roger Kermode also contributed to RFC 3450. Extra thanks go to Vincent Roca and Rod Walsh for their contributions to this update to Proposed Standard 💖.
8. Changes from RFC 3450 🔁
This section summarizes the changes that were made from the "Experimental" version of this specification, published as RFC 3450 [RFC3450]:
- Updated all references to the obsoleted RFC 2068 to RFC 2616.
- Removed the 'Statement of Intent' from the introduction. (The Statement of Intent was meant to clarify the "Experimental" status of RFC 3450.)
- Removed the 'Intellectual Property Issues' Section and replaced it with a standard IPR Statement.
- Removed material duplicated in LCT.
- Updated references in this document to new versions of the LCT Building Block and the FEC Building Block, and aligned this document with changes in the new version of the FEC Building Block.
- Split normative and informative references.
- Moved material applicable in a general LCT context, not just for ALC, to LCT.
- The first bit of the "Protocol-Specific Indication" in the LCT Header is defined as a "Source Packet Indication". This is used in the case that an FEC Scheme defines two FEC Payload ID formats, one of which is for packets containing only source symbols that can be processed by receivers that do not support FEC Decoding.
- Defined and registered the EXT_FTI LCT Header Extension with IANA.
9. References 📚
9.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
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 📚
Okay bestie, these are the informative refs. They're the extra reading that backs up the spec, so you don't need them to implement anything, but they're super good for context 🧠✨
- [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 Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
- [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
- [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
- [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
- [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
- [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
- [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
- [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
- [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
- [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 5776, April 2010.
- [RMT-SIMPLE] Roca, V., "Simple Authentication Schemes for the ALC and NORM Protocols", Work in Progress, October 2009.
Authors' Addresses 💌
The three authors all sat at the same Qualcomm address, so here are their contact details 🦋
Michael Luby
Qualcomm, Inc.
3165 Kifer Road
Santa Clara, CA 95051
US
EMail: luby@qualcomm.com
Mark Watson
Qualcomm, Inc.
3165 Kifer Road
Santa Clara, CA 95051
US
EMail: watson@qualcomm.com
Lorenzo Vicisano
Qualcomm, Inc.
3165 Kifer Road
Santa Clara, CA 95051
US
EMail: vicisano@qualcomm.comThat's the whole RFC, babe! 🌈💖 Bestie, you made it through the entire thing ✨👑
📦 where this page comes from
- ietf: rfc5775 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms