RFC 6726
FLUTE - File Delivery over Unidirectional Transport
Part 1 of 11 🎀 more parts are coming, bestie!
Okay, let's get into RFC 6726, the FLUTE spec 😭✨. It's a Standards Track document from the IETF (Internet Engineering Task Force 💅), published in November 2012. The authors are T. Paila (Nokia), R. Walsh (Nokia/TUT), M. Luby (Qualcomm Technologies, Inc.), V. Roca (INRIA), and R. Lehtonen (TeliaSonera). It's got ISSN 2070-1721, and it obsoletes RFC 3926, the older version, which was published as Experimental. It also updates ALC [RFC5775] and LCT [RFC5651] (more on that in the Introduction 🫶).
FLUTE stands for "File Delivery over Unidirectional Transport." The title is the vibe 🌈
Abstract ✨
So here's the tea 🍵. This doc defines File Delivery over Unidirectional Transport (FLUTE), a protocol for sending files one way over the Internet, and it's especially built for multicast networks 🦋. It builds on Asynchronous Layered Coding, the base protocol made for super-scalable multicast distribution. And yes, this document obsoletes RFC 3926.
Status of This Memo 📜
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 💜. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 🎀.
For the current status of this document, any errata, and how to send feedback, look at http://www.rfc-editor.org/info/rfc6726 🔥.
Copyright Notice ⚖️
Copyright (c) 2012 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 they stood on the publication date. Please read these carefully, because they explain your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the 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 include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭. Without 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 that process. The one exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌸.
Table of Contents 📚
1. Introduction ....................................................3
1.1. Applicability Statement ....................................5
1.1.1. The Target Application Space ........................5
1.1.2. The Target Scale ....................................5
1.1.3. Intended Environments ...............................5
1.1.4. Weaknesses ..........................................6
2. Conventions Used in This Document ...............................6
3. File Delivery ...................................................7
3.1. File Delivery Session ......................................8
3.2. File Delivery Table .......................................10
3.3. Dynamics of FDT Instances within a File Delivery Session ..12
3.4. Structure of FDT Instance Packets .........................15
3.4.1. Format of FDT Instance Header ......................16
3.4.2. Syntax of FDT Instance .............................17
3.4.3. Content Encoding of FDT Instance ...................21
3.5. Multiplexing of Files within a File Delivery Session ......22
4. Channels, Congestion Control, and Timing .......................23
5. Delivering FEC Object Transmission Information .................24
6. Describing File Delivery Sessions ..............................26
7. Security Considerations ........................................27
7.1. Problem Statement .........................................27
7.2. Attacks against the Data Flow .............................28
7.2.1. Access to Confidential Files .......................28
7.2.2. File Corruption ....................................28
7.3. Attacks against the Session Control Parameters and
Associated Building Blocks ................................30
7.3.1. Attacks against the Session Description ............30
7.3.2. Attacks against the FDT Instances ..................31
7.3.3. Attacks against the ALC/LCT Parameters .............31
7.3.4. Attacks against the Associated Building Blocks .....32
7.4. Other Security Considerations .............................32
7.5. Minimum Security Recommendations ..........................33
8. IANA Considerations ............................................34
8.1. Registration of the FDT Instance XML Namespace ............34
8.2. Registration of the FDT Instance XML Schema ...............34
8.3. Registration of the application/fdt+xml Media Type ........35
8.4. Creation of the FLUTE Content Encoding Algorithms
Registry ..................................................36
8.5. Registration of LCT Header Extension Types ................36
9. Acknowledgments ................................................36
10. Contributors ..................................................37
11. Change Log ....................................................37
11.1. RFC 3926 to This Document ................................37
12. References ....................................................40
12.1. Normative References .....................................40
12.2. Informative References ...................................41
Appendix A. Receiver Operation (Informative) ......................44
Appendix B. Example of FDT Instance (Informative) .................451. Introduction ✨
Okay, so this document defines FLUTE version 2, a protocol for sending files one way over the Internet 🦋. Heads up: this spec is not backwards compatible with the old experimental version from [RFC3926] (check Section 11 for the details 🙈). It builds on Asynchronous Layered Coding (ALC), version 1 [RFC5775], which is the base protocol made for massively scalable multicast distribution. ALC defines transport of arbitrary binary objects, but for file delivery, just moving objects around is not enough 😭. The end systems also need to know what the objects actually are.
So FLUTE is the technique that handles this. It's a mechanism for signaling and mapping the properties of files onto ALC concepts, so receivers can assign those parameters to the objects they get 💅. That's why, throughout this document, the term "file" refers to an "object" as ALC talks about it. Also, even though this spec often uses multicast addressing as its example, the techniques work just as well with unicast addressing 🌸.
This document is a specific transport application of ALC, and it adds the following:
- A definition of a file delivery session built on top of ALC, including transport details and timing constraints.
- In-band signaling of the transport parameters of the ALC session.
- In-band signaling of the properties of delivered files.
- Details about multiplexing multiple files within a session.
Here's how the spec is laid out 📚. Section 3 starts by defining the file delivery session. Then it introduces the File Delivery Table, which is the core of this spec 👑. It also covers how transmission objects get multiplexed within a file delivery session. Section 4 describes how congestion control and channels are used with FLUTE. Section 5 defines how the Forward Error Correction (FEC) Object Transmission Information gets delivered within a file delivery session. Section 6 defines the parameters you need for describing file delivery sessions in the general case. Section 7 outlines the security considerations for file delivery with FLUTE 😭. Finally, there are two informative appendices. Appendix A describes a receiver operation the spec envisions for the receiver of a file delivery session, and if you want to see a simple FLUTE example in action, go to Appendix A right away 🧚. Appendix B gives an example of a File Delivery Table.
This specification also contains part of the definitions needed to fully specify a Reliable Multicast Transport (RMT) protocol, following [RFC2357] 🎀.
This document obsoletes [RFC3926], which held a previous version of this spec and was published in the "Experimental" category 🥲. This Proposed Standard spec is based on [RFC3926], but it's been updated with accumulated experience and a maturing protocol since [RFC3926] came out. That experience applies both to this spec itself and to the congestion control strategies used with it ✨.
The differences between [RFC3926] and this document are listed in Section 11 🍓.
This document updates ALC [RFC5775] and Layered Coding Transport (LCT) [RFC5651] in the sense that it defines two new header extensions, EXT_FDT and EXT_CENC 🔥.
1.1. Applicability Statement 🧁
1.1.1. The Target Application Space 🌈
FLUTE works for delivering large and small files to lots of hosts, using delivery sessions that last several seconds or more 🦋. For example, FLUTE could deliver big software updates to many hosts at the same time 💖. It could also carry continuous but segmented data, like time-lined text for subtitling. That's where it can lean on the layering it inherits from ALC and LCT to scale the richness of the session to the network's congestion status 👑. It's also good for the basic transport of metadata, like Session Description Protocol (SDP) [RFC4566] files that let user applications reach multimedia sessions 🎀.
1.1.2. The Target Scale 💅
Massive scalability is a main design goal for FLUTE 🚀. IP multicast is inherently massively scalable, but the best-effort service it provides doesn't offer session management, congestion control, or reliability 🥺. FLUTE adds all of those by using ALC and IP multicast, and it does this without giving up any of IP multicast's built-in scalability 🫶.
That's the end of Part 1! 🌈💜
1.1.3. Intended Environments
okay so the environment stuff 🌍. Every environmental requirement and consideration that applies to the RMT building blocks FLUTE uses also applies to FLUTE, no cap 💅. That means the ALC protocol instantiation [RFC5775], the LCT building block [RFC5651], and the FEC building block [RFC5052].
FLUTE can do both multicast and unicast delivery 🦋, but its main thing is unidirectional multicast file delivery ✨. It needs connectivity between a sender and its receivers, but it does not require connectivity from the receivers back to the sender. Because its expectations are so low, FLUTE works with basically every kind of network: LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks 🛰️. literally iconic.
FLUTE is compatible with both IPv4 and IPv6, because no part of the packet is IP version specific 🌈. It works with both multicast models too: Any-Source Multicast (ASM) [RFC1112] and Source-Specific Multicast (SSM) [PAPER.SSM].
FLUTE is applicable for both shared networks, such as the Internet, when paired with a suitable congestion control building block 🚦, and for provisioned or controlled networks, such as wireless broadcast radio systems, when paired with a traffic-shaping building block 📡.
1.1.4. Weaknesses
ngl this part is where FLUTE has to admit a few things 🙈. FLUTE's congestion control protocols depend on a receiver being able to change its multicast subscriptions between multicast groups that support different rates and/or layered codings. If the network doesn't support that, the FLUTE congestion control protocols may not be a good fit for that network 💀.
FLUTE can also be used for point-to-point (unicast) communications. At a minimum, implementations of ALC MUST support the Wave and Equation Based Rate Control (WEBRC) [RFC3738] multiple-rate congestion control scheme [RFC5775]. However, WEBRC was designed for massively scalable multicast flows, so it isn't clear how well it suits the particular case of unicast flows 🤔. Using a separate point-to-point congestion control scheme is another option. How to do that is outside the scope of this document.
FLUTE provides reliability using the FEC building block 🛡️. This reduces the error rate as seen by applications. However, FLUTE does not give senders a way to verify whether receivers actually received things successfully, and specifying such a method is outside the scope of this document 😭.
2. Conventions Used in This Document
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 [RFC2119] 📖.
The terms "object" and "transmission object" line up with the definitions in ALC [RFC5775] and LCT [RFC5651] 🧚. The terms "file" and "source object" are pseudonyms for "object" 💜.
3. File Delivery
Asynchronous Layered Coding [RFC5775] is a protocol designed for delivering arbitrary binary objects 📦. It's especially suited to massively scalable, unidirectional multicast distribution 🚀. ALC provides the basic transport for FLUTE, so FLUTE inherits the requirements of ALC 🫶.
This specification is designed for delivering files 📁. Its core job is to define how the properties of the files get carried in-band, right along with the delivered files ✨.
For example, let's take a 5200-byte file referred to by "http://www.example.com/docs/file.txt" 🎀. Using this example, here are the properties the file delivery protocol needs to convey:
- Identifier of the file, expressed as a URI [RFC3986]. The identifier MAY provide a location for the file. In the above example: "http://www.example.com/docs/file.txt".
- File name (usually, this can be concluded from the URI). In the above example: "file.txt".
- File type, expressed as Internet Media Types (often referred to as "Media Types"). In the above example: "text/plain".
- File size, expressed in octets. In the above example: "5200". If the file is content encoded, then this is the file size before content encoding.
- Content encoding of the file, within transport. In the above example, the file could be encoded using ZLIB [RFC1950]. In this case, the size of the transmission object carrying the file would probably differ from the file size. The transmission object size is delivered to receivers as part of the FLUTE protocol.
- Security properties of the file, such as digital signatures, message digests, etc. For example, one could use S/MIME [RFC5751] as the content encoding type for files with this authentication wrapper, and one could use XML Digital Signatures (XML-DSIG) [RFC3275] to digitally sign the file. XML-DSIG can also be used to provide tamper prevention, e.g., in the Content-Location field. Content encoding is applied to file data before FEC protection.
For each unique file, FLUTE encodes the attributes listed above, plus other attributes, as children of an XML file element 🧾. A table of XML file elements gets transmitted as a special file called a 'File Delivery Table' (FDT) 🗂️. That's described more in the next subsection and in Section 3.2 👑.
3.1. File Delivery Session
ALC is a protocol instantiation of the Layered Coding Transport (LCT) building block [RFC5651]. So ALC inherits the session concept of LCT 💅. In this document, "ALC/LCT session" is used to collectively mean the interchangeable terms "ALC session" and "LCT session" 🦋.
An ALC/LCT session is a set of logically grouped ALC/LCT channels, all tied to a single sender sending ALC/LCT packets for one or more objects 🌸. An ALC/LCT channel is defined by the combination of a sender and an address that the sender associates with the channel. A receiver joins a channel to start receiving the data packets the sender sends to it, and a receiver leaves a channel to stop receiving data packets from it 🫧.
One of the fields in the ALC/LCT header is the Transport Session Identifier (TSI), an integer carried in a field of size 16, 32, or 48 bits 🔢. (Note that the TSI may be carried by other means, in which case it's absent from the LCT header [RFC5651].) The (source IP address, TSI) pair uniquely identifies a session 🔑. The TSI is scoped by the IP address, so the same TSI can be used by several source IP addresses at once 🤯. That means the receiver uses the (source IP address, TSI) pair from each packet to uniquely identify the session sending that packet. When a session carries multiple objects, the Transmission Object Identifier (TOI) field in the ALC/LCT header names the object used to generate each packet. Each object is associated with a unique TOI within the scope of a session 🧩.
A FLUTE session consistent with this specification MUST use FLUTE version 2 as specified in this document 💖. So all sessions consistent with this specification MUST set the FLUTE version to 2. The FLUTE version is carried within the EXT_FDT Header Extension (defined in Section 3.4.1) in the ALC/LCT layer. A FLUTE session consistent with this specification MUST use ALC version 1 as specified in [RFC5775], and LCT version 1 as specified in [RFC5651] ✨.
If multiple FLUTE sessions are sent to a channel, then receivers MUST determine the FLUTE protocol version, based on the version fields and the (source IP address, TSI) pair carried in the ALC/LCT header of the packet 🕵️♀️. Heads up: when a receiver first starts receiving packets, it might not know the FLUTE protocol version yet, because not every LCT packet carries the EXT_FDT header (the one with the FLUTE protocol version) 😭. A new receiver MAY keep an open binding in the LCT protocol layer between the TSI and the FLUTE protocol version, until the EXT_FDT header arrives. Alternatively, a new receiver MAY discover a binding between the TSI and the FLUTE protocol version via a session discovery protocol, which is out of scope of this document 🧭.
Heads up, bestie 🚨: if the sender's IP address isn't accessible to receivers, then the packets receivers can get contain an intermediate IP address instead. In that case, the TSI is scoped by this intermediate IP address of the sender for the duration of the session. For example, the sender might be behind a Network Address Translation (NAT) device that temporarily assigns an IP address for the sender, and then the TSI is scoped by the intermediate IP address the NAT assigned. Another example: the sender might send its original packets using IPv6, but some parts of the network aren't IPv6 capable. So there may be an IPv6-to-IPv4 translator that changes the IP address of the packets to a different IPv4 address. Receivers in the IPv4 portion of the network will then get packets containing that IPv4 address, so the TSI is scoped by the IPv4 address for them 🌐. How the IP address used to scope the session gets delivered to receivers, whether it's the sender's IP address or an intermediate one, is outside the scope of this document 🤷♀️.
When FLUTE is used for file delivery over ALC, the ALC/LCT session is called a file delivery session 📂. The ALC/LCT concept of 'object' then means either a 'file' or a 'File Delivery Table Instance' (Section 3.2) 🎀.
Additionally, the following rules apply 📋:
- The TOI field MUST be included in ALC packets sent within a FLUTE session, with one exception: ALC packets sent in a FLUTE session with the Close Session (A) flag set to
1(signaling the end of the session) and that contain no payload (carrying no information for any file or FDT) SHALL NOT carry the TOI. See Section 5.1 of [RFC5651] for the LCT definition of the Close Session flag, and see Section 4.2 of [RFC5775] for an example of using a TOI within an ALC packet 🧠. - The TOI value
0is reserved for the delivery of File Delivery Table Instances. Each non-expired File Delivery Table Instance is uniquely identified by an FDT Instance ID within the EXT_FDT header defined in Section 3.4.1 🗝️. - Each file in a file delivery session MUST be associated with a TOI (
>0) in the scope of that session 📌. - Information carried in the headers and the payload of a packet is scoped by the source IP address and the TSI. Information particular to the object carried in the headers and the payload of a packet is further scoped by the TOI for file objects, and is further scoped by both the TOI and the FDT Instance ID for FDT Instance objects 🫶.
3.2. File Delivery Table
okay bestie, so the File Delivery Table (FDT) 📋✨ is basically FLUTE's little cheat sheet that describes all the attributes of the files being delivered in a file delivery session 💖. The lists below are just examples, not a complete or exclusive set, so don't treat them as the whole story 🌸.
Here's what the FDT can describe about the delivery of a file 🚚:
- TOI value that represents the file
- FEC Object Transmission Information (including the FEC Encoding ID and, if relevant, the FEC Instance ID)
- Size of the transmission object carrying the file
- Aggregate rate of sending packets to all channels
And here's what it can describe about the file itself 📁🎀:
- Name, Identification, and Location of file (specified by the URI)
- Media type of file
- Size of file
- Encoding of file
- Message digest of file
Some of these attributes MUST be included in the file description entry for a file, and others are optional, as defined in Section 3.4.2 🫶. Not all of them are required, so chill 😌.
Logically, the FDT is a set of file description entries 🗂️ for the files in the session. Each file description entry MUST include the TOI for the file it describes and the URI identifying the file 🔑. The TOI in each entry is how FLUTE names the ALC/LCT data packets used to deliver that file, which is literally the main character move 👑. Each entry can also hold one or more descriptors that map those attributes to the file 🦋.
Each file delivery session MUST have an FDT that is local to that session 🏠. The FDT MUST provide a file description entry mapped to a TOI for each file appearing in the session 💅. Now, an object delivered in the ALC session that isn't described in the FDT (other than the FDT itself) is not considered a 'file' belonging to the session 🙈. If a receiver gets an object with an unmapped TOI (a non-zero TOI that the FDT doesn't resolve), it SHOULD, in general, be ignored by a FLUTE receiver 🚫. How to actually do that is out of scope for this spec 🤷♀️.
Heads up: a client that joins an active session MAY receive data packets for a TOI > 0 before it gets any FDT Instance 😭. For tips on making that less likely, see Section 3.3 🧚. Even if the TOI isn't mapped yet, it's hopefully just a transient moment ✨. When that happens, performance might improve by caching those packets for a reasonable time window and storage size 💜. These optimizations are use-case and implementation specific, so the details are beyond this document 🌈.
Inside the session, the FDT gets delivered as FDT Instances 📦. Each FDT Instance contains one or more file description entries of the FDT 💖. Any FDT Instance can be equal to, a subset of, a superset of, overlapping with, or complementary to any other FDT Instance 🌀. A certain FDT Instance may be repeated several times during a session, even after newer ones (with higher FDT Instance ID numbers) have already been sent 🔁. Each FDT Instance has at least one file description entry and at most the full set of entries for the files being delivered in the session 🍓.
A receiver keeps an FDT database 🗄️ for the file description entries it has received. The receiver maintains that database as FDT Instances come in, so at any moment the contents show the receiver's current view of the session's FDT 👀. Since every receiver behaves independently, you SHOULD NOT assume that the FDT database contents are the same for all receivers in a given session 🙅♀️. Like, it's giving "everyone has their own vibe" energy 💅.
Finally, the FDT database is an abstract concept, so how it's structured and maintained is up to each implementation 🧩. That means it's out of scope for this spec, periodt 💀✨.
3.3. Dynamics of FDT Instances within a File Delivery Session 🎀
okay so this part is all about how FDT Instances move around during a file delivery session, and bestie, the rules are lowkey the backbone of the whole thing 💅 here's the vibe:
- For every file delivered within a file delivery session, there MUST be a file description entry included in at least one FDT Instance sent within the session. A file description entry contains at a minimum the mapping between the TOI and the URI. 🦋
- An FDT Instance MAY appear in any part of the file delivery session, and packets for an FDT Instance MAY be interleaved with packets for other files or other FDT Instances within a session. 🌸
- The TOI value of '0' MUST be reserved for delivery of FDT Instances. The use of other TOI values (i.e., an integer > 0) for FDT Instances is outside the scope of this specification. 🔥
- The FDT Instance is identified by the use of a new fixed-length LCT Header Extension, EXT_FDT (defined later in this section). Each non-expired FDT Instance is uniquely identified within the file delivery session by its FDT Instance ID, carried by the EXT_FDT Header Extension. Any ALC/LCT packet carrying an FDT Instance MUST include EXT_FDT. ✨
- It is RECOMMENDED that an FDT Instance that contains the file description entry for a file be sent at least once before sending the described file within a file delivery session. This recommendation is intended to minimize the amount of file data that may be received by receivers in advance of the FDT Instance containing the entry for a file (such data must either be speculatively buffered or discarded). Note that this possibility cannot be completely eliminated, since the first transmission of FDT data might be lost. 🙈
- Within a file delivery session, any TOI > 0 MAY be described more than once. For example, a previous FDT Instance 0 describes a TOI of value '3'. Now, subsequent FDT Instances can either keep TOI '3' unmodified in the table, not include it, or augment the description. However, subsequent FDT Instances MUST NOT change the parameters already described for a specific TOI. 🧚
- An FDT Instance is valid until its expiration time. The expiration time is expressed within the FDT Instance payload as a UTF-8 decimal representation of a 32-bit unsigned integer. The value of this integer represents the 32 most significant bits of a 64-bit Network Time Protocol (NTP) [RFC5905] time value. These 32 bits provide an unsigned integer representing the time in seconds relative to 0 hours 1 January 1900 in the case of the prime epoch (era 0) [RFC5905]. The handling of time wraparound (to happen in 2036) requires that the associated epoch be considered. In any case, both a sender and a receiver easily determine to which (136-year) epoch the FDT Instance expiration time value pertains by choosing the epoch for which the expiration time is closest in time to the current time. ⏰
Here is an example. Let us imagine that a new FLUTE session is started on February 7th, 2036, 0h, i.e., at NTP time 4,294,944,000, a few hours before the end of epoch 0. In order to define an FDT Instance valid for the next 48 hours, The FLUTE sender sets an expiry time of 149,504. This FDT Instance will expire exactly on February 9th, 2036, 0h. A client that receives this FDT Instance on the 7th, 0h, just after it has been sent, immediately understands that this value corresponds to epoch 1. A client that joins the session on February 8th, 0h, i.e., at NTP time 63,104, epoch 1, immediately understands that the 149,504 NTP timestamp corresponds to epoch 1. 🌈
- The space of FDT Instance IDs is limited by the associated field size (i.e., 20 bits) in the EXT_FDT Header Extension (Section 3.4.1). Therefore, senders should take care to always have a large enough supply of available FDT Instance IDs when specifying FDT expiration times. 📦
- The receiver MUST NOT use a received FDT Instance to interpret packets received beyond the expiration time of the FDT Instance. 🚫
- A sender MUST use an expiration time in the future upon creation of an FDT Instance relative to its Sender Current Time (SCT). ⭐
- Any FEC Encoding ID MAY be used for the sending of FDT Instances. The default is to use the Compact No-Code FEC Encoding ID 0 [RFC5445] for the sending of FDT Instances. (Note that since FEC Encoding ID 0 is the default for FLUTE, this implies that Source Block Number and Encoding Symbol ID lengths both default to 16 bits each.) 💜
- If the receiver does not support the FEC Scheme indicated by the FEC Encoding ID, the receiver MUST NOT decode the associated FDT. 🙅
- It is RECOMMENDED that the mechanisms used for file attribute delivery SHOULD achieve a delivery probability that is higher than the file recovery probability and the file attributes SHOULD be delivered at this higher priority before the delivery of the associated files begins. 👑
Generally, a receiver needs to receive an FDT Instance describing a file before it is able to recover the file itself. In this sense, FDT Instances are of higher priority than files. Additionally, a FLUTE sender SHOULD assume that receivers will not receive all packets pertaining to FDT Instances. The way FDT Instances are transmitted has a large impact on satisfying the recommendation above. When there is a single file transmitted in the session, one way to satisfy the recommendation above is to repeatedly transmit on a regular enough basis FDT Instances describing the file while the file is being transmitted. If an FDT Instance is longer than one packet payload in length, it is RECOMMENDED that an FEC code that provides protection against loss be used for delivering this FDT Instance. When there are multiple files in a session concurrently being transmitted to receivers, the way the FDT Instances are structured and transmitted also has a large impact. As an example, a way to satisfy the recommendation above is to transmit an FDT Instance that describes all files currently being transmitted, and to transmit this FDT Instance reliably, using the same techniques as explained for the case when there is a single file transmitted in a session. If instead the concurrently transmitted files are described in separate FDT Instances, another way to satisfy this recommendation is to transmit all the relevant FDT Instances reliably, using the same techniques as explained for the case when there is a single file transmitted in a session. 🧩
In any case, how often the description of a file is sent in an FDT Instance, how often an FDT Instance is sent, and how much FEC protection is provided for an FDT Instance (if longer than one packet payload) are dependent on the particular application and are outside the scope of this document. 🤷♀️
Sometimes the various attributes associated with files that are to be delivered within the file delivery session are sent out-of-band. The details of how this is done are out of the scope of this document. However, it is still RECOMMENDED that any out-of-band transmission be managed in such a way that a receiver will be able to recover the attributes associated with a file at least as reliably as the receiver is able to receive enough packets containing encoding symbols to recover the file. For example, the probability of a randomly chosen receiver being able to recover a given file can often be estimated based on a statistical model of reception conditions, the amount of data transmitted, and the properties of any Forward Error Correction in use. The recommendation above suggests that mechanisms used for file attribute delivery should achieve a higher delivery probability than the file recovery probability. The sender MAY also continue sending the various file attributes in-band, in addition to the out-of-band transmission. 📬
3.4. Structure of FDT Instance Packets 🧱
FDT Instances are carried in ALC packets with TOI = 0 and with an additional REQUIRED LCT Header extension called the FDT Instance Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance ID that uniquely identifies FDT Instances within a file delivery session. Placement of the FDT Instance Header is the same as that of any other LCT Header Extension. There MAY be other LCT Header Extensions in use.
The FDT Instance is encoded for transmission, like any other object, using an FEC Scheme (which MAY be the Compact No-Code FEC Scheme). The LCT Header Extensions are followed by the FEC Payload ID, and finally the Encoding Symbols for the FDT Instance, which contains one or more file description entries. An FDT Instance MAY span several ALC packets -- the number of ALC packets is a function of the file attributes associated with the FDT Instance. The FDT Instance Header is carried in each ALC packet carrying the FDT Instance. The FDT Instance Header is identical for all ALC/LCT packets for a particular FDT Instance.
The overall format of ALC/LCT packets carrying an FDT Instance is depicted in Figure 1 below. All integer fields are carried in "big-endian" or "network order" format (i.e., most significant byte (octet) first). As defined in [RFC5775], all ALC/LCT packets are sent using UDP. 🌷
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default LCT header (with TOI = 0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT Header Extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FLUTE Payload: Encoding Symbol(s)
~ (for FDT Instance in an FDT packet) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Overall FDT Packet3.4.1. Format of FDT Instance Header ✨
okay so the FDT Instance Header (EXT_FDT) is a brand new fixed-length extension that's specific to the ALC Protocol-Instantiation, as defined in [RFC5651] 💅. its Header Extension Type (HET) is 192 🎀. here's the layout, bestie:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 192 | V | FDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: EXT_FDT Format 🦋
Version of FLUTE (V), 4 bits:
this spec is for FLUTE version 2, so in any ALC packet that carries an FDT Instance and belongs to the file delivery session as described here, you MUST set this field to 2. no cap, it's not optional 🫶
FDT Instance ID, 20 bits:
so for each file delivery session, FDT Instances start counting at 0 and go up by one for every new one. once you hit the max (2^20-1), it wraps around to the smallest FDT Instance ID value that was given to an expired FDT Instance 🔄. when the numbers wrap from a bigger value to a smaller one, the smaller one is treated as logically higher. the next FDT Instances then get the next available smallest value, so the IDs always keep logically increasing 📈 it's giving clean math, periodt 💖
- Senders MUST NOT reuse an FDT Instance ID value that is already in use for a non-expired FDT Instance. literally never double-book an ID that's still alive 🙈
- what happens when every single FDT Instance ID is being used by a non-expired FEC Instance is out of scope for this spec, so each FLUTE implementation decides for itself 🌸
- receipt of an FDT Instance that reuses an FDT Instance ID value currently used by a non-expired FDT Instance MUST be considered an error case. that's a big oof 💀
- how the receiver handles that error (e.g., leave the session or ignore the new FDT Instance) is also out of scope, and it's up to each FLUTE implementation 🧚
- Receivers MUST be ready to handle FDT Instance ID wraparound and situations where missing FDT Instance IDs result in increments larger than one. wraparound and skipped IDs are the main character moments here, so receivers need to be ready for both ✨👑
3.4.2. Syntax of FDT Instance ✨
okay bestie, this is where the FDT Instance gets its actual shape 💅 The file description entries are what do the mapping stuff from Section 3.2 above 🗺️
The FDT Instance is an Extensible Markup Language (XML) structure with one root element called FDT-Instance 🎀 The FDT-Instance element MUST contain the Expires attribute, which gives the expiration time of the FDT Instance ⏰ It can also MAY-contain the Complete attribute, which is a boolean. It can be set to 1 or true for TRUE, or 0 or false for FALSE 🦋
When it's TRUE, the Complete attribute is saying that this FDT Instance has every File entry, covering both the files delivered so far and the files still to be delivered in the session. That means no new data will show up in future FDT Instances in this session. Either the FDT Instances with higher ID numbers won't be used, or if they are used, they'll only give file parameters that match what's already been given in this one and the earlier ones 🤝 So Complete is how you get a full list of files for the whole FLUTE session (a "complete FDT") 📜
Now, if every FDT Instance the receiver has seen so far has no Complete attribute, the receiver MUST consider the session not complete, and new data MAY show up in future FDT Instances 👀 Having no Complete attribute is the same thing as getting FDT Instances with Complete set to FALSE 💜
The FDT-Instance element MAY contain attributes that give common parameters for all files in an FDT Instance ✨ Those attributes MAY also show up on individual files in the File element. If the same attribute is in both places, the one on the File element wins, no debate 👑
Every file being declared in an FDT Instance gets one file description entry, shown as an element called File, which is a child of the FDT Instance structure 🧚
The attributes on the File element stand for the attributes of the file being delivered in the file delivery session. The XML attribute name matches the MIME field name, and the XML attribute value matches the MIME field body [RFC2045] 🌸 Each File element MUST contain at least two attributes: TOI and Content-Location. TOI MUST be given a valid TOI value, as described in Section 3.3 🔥 Content-Location [RFC2616] MUST be given a syntactically valid URI, as defined in [RFC3986], that identifies the file being delivered. For example, it can be a URI with the http or file URI scheme 🌈 Only one Content-Location attribute is allowed per file. The Content-Location field MUST be treated as a string that identifies a file, so two different strings are two different identifiers 💅 Using Content-Location for anything other than identifying the object is out of scope for this specification 🙈 And if two File elements declare the same Content-Location but have different TOI values, the one with the greater FDT Instance ID is the newer instance (like a newer version) of the same File 🍓
Besides the mandatory attributes, the FDT-Instance element and the File element MAY contain other attributes. These are the ones specifically called out:
Content-TypeSHOULD be included, and when it's present, it MUST be used for the purpose defined in [RFC2616] 🎀- Where the length is described,
Content-LengthMUST be used for the purpose defined in [RFC2616]. The transfer length is the length of the transported object in octets. Receivers really need this, because the source block structure has to be known for the FEC decoder to recover the source blocks of the file, and the transfer length is often what you need to work out that structure 🧮 The transfer length usually differs from the original file length when content encoding is applied before transport, which is whenContent-Encodinggets used. If the file isn't content encoded before transport (soContent-Encodingisn't used), the transfer length is the original file length, andContent-Lengthis also the transfer length. But if the file IS content encoded before transport, like compressing it to cut down the octets sent, the transfer length is generally different from the original length. In that case, theTransfer-Lengthattribute MAY be used to carry the transfer length 📦 - Whenever content encoding is applied,
Content-EncodingMUST be included. WheneverContent-Encodingis included, it MUST be used as described in [RFC2616] 🌷 - Where the MD5 message digest is described,
Content-MD5MUST be used for the purpose defined in [RFC2616]. The goal here is a decoded object integrity service, for when transmission and/or FLUTE/ALC processing errors might happen (the chance of a collision is negligible in that case). It MUST NOT be regarded as a security mechanism, so check Section 7 for the security measures 🔒 - The FEC Object Transmission Information attributes are described in Section 5 🦋
The following specifies the XML Schema [XML-Schema-Part-1] [XML-Schema-Part-2] for the FDT Instance 🧾
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:ietf:params:xml:ns:fdt"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:fdt"
elementFormDefault="qualified">
<xs:element name="FDT-Instance" type="FDT-InstanceType"/>
<xs:complexType name="FDT-InstanceType">
<xs:sequence>
<xs:element name="File" type="FileType" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Expires"
type="xs:string"
use="required"/>
<xs:attribute name="Complete"
type="xs:boolean"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedByte"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Scheme-Specific-Info"
type="xs:base64Binary"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:complexType name="FileType">
<xs:sequence>
<xs:any namespace="##other" processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Content-Location"
type="xs:anyURI"
use="required"/>
<xs:attribute name="TOI"
type="xs:positiveInteger"
use="required"/>
<xs:attribute name="Content-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Transfer-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-MD5"
type="xs:base64Binary"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedByte"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Scheme-Specific-Info"
type="xs:base64Binary"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:schema>
ENDFigure 3: XML Schema for the FDT Instance 🎀
Any valid FDT Instance MUST use the XML Schema above. This is how FDT stays extensible for private elements and private attributes in the file description entries 🧩 Those could be things like attributes about delivering the file (timing, packet transmission rate, etc.) ⏱️ Unsupported private elements and attributes SHOULD be silently ignored by a FLUTE receiver 🫶
If the basic FDT XML Schema gets extended with new descriptors (attributes or elements), any descriptor that applies to a single file MUST be placed within the File element. Any descriptor that applies to all files in the current FDT Instance MUST be placed within the FDT-Instance element 🌸 It is RECOMMENDED that new attributes in the FDT follow the format of message header fields, and that they're either defined in the HTTP/1.1 specification [RFC2616] or another well-known specification, or in an IANA registry [IANAheaderfields] 💜 That said, this specification doesn't stop anyone from using other formats for private attributes when interoperability isn't a concern 🦋
3.4.3. Content Encoding of FDT Instance ✨
okay bestie, the FDT Instance itself MAY be content encoded (think compressed, like zipping it up 🎀). This spec defines the FDT Instance Content Encoding Header, aka EXT_CENC 💅. It's a brand new fixed-length LCT Header Extension [RFC5651], and its Header Extension Type (HET) is 193. If the FDT Instance is content encoded, EXT_CENC MUST be used to signal the content encoding type. In that case, the EXT_CENC Header Extension MUST be used in every ALC packet carrying the same FDT Instance ID (consistency is everything 😭). When EXT_CENC shows up, it MUST be used together with a proper FDT Instance Header (EXT_FDT). Within one file delivery session, content encoded and non-content encoded FDT Instances MAY both appear 🌈. If content encoding isn't used for a given FDT Instance, EXT_CENC MUST NOT be used in any packet carrying that FDT Instance. Here's the format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 193 | CENC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: EXT_CENC Format 🧚
Content Encoding Algorithm (CENC), 8 bits: this field signals which content encoding algorithm was used on the FDT Instance payload. This subsection reserves the Content Encoding Algorithm values 0, 1, 2, and 3 for null, ZLIB [RFC1950], DEFLATE [RFC1951], and GZIP [RFC1952], respectively.
Reserved, 16 bits: this field MUST be set to all '0's. This field MUST be ignored on reception. 🙈
3.5. Multiplexing of Files within a File Delivery Session 🦋
The delivered files travel as transmission objects (identified with TOIs) in the session. All of these, FDT Instances included, MAY be multiplexed in any order and in parallel with each other within a session. So packets for one file can be interleaved with packets for other files or other FDT Instances, and that's totally a vibe 🌸.
Multiple FDT Instances MAY be delivered in a single session using TOI = 0. In this case, it is RECOMMENDED that the sending of a previous FDT Instance SHOULD end before the sending of the next FDT Instance starts. However, due to unexpected network conditions, packets for the FDT Instances might get interleaved 😩. Receivers can still tell which FDT Instance a packet is about, because the FDT Instances are uniquely identified by their FDT Instance ID carried in the EXT_FDT headers 🔥.
4. Channels, Congestion Control, and Timing 👑
ALC/LCT has a concept of channels and congestion control. FLUTE is envisioned for four scenarios, and I'm obsessed with how they're laid out 💜:
(a) Use of a single channel and a single-rate congestion control protocol.
(b) Use of multiple channels and a multiple-rate congestion control protocol. In this case, the FDT Instances MAY be delivered on more than one channel.
(c) Use of a single channel without congestion control supplied by ALC, but only when in a controlled network environment where flow/congestion control is being provided by other means.
(d) Use of multiple channels without congestion control supplied by ALC, but only when in a controlled network environment where flow/congestion control is being provided by other means. In this case, the FDT Instances MAY be delivered on more than one channel.
When you're using just one channel for a file delivery session, as in (a) and (c), the notions of 'prior' and 'after' are super intuitive for objects, based on their delivery times. 🍓
But if multiple channels are used, as in (b) and (d), it's not straightforward to say an object was delivered 'prior' to another one 🙃. An object can start being delivered on one or more of those channels before a second object starts. However, using multiple channels or layers can mean the second object finishes before the first. This is not a problem when objects are delivered sequentially over a single channel. So if the application of FLUTE has a mandatory or critical requirement that the first transmission object has to complete 'prior' to the second one, it is RECOMMENDED that only a single channel be used for the file delivery session. 💅
Furthermore, if multiple channels are used, a receiver joined to the session at a low reception rate will only be joined to the lower layers of the session. Since receiving FDT Instances is a higher priority than receiving files (because receiving files depends on receiving an FDT Instance describing them), the following are RECOMMENDED:
- The layers to which packets for FDT Instances are sent SHOULD NOT be biased towards those layers to which lower-rate receivers are not joined. For example, it's okay to put all the packets for an FDT Instance into the lowest layer (if this layer carries enough packets to deliver the FDT to higher-rate receivers in a reasonable amount of time), but it's not okay to put all the packets for an FDT Instance into the higher layers that only higher-rate receivers will receive. 🌈
- If FDT Instances are generally longer than one Encoding Symbol in length, and some packets for FDT Instances are sent to layers that lower-rate receivers don't receive, an FEC encoding other than Compact No-Code FEC Encoding ID 0 [RFC5445] SHOULD be used to deliver FDT Instances. This is because in this case, even when there's no packet loss in the network, a lower-rate receiver won't receive all the packets sent for an FDT Instance. 😭
5. Delivering FEC Object Transmission Information 🌸
FLUTE inherits the use of the FEC building block [RFC5052] from ALC. When using FLUTE for file delivery over ALC, the FEC Object Transmission Information MUST be delivered in-band within the file delivery session. There are two methods to achieve this: the ALC-specific LCT Header Extension EXT_FTI [RFC5775], and the FDT. This section specifies the FDT method. EXT_FTI needs the FEC Object Transmission Information repeated to make sure it gets received (though not necessarily in every packet), so it can mean more overhead than the FDT, but it can also give more timely delivery of the FEC Object Transmission Information. ⏰
The receiver of a file delivery session MUST support delivery of FEC Object Transmission Information using EXT_FTI for the FDT Instances carried using TOI value 0. For TOI values other than 0, the receiver MUST support both methods: the use of EXT_FTI and the use of the FDT. 🫶
The FEC Object Transmission Information that needs to be delivered to receivers MUST be exactly the same whether it is delivered using EXT_FTI or using the FDT (or both). The FEC Object Transmission Information that MUST be delivered to receivers is defined by the FEC Scheme. This section describes the delivery using the FDT. 🎀
The FEC Object Transmission Information regarding a given TOI can be available from several sources. In this case, it is RECOMMENDED that the receiver of the file delivery session prioritize the sources in the following way (in order of decreasing priority). 👑
- FEC Object Transmission Information that is available in EXT_FTI.
- FEC Object Transmission Information that is available in the FDT.
The FDT delivers FEC Object Transmission Information for each file using an appropriate attribute within the "FDT-Instance" or the "File" element of the FDT structure. ✨
Transfer-Lengthcarries the "Transfer-Length" Object Transmission Information element defined in [RFC5052].FEC-OTI-FEC-Encoding-IDcarries the "FEC Encoding ID" Object Transmission Information element defined in [RFC5052], as carried in the Codepoint field of the ALC/LCT header.FEC-OTI-FEC-Instance-IDcarries the "FEC Instance ID" Object Transmission Information element defined in [RFC5052] for Under-Specified FEC Schemes.FEC-OTI-Maximum-Source-Block-Lengthcarries the "Maximum-Source-Block-Length" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.FEC-OTI-Encoding-Symbol-Lengthcarries the "Encoding-Symbol-Length" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.FEC-OTI-Max-Number-of-Encoding-Symbolscarries the "Max-Number-of-Encoding-Symbols" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.FEC-OTI-Scheme-Specific-Infocarries the "encoded Scheme-specific FEC Object Transmission Information" as defined in [RFC5052], if required by the FEC Scheme.
In FLUTE, the FEC Encoding ID (8 bits) for a given TOI MUST be carried in the Codepoint field of the ALC/LCT header. When the FEC Object Transmission Information for this TOI is delivered through the FDT, then the associated FEC-OTI-FEC-Encoding-ID attribute and the Codepoint field of all packets for this TOI MUST be the same. 💖
6. Describing File Delivery Sessions ✨
okay so bestie, before a receiver can join a file delivery session, it needs the transport parameters for that session 🎀 Figuring those out and starting reception is the entry point, and everything after that is the part this spec covers 💅 According to [RFC5775], the ALC/LCT transport parameters the receiver needs to know are:
- The source IP address;
- The number of channels in the session;
- The destination IP address and port number for each channel in the session;
- The Transport Session Identifier (TSI) of the session;
- An indication that the session is a FLUTE session. Demultiplexing objects on reception is implied by using FLUTE at all, and that covers the ALC requirement to say whether a session carries packets for more than one object (all FLUTE sessions do 🦋).
Optionally, the following parameters MAY be associated with the session (the list is not exhaustive, so there's more out there 🌸):
- The start time and end time of the session;
- FEC Encoding ID and FEC Instance ID when the default FEC Encoding ID 0 is not used for the delivery of the FDT;
- Content encoding format if optional content encoding of the FDT Instance is used, e.g., compression;
- Some information that tells receiver, in the first place, that the session contains files that are of interest;
- Definition and configuration of a congestion control mechanism for the session;
- Security parameters relevant for the session;
- FLUTE version number.
It's envisioned that these parameters get described using some session description syntax (like SDP [RFC4566] or something XML based) and kept in a file the receiver grabs before the FLUTE session starts. The file can come through a transport protocol like the Session Announcement Protocol (SAP) [RFC2974], email, HTTP [RFC2616], SIP [RFC3261], manual preconfiguration, etc. 📬 But how the receiver discovers those parameters is out of scope for this document, same as for LCT and ALC. This spec doesn't require or rule out any mechanism, so it's giving "your call" 💜
7. Security Considerations ⚠️
7.1. Problem Statement
okay, security time, and honestly this part is dramatic 😭 A content delivery system can be attacked. The targets can be:
- the network (to compromise the routing infrastructure, e.g., by creating congestion),
- the Content Delivery Protocol (CDP) (e.g., to compromise the normal behavior of FLUTE), or
- the content itself (e.g., to corrupt the files being transmitted).
These attacks can be launched:
- against the data flow itself (e.g., by sending forged packets),
- against the session control parameters (e.g., by corrupting the session description, the FDT Instances, or the ALC/LCT control parameters) that are sent either in-band or out-of-band, or
- against some associated building blocks (e.g., the congestion control component).
In the following sections we get into more detail on these possible attacks and sketch some countermeasures 🛡️ Our recommendations are in Section 7.5 💖
7.2. Attacks against the Data Flow
let's start with attacks on the data flow 👀 At the very least, these types exist:
- attacks that are meant to give access to a confidential file (e.g., in the case of non-free content) and
- attacks that try to corrupt the file being transmitted (e.g., to inject malicious code within a file, or to stop a receiver from using a file, which is a kind of denial of service (DoS)).
7.2.1. Access to Confidential Files
access control for the file being transmitted is usually handled by encryption 🔐 That encryption can cover the whole file, meaning before FEC protection (e.g., by the content provider, before submitting the file to FLUTE), or it can happen packet by packet (e.g., when IPsec/ESP [RFC4303] is used; see Section 7.5). If confidentiality matters to you, it is RECOMMENDED that one of these solutions be used. 🫶
7.2.2. File Corruption
protection against corruption (e.g., if an attacker sends forged packets) comes from a content integrity verification / sender authentication scheme 🧚 This service can work at the file level, meaning before content encoding and FEC encoding. In that case, a receiver has no way to tell which symbol(s) got corrupted if the file is detected as corrupted 😭 It can also work at the packet level, meaning after content encoding and FEC encoding, on a packet-by-packet basis. Then, after removing all the corrupted packets, the file may in some cases still be recovered from the remaining correct packets ✨
File-level integrity protection has the advantage of lower overhead, since only relatively few bits get added compared to the file size. The downside is that it can't tell correct packets from corrupt ones, so correct packets, which may be the majority of what was received, could end up unusable 💀 Packet-level integrity protection can tell correct and corrupt packets apart, but it costs extra overhead per packet.
Several techniques can provide this source authentication / content integrity service:
- At the file level, the file MAY be digitally signed (e.g., by using RSA Probabilistic Signature Scheme Public-Key Cryptography Standards version 1.5 (RSASSA-PKCS1-v1_5) [RFC3447]). The signature lets a receiver check the file's integrity once the file has been fully decoded. Digital signatures are computationally expensive, but this calculation happens only once per file, which is usually fine 🌈
- At the packet level, each packet can be digitally signed [RFC6584]. The big limitation is the high computational and transmission overhead this needs 😵 To avoid that, the signature may span a set of symbols (instead of a single one) to amortize the signature calculation, but if a single symbol is missing, the integrity of the whole set can't be checked.
- At the packet level, a Group-Keyed Message Authentication Code (MAC) [RFC2104] [RFC6584] scheme can be used; an example is using HMAC-SHA-256 with a secret key shared by all the group members, senders, and receivers. This technique creates a cryptographically secured digest of a packet that is sent along with the packet. The Group-Keyed MAC scheme doesn't create prohibitive processing load or transmission overhead, but it has a major limitation: it only provides a group authentication / integrity service, since all group members share the same secret group key, which means each member can send a forged packet 🙈 So it's restricted to situations where group members are fully trusted (or used together with another technique as a pre-check).
- At the packet level, Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082] [RFC5776] is an attractive solution: it's robust to losses, provides a true authentication / integrity service, and doesn't create any prohibitive processing load or transmission overhead 🦋 The catch is that checking a packet needs a small delay (a second or more) after it's received.
- At the packet level, IPsec/ESP [RFC4303] can be used to check the integrity and authenticate the sender of all the packets exchanged in a session (see Section 7.5).
Techniques relying on public key cryptography (digital signatures, and TESLA during the bootstrap process when it's used) require that public keys be securely associated with the entities. That can be done with a Public Key Infrastructure (PKI), a Pretty Good Privacy (PGP) Web of Trust, or by pre-distributing the public keys of each group member 🔑
Techniques relying on symmetric key cryptography (Group-Keyed MAC) require that a secret key be shared by all group members. That can be done with a group key management protocol, or by simply pre-distributing the secret key (but this manual approach has lots of limitations).
It's up to the developer and deployer, who know the security requirements and features of the target application area, to decide which solution is most appropriate 💅 Still, if there's any concern about file corruption, it is RECOMMENDED that at least one of these techniques be used. 🎀
7.3. Attacks against the Session Control Parameters and Associated Building Blocks
now let's look at attacks on the session control parameters and the associated building blocks 🧐 The attacker has at least these chances to launch an attack:
- the attack can target the session description,
- the attack can target the FDT Instances,
- the attack can target the ALC/LCT parameters, carried within the LCT header, or
- the attack can target the FLUTE associated building blocks (e.g., the multiple-rate congestion control protocol).
The consequences can be really serious, since they might compromise how the content delivery system behaves itself 😱
7.3.1. Attacks against the Session Description
a FLUTE receiver may end up with an incorrect session description for the session. The result is that legitimate receivers with the wrong session description can't correctly receive the session content, or receivers accidentally try to receive at a much higher rate than they can handle, which could disrupt other traffic on the network 🍓
To avoid these problems, it is RECOMMENDED that measures be taken to stop receivers from accepting incorrect session descriptions. One such measure is source authentication, so receivers only accept legitimate session descriptions from authorized senders. How these measures are achieved is outside the scope of this document, since the session description is usually carried out-of-band 🌸
7.3.2. Attacks against the FDT Instances 📜✨
Messing with the FDT Instances is one way to pull off a DoS attack, bestie 😈. For example, the attacker changes the MD5 sum attached to a file. That could make a receiver reject the files it got, even when they arrived perfectly fine 💀.
Corrupting the FDT Instances is also a way to make reception way more expensive than it should be 💸. This can happen by changing the FEC Object Transmission Information, but only when that info is included in the FDT Instance. For example, an attacker could corrupt the FDT Instance so that Reed-Solomon over GF(2^^16) gets used instead of GF(2^^8) with FEC Encoding ID 2 🙈. This may seriously ramp up the processing load while messing with FEC decoding 🔥.
More generally, FDT Instance data is structured with XML and sent under an XML media type, so many of the security considerations in [RFC3023] and [RFC3470] apply to that data too 🧾.
So yeah, it is RECOMMENDED that you take measures to guarantee the integrity of the FDT Instances and check who the sender is 🫶. For that, one of the countermeasures mentioned above (Section 7.2.2) SHOULD be used. These measures can be applied at the packet level or globally over the whole FDT Instance object. Also, XML digital signatures [RFC3275] are a way to protect the FDT Instance by signing it digitally ✍️. When there is no packet-level integrity verification scheme, it is RECOMMENDED to rely on XML digital signatures of the FDT Instances 💜.
7.3.3. Attacks against the ALC/LCT Parameters 🦋
By corrupting the ALC/LCT header (or its header extensions), someone can run attacks on the underlying ALC/LCT implementation 😤. For example, sending forged ALC packets with the Close Session flag (A) set to one can make the receiver close the session too early. Similarly, sending forged ALC packets with the Close Object flag (B) set to one can make the receiver give up on an object too early 🥲.
It is therefore RECOMMENDED that measures be taken to guarantee the integrity of the ALC packets received and to check the sender's identity 🔐. For that, one of the countermeasures mentioned above (Section 7.2.2) SHOULD be used.
7.3.4. Attacks against the Associated Building Blocks 🧱
Okay, let's start with the congestion control building block, which may be used in the ALC session. A receiver with an incorrect or corrupted implementation of the multiple-rate congestion control building block may hurt the health of the network along the path between the sender and that receiver 😬. It can also mess with the reception rates of other receivers who joined the session.
When the congestion control building block is applied with FLUTE, it is RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the session description needed to join the session 🪪. How receivers identify themselves as legitimate is outside the scope of this document 🤷. If authenticating a receiver does not stop that receiver from launching an attack, the authentication still lets the network operator identify them and take countermeasures 🕵️.
When the congestion control building block is applied with FLUTE, it is also RECOMMENDED that a packet-level authentication scheme be used, as explained in Section 7.2.2 🎀. Some of them, like TESLA, only provide a delayed authentication service, whereas congestion control requires a rapid reaction ⏰. It is therefore RECOMMENDED [RFC5775] that a receiver using TESLA quickly reduce its subscription level when it believes that congestion did occur, even if the packet has not yet been authenticated. Therefore, TESLA will not prevent DoS attacks where an attacker makes the receiver believe that congestion occurred. This is an issue for the receiver, but it will not compromise the network 🙃. Other authentication methods that do not feature this delayed authentication could be preferred, or a Group-Keyed MAC scheme could be used in parallel with TESLA to prevent attacks launched from outside of the group 🧑🤝🧑.
7.4. Other Security Considerations 🛡️
The security considerations that apply to, and are described in, ALC [RFC5775], LCT [RFC5651], and FEC [RFC5052] also apply to FLUTE, since FLUTE builds on those specifications 📚. In addition, any security considerations that apply to any congestion control building block used in conjunction with FLUTE also apply to FLUTE 🔁.
Even though FLUTE defines a purely unidirectional delivery service, with no feedback sent back to the sender, security considerations MAY require bidirectional communications 🔄. For instance, if an automated key management scheme is used, a bidirectional point-to-point channel is often needed to establish a shared secret between each receiver and the sender. Each shared secret can then be used to distribute additional keys to the associated receiver (e.g., traffic encryption keys) 🔑.
As an example, [MBMSsecurity] details a complete security framework for the Third Generation Partnership Project (3GPP) Multimedia Broadcast/Multicast Service (MBMS) that relies on FLUTE/ALC for Download Sessions 📡. It relies on bidirectional point-to-point communications for User Equipment authentication and for key distribution, using the Multimedia Internet KEYing (MIKEY) protocol [RFC3830]. Because this security framework is specific to this use case, it cannot be reused as such for generic security recommendations in this specification. Instead, the following section introduces minimum security recommendations 📝.
7.5. Minimum Security Recommendations 🔐
We now introduce a mandatory-to-implement, but not necessarily to use, security configuration, in the sense of [RFC3365] 💅. Since FLUTE relies on ALC/LCT, it inherits the "baseline secure ALC operation" of [RFC5775]. More precisely, security is achieved by means of IPsec/ESP in transport mode. [RFC4303] explains that ESP can be used to potentially provide confidentiality, data origin authentication, content integrity, anti-replay, and (limited) traffic flow confidentiality. [RFC5775] specifies that the data origin authentication, content integrity, and anti-replay services SHALL be supported, and that the confidentiality service is RECOMMENDED. If a short-lived session MAY rely on manual keying, it is also RECOMMENDED that an automated key management scheme be used, especially in the case of long-lived sessions 🗝️.
Therefore, the RECOMMENDED solution for FLUTE provides per-packet security, with data origin authentication, integrity verification, and anti-replay ✨. This is sufficient to prevent most of the in-band attacks listed above. If confidentiality is required, a per-packet encryption SHOULD also be used 🎀.
8. IANA Considerations 📋
This specification contains five separate items upon which IANA has taken action:
- Registration of the FDT Instance XML Namespace.
- Registration of the FDT Instance XML Schema.
- Registration of the application/fdt+xml Media Type.
- Registration of the Content Encoding Algorithms.
- Registration of two LCT Header Extension Types (EXT_FDT and EXT_CENC).
8.1. Registration of the FDT Instance XML Namespace 🏷️
IANA has registered the following new XML Namespace in the IETF XML "ns" registry [RFC3688] at http://www.iana.org/assignments/xml-registry/ns.html.
URI: urn:ietf:params:xml:ns:fdt
Registrant Contact: Toni Paila (toni.paila@gmail.com)
XML: N/A8.2. Registration of the FDT Instance XML Schema 🗂️
IANA has registered the following in the IETF XML "schema" registry [RFC3688] at http://www.iana.org/assignments/xml-registry/schema.html.
URI: urn:ietf:params:xml:schema:fdt
Registrant Contact: Toni Paila (toni.paila@gmail.com)
XML: The XML Schema specified in Section 3.4.28.3. Registration of the application/fdt+xml Media Type 💖
IANA has registered the following in the "Application Media Types" registry at http://www.iana.org/assignments/media-types/application/.
Type name: application
Subtype name: fdt+xml
Required parameters: none
Optional parameters: charset="utf-8"
Encoding considerations: binary (the FLUTE file delivery protocol
does not impose any restriction on the objects it carries and in
particular on the FDT Instance itself)
Restrictions on usage: none
Security considerations: fdt+xml data is passive and does not
generally represent a unique or new security threat. However, there
is some risk in sharing any kind of data, in that unintentional
information may be exposed, and that risk applies to fdt+xml data as
well.
Interoperability considerations: None
Published specification: [RFC6726], especially noting Section 3.4.2.
The specified FDT Instance functions as an actual media format of use
to the general Internet community, and thus media type registration
under the Standards Tree is appropriate to maximize interoperability.
Applications that use this media type: file and object delivery
applications and protocols (e.g., FLUTE).
Additional information:
Magic number(s): none
File extension(s): ".fdt" (e.g., if there is a need to store an
FDT Instance as a file)
Macintosh File Type Code(s): none
Person and email address to contact for further information:
Toni Paila (toni.paila@gmail.com)
Intended usage: Common
Author/Change controller: IETF8.4. Creation of the FLUTE Content Encoding Algorithms Registry 🎶
IANA has created a new registry, "FLUTE Content Encoding Algorithms", with a reference to [RFC6726]; see Section 3.4.3. The registry entries consist of a numeric value from 0 to 255, inclusive, and may be registered using the Specification Required policy [RFC5226].
The initial contents of the registry are as follows, with unspecified values available for new registrations 🍓:
+-------+----------------+-----------+
| Value | Algorithm Name | Reference |
+-------+----------------+-----------+
| 0 | null | [RFC6726] |
| 1 | ZLIB | [RFC1950] |
| 2 | DEFLATE | [RFC1951] |
| 3 | GZIP | [RFC1952] |
+-------+----------------+-----------+8.5. Registration of LCT Header Extension Types 🧩
IANA has registered two new entries in the "Layered Coding Transport (LCT) Header Extension Types" registry [RFC5651], as follows:
+--------+----------+-------------------------+
| Number | Name | Reference |
+--------+----------+-------------------------+
| 192 | EXT_FDT | [RFC6726] Section 3.4.1 |
| 193 | EXT_CENC | [RFC6726] Section 3.4.3 |
+--------+----------+-------------------------+9. Acknowledgments 🌟
The following persons have contributed to this specification: Brian Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma, Topi Pohjolainen, Lorenzo Vicisano, Mark Watson, David Harrington, Ben Campbell, Stephen Farrell, Robert Sparks, Ronald Bonica, Francis Dupont, Peter Saint-Andre, Don Gillies, and Barry Leiba. The authors would like to thank all the contributors for their valuable work in reviewing and providing feedback regarding this specification 🫶💜
10. Contributors ✨
Okay, bestie, shoutout to the people who helped build this 🫶 Here are the contributors, with their contact info exactly as listed:
Jani Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FIN-33101
Finland
EMail: jani.peltotalo@tut.fi
Sami Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FIN-33101
Finland
EMail: sami.peltotalo@tut.fi
Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm
Sweden
EMail: magnus.westerlund@ericsson.com
Thorsten Lohmar
Ericsson Research (EDD)
Ericsson Allee 1
52134 Herzogenrath
Germany
EMail: thorsten.lohmar@ericsson.com11. Change Log 🦋
11.1. RFC 3926 to This Document
- Okay so the FLUTE protocol version went from 1 to 2 because of backwards compatibility worries 😭 The LCT header changed between RFC 3451 and [RFC5651]. In RFC 3451, the
TandRfields indicate the presence of Sender Current Time and Expected Residual Time, respectively. In [RFC5651], these fields MUST be set to zero and MUST be ignored by receivers (theEXT_TIMEHeader Extensions can carry this info if needed instead). So [RFC5651] is not backwards compatible with RFC 3451, even though both use LCT version 1. FLUTE version 1 as specified in [RFC3926] MUST use RFC 3451. FLUTE version 2 as specified in this document MUST use [RFC5651]. Therefore, an implementation that relies on [RFC3926] and RFC 3451 will not be backwards compatible with FLUTE as specified in this document. Major mood 💀 - Updated dependencies to revised versions of other RFCs. For example, the ALC reference changed from RFC 3450 to [RFC5775], and the LCT reference changed from RFC 3451 to [RFC5651], etc. 🌸
- Added clarification for using FLUTE for unicast communications in Section 1.1.4. 💅
- Clarified how to reliably deliver the FDT in Section 3.3, plus the possibility of out-of-band delivery of FDT information. 🎀
- Clarified how to handle FDT Instance expiration time wraparound with the NTPv4 "epoch" notion in Section 3.3. ✨
- Clarified what should be considered erroneous situations in Section 3.4.1 (definition of FDT Instance ID). Most importantly, a receiver MUST be ready to handle FDT Instance ID wraparounds and missing FDT Instances. Non-negotiable 🔥
- Updated Section 7.5 to define IPsec/ESP as a mandatory-to-implement security solution. 🔐
- Removed the "Statement of Intent" from Section 1. It was meant to clarify the "Experimental" status of [RFC3926], and it doesn't apply to this document anymore 🙈
- Added clarification of "XML-DSIG" near the end of Section 3. 🧚
- In Section 3.2, replaced "complete FDT" with text that is more descriptive. 🍓
- Clarified Figure 1 with regard to "Encoding Symbol(s) for FDT Instance". 🌈
- Clarified the text on FDT Instance ID wraparound at the end of Section 3.4.1. 💜
- Clarified "complete FDT" in Section 3.4.2. ⭐
- Added semantics for the case where two TOIs refer to the same Content-Location. This now lines up with how 3GPP and Digital Video Broadcasting (DVB) standards interpret it, which is so clean 👑
- In Section 3.4.2, the XML Schema of the FDT Instance was modified based on advice from various sources. For example, extension by element was missing but is now supported. The namespace definition was also changed to URN format. 🦋
- Clarified FDT-schema extensibility at the end of Section 3.4.2. 🫶
- Added the CENC value allocation at the end of Section 3.4.3. 🌸
- Section 5 was modified so that EXT_FTI and the FEC issues are replaced by a reference to the ALC specification [RFC5775]. 💅
- Added a clarifying paragraph on the use of the Codepoint field at the end of Section 5. ✨
- Reworked Section 8 (IANA Considerations). It now contains six IANA registration requests:
- Registration of the FDT Instance XML Namespace.
- Registration of the FDT Instance XML Schema.
- Registration of the application/fdt+xml Media Type.
- Registration of the Content Encoding Algorithms.
- Registration of two LCT Header Extension Types and corresponding values in the LCT Header Extension Types Registry (192 for
EXT_FDTand 193 forEXT_CENC).
- Added Section 10 (Contributors). Iconic 🎀
- Revised the lists of both Normative and Informative references. 📚
- Added a clarification that the receiver should ignore reserved bits of Header Extension type 193 upon reception. 🔥
- Elaborated on what kinds of networks cannot support FLUTE congestion control (Section 1.1.4). 🌊
- In Section 3.2, changed "several" (meaning 3-n vs. "couple" = 2) to "multiple" (meaning 2-n). Precision is everything 💅
- Moved the requirement in Section 3.3 (to send FDT more reliably than files) into a bulleted RECOMMENDED requirement, which makes checking it off easier for testers. ✅
- In Section 3.3, sharpened the definition so future FDT file instances can "augment" (meaning enhance) rather than "complement" (sometimes meaning negate, which is not allowed) the file parameters. 💖
- Elaborated in Sections 3.3 and 4 that FEC Encoding ID = 0 is Compact No-Code FEC, so readers don't have to dig through other RFCs to understand these FLUTE protocol constants. 🧠
- Required in Section 3.3 that FLUTE receivers SHALL NOT attempt to decode FDTs if they do not understand the FEC Encoding ID. Hard boundary, no cap 🚫
- Removed the restriction in Section 3.3, bullet #4, that TOI = 0 for the FDT, to be consistent with Appendix A step 6 and elsewhere. An FDT is signaled by an FDT Instance ID, NOT only by TOI = 0. Iykyk 🙈
- Standardized on the term "expiration time" and avoided the redundant, possibly confusing term "expiry time". 🌈
- To interwork with experimental FLUTE, stipulated in Section 3.1 that only one instantiation of all three protocols (FLUTE, ALC, and LCT) can be associated with a session (source IP Address, TSI). Section 6 also mentions that one may (optionally) derive the FLUTE version from the file delivery session description. 🦋
- Used a software writing tool to lower the reading grade level and simplify Section 3.1. Making the spec readable for everybody is the goal 🧚
12. References 📚
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", RFC 5775,
April 2010.
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC)
Schemes", RFC 5445, March 2009.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[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.
[XML-Schema-Part-1]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition",
W3C Recommendation, October 2004,
<http://www.w3.org/TR/xmlschema-1/>.
[XML-Schema-Part-2]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C Recommendation, October 2004,
<http://www.w3.org/TR/xmlschema-2/>.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004.
Note: The RFC 3738 reference is to a target document of a
lower maturity level. Some caution should be used, since
it may be less stable than the present document.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.12.2. Informative References ✨
Okay bestie, now we get to the bonus reading list 📚🎀 These are the informative references, so they're not required to implement the spec, but they're where a lot of the background lives.
- [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004.
- [RFC2357] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
- [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
- [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
- [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
- [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
- [IANAheaderfields] IANA, "Message Header Fields",
<http://www.iana.org/protocols>. - [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
- [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
- [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
- [PAPER.SSM] Holbrook, H., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
- [RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002.
- [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
- [RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
- [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
- [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.
- [RFC6584] Roca, V., "Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6584, April 2012.
- [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
- [MBMSsecurity] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS) (Release 10)", December 2010,
<http://www.3gpp.org/ftp/Specs/archive/33_series/33.246/>.
Appendix A. Receiver Operation (Informative) 🧚
Here's a little walkthrough of how a receiver of a file delivery session might behave 💅 It's not a strict state-by-state spec, just a rough sequence of what the receiver is envisioned to do, so treat it like a vibe check and not a rulebook 🫶
- The receiver grabs the description of the file delivery session, which is identified by the (source IP address, Transport Session Identifier) pair 🔍 It also gets the destination IP addresses and their respective ports for that session.
- The receiver joins the channels so it can catch the packets for the file delivery session 🦋 It can schedule this join using the timing info in a possible description of the session.
- The receiver receives ALC/LCT packets for the session and checks that they match the declared Transport Session Identifier. If they don't, they get silently discarded 💀
- While receiving, the receiver sorts packets by their
TOIand stores the useful info in the right spot so the matching file can be rebuilt. Multiple files can be reconstructed concurrently, so it's giving multitasking queen 👑 - The receiver recovers an object once it has an appropriate set of packets containing Encoding Symbols for the transmission object. What counts as "appropriate" depends on the FEC Encoding ID, the FEC Instance ID, and other info in the FEC Object Transmission Information 🌈
- Objects with
TOI = 0are reserved for FDT Instances, and all FDT Instances get signaled by including anEXT_FDTHeader Extension in the LCT header 🎀 TheEXT_FDTheader carries an FDT Instance ID (aka an FDT version number). If the object has an FDT Instance ID 'N', the receiver parses the payload of instance 'N' of the FDT and updates its FDT database accordingly 📝 - If the recovered object is a file and not an FDT Instance, the receiver looks in its FDT database for the properties described there and assigns them to the file 🍓 It also checks that the received content length matches the description in the database. Optionally, if an MD5 checksum has been used, the receiver checks that the calculated MD5 matches the description in the FDT database.
- What the receiver does with imperfectly received files (missing data, mismatching content integrity digest, etc.) is outside the scope of this specification 🙈 When a file is recovered before its associated file description entry is available, one possible behavior is to wait until an FDT Instance arrives that includes the missing properties.
- If the file delivery session end time hasn't been reached, go back to step 3. Otherwise, you're done ✨
Appendix B. Example of FDT Instance (Informative) 🌸
Here's a sample FDT Instance so you can see what the XML actually looks like in the wild 💖
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:fdt
ietf-flute-fdt.xsd"
Expires="2890842807">
<File
Content-Location="http://www.example.com/menu/tracklist.html"
TOI="1"
Content-Type="text/html"/>
<File
Content-Location="http://www.example.com/tracks/track1.mp3"
TOI="2"
Content-Length="6100"
Content-Type="audio/mp3"
Content-Encoding="gzip"
Content-MD5="+VP5IrWploFkZWc11iLDdA=="
Some-Private-Extension-Tag="abc123"/>
</FDT-Instance>Authors' Addresses 💜
Toni Paila, Nokia:
Toni Paila
Nokia
Itamerenkatu 11-13
Helsinki 00180
Finland
EMail: toni.paila@gmail.comRod Walsh, Nokia/Tampere University of Technology:
Rod Walsh
Nokia/Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FI-33101
Finland
EMail: roderick.walsh@tut.fiMichael Luby, Qualcomm Technologies, Inc.:
Michael Luby
Qualcomm Technologies, Inc.
2030 Addison Street, Suite 420
Berkeley, CA 94704
USA
EMail: luby@qti.qualcomm.comVincent Roca, INRIA:
Vincent Roca
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
EMail: vincent.roca@inria.frRami Lehtonen, TeliaSonera:
Rami Lehtonen
TeliaSonera
Hatanpaankatu 1
Tampere FIN-33100
Finland
EMail: rami.lehtonen@teliasonera.comAnd that's a wrap on RFC 6726, bestie! 🌈🎀 Thanks for reading all the way to the end 🫶💅
📦 where this page comes from
- ietf: rfc6726 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms