2. FEC Object Transmission Information that is available in the FDT.
5.1. Use of EXT_FTI for delivery of FEC Object Transmission Information
As specified in [2], the EXT_FTI header extension is intended to
carry the FEC Object Transmission Information for an object in-band.
It is left up to individual implementations to decide how frequently
and in which ALC packets the EXT_FTI header extension is included.
In environments with higher packet loss rate, the EXT_FTI might need
to be included more frequently in ALC packets than in environments
with low error probability. The EXT_FTI MUST be included in at least
one sent ALC packet for each FDT Instance.
The ALC specification does not define the format or the processing of
the EXT_FTI header extension. The following sections specify EXT_FTI
when used in FLUTE.
In FLUTE, the FEC Encoding ID (8 bits) is carried in the Codepoint
field of the ALC/LCT header.
5.1.1. General EXT_FTI format
The general EXT_FTI format specifies the structure and those
attributes of FEC Object Transmission Information that are applicable
to any FEC Encoding ID.
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 = 64 | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Instance ID | FEC Enc. ID Specific Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Type (HET), 8 bits:
64 as defined in [2].
Header Extension Length (HEL), 8 bits:
The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This length includes the FEC Encoding ID
specific format part.
Transfer Length, 48 bits:
The length of the transport object that carries the file in bytes.
(This is the same as the file length if the file is not content
encoded.)
FEC Instance ID, optional, 16 bits:
This field is used for FEC Instance ID. It is only present if the
value of FEC Encoding ID is in the range of 128-255. When the value
of FEC Encoding ID is in the range of 0-127, this field is set to 0.
FEC Encoding ID Specific Format:
Different FEC encoding schemes will need different sets of encoding
parameters. Thus, the structure and length of this field depends on
FEC Encoding ID. The next sections specify structure of this field
for FEC Encoding ID numbers 0, 128, 129, and 130.
5.1.2. FEC Encoding ID specific formats for EXT_FTI
5.1.2.1. FEC Encoding IDs 0, 128, and 130
FEC Encoding ID 0 is ’Compact No-Code FEC’ (Fully-Specified) [7].
FEC Encoding ID 128 is ’Small Block, Large Block and Expandable FEC’
(Under-Specified) [4]. FEC Encoding ID 130 is ’Compact FEC’ (Under-
Specified) [7]. For these FEC Encoding IDs, the FEC Encoding ID
specific format of EXT_FTI is defined as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
General EXT_FTI format | Encoding Symbol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoding Symbol Length, 16 bits:
Length of Encoding Symbol in bytes.
All Encoding Symbols of a transport object MUST be equal to this
length, with the optional exception of the last source symbol of the
last source block (so that redundant padding is not mandatory in this
last symbol). This last source symbol MUST be logically padded out
with zeroes when another Encoding Symbol is computed based on this
source symbol to ensure the same interpretation of this Encoding
Symbol value by the sender and receiver. However, this padding does
not actually need to be sent with the data of the last source symbol.
Maximum Source Block Length, 32 bits:
The maximum number of source symbols per source block.
This EXT_FTI specification requires that an algorithm is known to
both sender and receivers for determining the size of all source
blocks of the transport object that carries the file identified by
the TOI (or within the FDT Instance identified by the TOI and the FDT
Instance ID). The algorithm SHOULD be the same for all files using
the same FEC Encoding ID within a session.
Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this
use.
For the FEC Encoding IDs 0, 128 and 130, this algorithm is the only
well known way the receiver can determine the length of each source
block. Thus, the algorithm does two things: (a) it tells the
receiver the length of each particular source block as it is
receiving packets for that source block - this is essential to all of
these FEC schemes; and, (b) it provides the source block structure
immediately to the receiver so that the receiver can determine where
to save recovered source blocks at the beginning of the reception of
data packets for the file - this is an optimization which is
essential for some implementations.
5.1.2.2. FEC Encoding ID 129
Small Block Systematic FEC (Under-Specified). The FEC Encoding ID
specific format of EXT_FTI is defined as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
General EXT_FTI format | Encoding Symbol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Source Block Length | Max. Num. of Encoding Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoding Symbol Length, 16 bits:
Length of Encoding Symbol in bytes.
All Encoding Symbols of a transport object MUST be equal to this
length, with the optional exception of the last source symbol of the
last source block (so that redundant padding is not mandatory in this
last symbol). This last source symbol MUST be logically padded out
with zeroes when another Encoding Symbol is computed based on this
source symbol to ensure the same interpretation of this Encoding
Symbol value by the sender and receiver. However, this padding need
not be actually sent with the data of the last source symbol.
Maximum Source Block Length, 16 bits:
The maximum number of source symbols per source block.
Maximum Number of Encoding Symbols, 16 bits:
Maximum number of Encoding Symbols that can be generated for a source
block.
This EXT_FTI specification requires that an algorithm is known to
both sender and receivers for determining the size of all source
blocks of the transport object that carries the file identified by
the TOI (or within the FDT Instance identified by the TOI and the FDT
Instance ID). The algorithm SHOULD be the same for all files using
the same FEC Encoding ID within a session.
Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this
use. For FEC Encoding ID 129 the FEC Payload ID in each data packet
already contains the source block length for the source block
corresponding to the Encoding Symbol carried in the data packet.
Thus, the algorithm for computing source blocks for FEC Encoding ID
129 could be to just use the source block lengths carried in data
packets within the FEC Payload ID. However, the algorithm described
in Section 5.1.2.3 is useful for the receiver to compute the source
block structure at the beginning of the reception of data packets for
the file. If the algorithm described in Section 5.1.2.3 is used then
it MUST be the case that the source block lengths that appear in data
packets agree with the source block lengths calculated by the
algorithm.
5.1.2.3. Algorithm for Computing Source Block Structure
This algorithm computes a source block structure so that all source
blocks are as close to being equal length as possible. A first
number of source blocks are of the same larger length, and the
remaining second number of source blocks are sent of the same smaller
length. The total number of source blocks (N), the first number of
source blocks (I), the second number of source blocks (N-I), the
larger length (A_large) and the smaller length (A_small) are
calculated thus,
Input:
B -- Maximum Source Block Length, i.e., the maximum number of
source symbols per source block
L -- Transfer Length in bytes
E -- Encoding Symbol Length in bytes
Output:
N -- The number of source blocks into which the transport
object is partitioned.
The number and lengths of source symbols in each of the N
source blocks.
Algorithm:
(a) The number of source symbols in the transport object is
computed as T = L/E rounded up to the nearest integer.
(b) The transport object is partitioned into N source blocks,
where N = T/B rounded up to the nearest integer
(c) The average length of a source block, A = T/N
(this may be non-integer)
(d) A_large = A rounded up to the nearest integer
(it will always be the case that the value of A_large is at
most B)
(e) A_small = A rounded down to the nearest integer
(if A is an integer A_small = A_large,
and otherwise A_small = A_large - 1)
(f) The fractional part of A, A_fraction = A - A_small
(g) I = A_fraction * N
(I is an integer between 0 and N-1)
(h) Each of the first I source blocks consists of A_large source
symbols, each source symbol is E bytes in length. Each of the
remaining N-I source blocks consist of A_small source symbols,
each source symbol is E bytes in length except that the last
source symbol of the last source block is L-(((L-1)/E) rounded
down to the nearest integer)*E bytes in length.
Note, this algorithm does not imply implementation by floating point
arithmetic and integer arithmetic may be used to avoid potential
floating point rounding errors.
5.2. Use of FDT for delivery of FEC Object Transmission Information
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. For future FEC Encoding IDs, if
the attributes listed below do not fulfill the needs of describing
the FEC Object Transmission Information then additional new
attributes MAY be used.
* "Transfer-Length" is semantically equivalent with the field
"Transfer Length" of EXT_FTI.
* "FEC-OTI-FEC-Encoding-ID" is semantically equivalent with the
field "FEC Encoding ID" as carried in the Codepoint field of the
ALC/LCT header.
* "FEC-OTI-FEC-Instance-ID" is semantically equivalent with the
field "FEC Instance ID" of EXT_FTI.
* "FEC-OTI-Maximum-Source-Block-Length" is semantically equivalent
with the field "Maximum Source Block Length" of EXT_FTI for FEC
Encoding IDs 0, 128 and 130, and semantically equivalent with the
field "Maximum Source Block Length" of EXT_FTI for FEC Encoding ID
129.
* "FEC-OTI-Encoding-Symbol-Length" is semantically equivalent with
the field "Encoding Symbol Length" of EXT_FTI for FEC Encoding IDs
0, 128, 129 and 130.
* "FEC-OTI-Max-Number-of-Encoding-Symbols" is semantically
equivalent with the field "Maximum Number of Encoding Symbols" of
EXT_FTI for FEC Encoding ID 129.
6. Describing file delivery sessions
To start receiving a file delivery session, the receiver needs to
know transport parameters associated with the session.
Interpreting these parameters and starting the reception therefore
represents the entry point from which thereafter the receiver
operation falls into the scope of this specification. According
to [2], the transport parameters of an ALC/LCT session that 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. The need to
demultiplex objects upon reception is implicit in any use of
FLUTE, and this fulfills the ALC requirement of an indication of
whether or not a session carries packets for more than one object
(all FLUTE sessions carry packets for more than one object).
Optionally, the following parameters MAY be associated with the
session (Note, the list is not exhaustive):
* 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 FDT;
* Content Encoding format if optional content encoding of 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.
It is envisioned that these parameters would be described according
to some session description syntax (such as SDP [12] or XML based)
and held in a file which would be acquired by the receiver before the
FLUTE session begins by means of some transport protocol (such as
Session Announcement Protocol [11], email, HTTP [6], SIP [22], manual
pre-configuration, etc.) However, the way in which the receiver
discovers the above-mentioned parameters is out of scope of this
document, as it is for LCT and ALC. In particular, this
specification does not mandate or exclude any mechanism.
7. Security Considerations
The security considerations that apply to, and are described in, ALC
[2], LCT [3] and FEC [4] also apply to FLUTE. In addition, any
security considerations that apply to any congestion control building
block used in conjunction with FLUTE also apply to FLUTE.
Because of the use of FEC, FLUTE is especially vulnerable to denial-
of-service attacks by attackers that try to send forged packets to
the session which would prevent successful reconstruction or cause
inaccurate reconstruction of large portions of the FDT or file by
receivers. Like ALC, FLUTE is particularly affected by such an
attack because many receivers may receive the same forged packet. A
malicious attacker may spoof file packets and cause incorrect
recovery of a file.
Even more damaging, a malicious forger may spoof FDT Instance
packets, for example sending packets with erroneous FDT-Instance
fields. Many attacks can follow this approach. For instance a
malicious attacker may alter the Content-Location field of TOI ’n’,
to make it point to a system file or a user configuration file.
Then, TOI ’n’ can carry a Trojan Horse or some other type of virus.
It is thus STRONGLY RECOMMENDED that the FLUTE delivery service at
the receiver does not have write access to the system files or
directories, or any other critical areas. As described for MIME
[20][21], special consideration should be paid to the security
implications of any MIME types that can cause the remote execution of
any actions in the recipient’s environment. Note, RFC 1521 [21]
describes important security issues for this environment, even though
its protocol is obsoleted by RFC 2048 [20].
Another example is generating a bad Content-MD5 sum, leading
receivers to reject the associated file that will be declared
corrupted. The Content-Encoding can also be modified, which also
prevents the receivers to correctly handle the associated file.
These examples show that the FDT information is critical to the FLUTE
delivery service.
At the application level, it is RECOMMENDED that an integrity check
on the entire received object be done once the object is
reconstructed to ensure it is the same as the sent object, especially
for objects that are FDT Instances. Moreover, in order to obtain
strong cryptographic integrity protection a digital signature
verifiable by the receiver SHOULD be used to provide this application
level integrity check. However, if even one corrupted or forged
packet is used to reconstruct the object, it is likely that the
received object will be reconstructed incorrectly. This will
appropriately cause the integrity check to fail and, in this case,
the inaccurately reconstructed object SHOULD be discarded. Thus, the
acceptance of a single forged packet can be an effective denial of
service attack for distributing objects, but an object integrity
check at least prevents inadvertent use of inaccurately reconstructed
objects. The specification of an application level integrity check
of the received object is outside the scope of this document.
At the packet level, it is RECOMMENDED that a packet level
authentication be used to ensure that each received packet is an
authentic and uncorrupted packet containing FEC data for the object
arriving from the specified sender. Packet level authentication has
the advantage that corrupt or forged packets can be discarded
individually and the received authenticated packets can be used to
accurately reconstruct the object. Thus, the effect of a denial of
service attack that injects forged packets is proportional only to
the number of forged packets, and not to the object size. Although
there is currently no IETF standard that specifies how to do
multicast packet level authentication, TESLA [14] is a known
multicast packet authentication scheme that would work.
In addition to providing protection against reconstruction of
inaccurate objects, packet level authentication can also provide 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,
thereby potentially adversely affecting network elements and
receivers downstream of the attack, and much less significantly the
rest of the network and other receivers. Thus, it is also
RECOMMENDED that packet level authentication be used to protect
against such attacks. TESLA [14] can also be used to some extent to
limit the damage caused by such attacks. However, with TESLA a
receiver can only determine if a packet is authentic several seconds
after it is received, and thus an attack against the congestion
control protocol can be effective for several seconds before the
receiver can react to slow down the session reception rate.
Reverse Path Forwarding checks SHOULD be enabled in all network
routers and switches along the path from the sender to receivers to
limit the possibility of a bad agent injecting forged packets into
the multicast tree data path.
A receiver with an incorrect or corrupted implementation of the
multiple rate congestion control building block may affect health of
the network in the path between the sender and the receiver, and may
also affect the reception rates of other receivers joined to the
session. It is therefore 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.
Another vulnerability of FLUTE is the potential of receivers
obtaining an incorrect Session Description for the session. The
consequences of this could be that legitimate receivers with the
wrong Session Description are unable to correctly receive the session
content, or that receivers inadvertently try to receive at a much
higher rate than they are capable of, thereby disrupting traffic in
portions of the network. To avoid these problems, it is RECOMMENDED
that measures be taken to prevent receivers from accepting incorrect
Session Descriptions, e.g., by using source authentication to ensure
that receivers only accept legitimate Session Descriptions from
authorized senders. How this is done is outside the scope of this
document.
8. IANA Considerations
No information in this specification is directly subject to IANA
registration. However, building blocks components used by ALC may
introduce additional IANA considerations. In particular, the FEC
building block used by FLUTE does require IANA registration of the
FEC codec used.
9. Acknowledgements
The following persons have contributed to this specification: Brian
Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
Jani Peltotalo, Sami Peltotalo, Topi Pohjolainen, and Lorenzo
Vicisano. The authors would like to thank all the contributors for
their valuable work in reviewing and providing feedback regarding
this specification.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002.
[3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,
and J. Crowcroft, "Layered Coding Transport (LCT) Building
Block", RFC 3451, December 2002.
[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
and J. Crowcroft, "Forward Error Correction (FEC) Building
Block", RFC 3452, December 2002.
[5] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[6] 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.
[7] Luby, M. and L. Vicisano, "Compact Forward Error Correction
(FEC) Schemes", RFC 3695, February 2004.
[8] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C Recommendation, May 2001.
[9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
Recommendation, May 2001.
Informative References
[10] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[12] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[13] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
1112, August 1989.
[14] Perrig, A., Canetti, R., Song, D., and J. Tygar, "Efficient and
Secure Source Authentication for Multicast, Network and