draft-ietf-tsvwg-rlc-fec-scheme-06.txt   draft-ietf-tsvwg-rlc-fec-scheme-07.txt 
TSVWG V. Roca TSVWG V. Roca
Internet-Draft B. Teibi Internet-Draft B. Teibi
Intended status: Standards Track INRIA Intended status: Standards Track INRIA
Expires: January 26, 2019 July 25, 2018 Expires: March 11, 2019 September 7, 2018
Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC)
Schemes for FECFRAME Schemes for FECFRAME
draft-ietf-tsvwg-rlc-fec-scheme-06 draft-ietf-tsvwg-rlc-fec-scheme-07
Abstract Abstract
This document describes two fully-specified Forward Erasure This document describes two fully-specified Forward Erasure
Correction (FEC) Schemes for Sliding Window Random Linear Codes Correction (FEC) Schemes for Sliding Window Random Linear Codes
(RLC), one for RLC over GF(2) (binary case), a second one for RLC (RLC), one for RLC over the Galois Field (A.K.A. Finite Field)
over GF(2^^8), with the possibility of controlling the code density. GF(2), a second one for RLC over the Galois Field GF(2^^8), each time
They can protect arbitrary media streams along the lines defined by with the possibility of controlling the code density. They can
FECFRAME extended to sliding window FEC codes. These sliding window protect arbitrary media streams along the lines defined by FECFRAME
FEC codes rely on an encoding window that slides over the source extended to sliding window FEC codes, as defined in [fecframe-ext].
symbols, generating new repair symbols whenever needed. Compared to These sliding window FEC codes rely on an encoding window that slides
block FEC codes, these sliding window FEC codes offer key advantages over the source symbols, generating new repair symbols whenever
with real-time flows in terms of reduced FEC-related latency while needed. Compared to block FEC codes, these sliding window FEC codes
often providing improved packet erasure recovery capabilities. offer key advantages with real-time flows in terms of reduced FEC-
related latency while often providing improved packet erasure
recovery capabilities.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 26, 2019. This Internet-Draft will expire on March 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 31
1.3. Small Transmission Overheads with the Sliding Window RLC 1.3. Small Transmission Overheads with the Sliding Window RLC
FEC Scheme . . . . . . . . . . . . . . . . . . . . . . . 5 FEC Scheme . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Document Organization . . . . . . . . . . . . . . . . . . 6 1.4. Document Organization . . . . . . . . . . . . . . . . . . 6
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Possible Parameter Derivations . . . . . . . . . . . . . 7 3.1. Possible Parameter Derivations . . . . . . . . . . . . . 7
3.1.1. Case of a CBR Real-Time Flow . . . . . . . . . . . . 8 3.1.1. Case of a CBR Real-Time Flow . . . . . . . . . . . . 8
3.1.2. Other Types of Real-Time Flow . . . . . . . . . . . . 10 3.1.2. Other Types of Real-Time Flow . . . . . . . . . . . . 10
3.1.3. Case of a Non Real-Time Flow . . . . . . . . . . . . 11 3.1.3. Case of a Non Real-Time Flow . . . . . . . . . . . . 11
3.2. ADU, ADUI and Source Symbols Mappings . . . . . . . . . . 11 3.2. ADU, ADUI and Source Symbols Mappings . . . . . . . . . . 11
3.3. Encoding Window Management . . . . . . . . . . . . . . . 12 3.3. Encoding Window Management . . . . . . . . . . . . . . . 13
3.4. Pseudo-Random Number Generator (PRNG) . . . . . . . . . . 13 3.4. Pseudo-Random Number Generator (PRNG) . . . . . . . . . . 13
3.5. Coding Coefficients Generation Function . . . . . . . . . 14 3.5. Coding Coefficients Generation Function . . . . . . . . . 14
3.6. Finite Fields Operations . . . . . . . . . . . . . . . . 17 3.6. Finite Fields Operations . . . . . . . . . . . . . . . . 17
3.6.1. Finite Field Definitions . . . . . . . . . . . . . . 17 3.6.1. Finite Field Definitions . . . . . . . . . . . . . . 17
3.6.2. Linear Combination of Source Symbols Computation . . 17 3.6.2. Linear Combination of Source Symbols Computation . . 17
4. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary ADU 4. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary ADU
Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 18 4.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 18
4.1.1. FEC Framework Configuration Information . . . . . . . 18 4.1.1. FEC Framework Configuration Information . . . . . . . 18
4.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 19 4.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 19
skipping to change at page 3, line 9 skipping to change at page 3, line 11
5.1.4. Additional Procedures . . . . . . . . . . . . . . . . 22 5.1.4. Additional Procedures . . . . . . . . . . . . . . . . 22
6. FEC Code Specification . . . . . . . . . . . . . . . . . . . 22 6. FEC Code Specification . . . . . . . . . . . . . . . . . . . 22
6.1. Encoding Side . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Encoding Side . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Decoding Side . . . . . . . . . . . . . . . . . . . . . . 23 6.2. Decoding Side . . . . . . . . . . . . . . . . . . . . . . 23
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 24 8.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 24
8.1.1. Access to Confidential Content . . . . . . . . . . . 24 8.1.1. Access to Confidential Content . . . . . . . . . . . 24
8.1.2. Content Corruption . . . . . . . . . . . . . . . . . 24 8.1.2. Content Corruption . . . . . . . . . . . . . . . . . 24
8.2. Attacks Against the FEC Parameters . . . . . . . . . . . 25 8.2. Attacks Against the FEC Parameters . . . . . . . . . . . 25
8.3. When Several Source Flows are to be Protected Together . 25 8.3. When Several Source Flows are to be Protected Together . 26
8.4. Baseline Secure FEC Framework Operation . . . . . . . . . 25 8.4. Baseline Secure FEC Framework Operation . . . . . . . . . 26
9. Operations and Management Considerations . . . . . . . . . . 25 9. Operations and Management Considerations . . . . . . . . . . 26
9.1. Operational Recommendations: Finite Field GF(2) Versus 9.1. Operational Recommendations: Finite Field GF(2) Versus
GF(2^^8) . . . . . . . . . . . . . . . . . . . . . . . . 26 GF(2^^8) . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Operational Recommendations: Coding Coefficients Density 9.2. Operational Recommendations: Coding Coefficients Density
Threshold . . . . . . . . . . . . . . . . . . . . . . . . 26 Threshold . . . . . . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. TinyMT32 Pseudo-Random Number Generator . . . . . . 29 Appendix A. TinyMT32 Pseudo-Random Number Generator . . . . . . 31
Appendix B. Decoding Beyond Maximum Latency Optimization . . . . 32 Appendix B. Decoding Beyond Maximum Latency Optimization . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
Application-Level Forward Erasure Correction (AL-FEC) codes, or Application-Level Forward Erasure Correction (AL-FEC) codes, or
simply FEC codes, are a key element of communication systems. They simply FEC codes, are a key element of communication systems. They
are used to recover from packet losses (or erasures) during content are used to recover from packet losses (or erasures) during content
delivery sessions to a large number of receivers (multicast/broadcast delivery sessions to a potentially large number of receivers
transmissions). This is the case with the FLUTE/ALC protocol (multicast/broadcast transmissions). This is the case with the
[RFC6726] when used for reliable file transfers over lossy networks, FLUTE/ALC protocol [RFC6726] when used for reliable file transfers
and the FECFRAME protocol when used for reliable continuous media over lossy networks, and the FECFRAME protocol when used for reliable
transfers over lossy networks. continuous media transfers over lossy networks.
The present document only focusses on the FECFRAME protocol, used in The present document only focuses on the FECFRAME protocol, used in
multicast/broadcast delivery mode, with contents that feature multicast/broadcast delivery mode, in particular for contents that
stringent real-time constraints: each source packet has a maximum feature stringent real-time constraints: each source packet has a
validity period after which it will not be considered by the maximum validity period after which it will not be considered by the
destination application. destination application.
1.1. Limits of Block Codes with Real-Time Flows 1.1. Limits of Block Codes with Real-Time Flows
With FECFRAME, there is a single FEC encoding point (either a end- With FECFRAME, there is a single FEC encoding point (either a end-
host/server (source) or a middlebox) and a single FEC decoding point host/server (source) or a middlebox) and a single FEC decoding point
(either a end-host (receiver) or middlebox). In this context, (either a end-host (receiver) or middlebox). In this context,
currently standardized AL-FEC codes for FECFRAME like Reed-Solomon currently standardized AL-FEC codes for FECFRAME like Reed-Solomon
[RFC6865], LDPC-Staircase [RFC6816], or Raptor/RaptorQ, are all [RFC6865], LDPC-Staircase [RFC6816], or Raptor/RaptorQ, are all
linear block codes: they require the data flow to be segmented into linear block codes: they require the data flow to be segmented into
skipping to change at page 4, line 25 skipping to change at page 4, line 27
FEC-related latency of all receivers, even those experiencing a good FEC-related latency of all receivers, even those experiencing a good
communication quality, since no FEC encoding can happen until all the communication quality, since no FEC encoding can happen until all the
source data of the block is available at the sender, which directly source data of the block is available at the sender, which directly
depends on the block size. depends on the block size.
1.2. Lower Latency and Better Protection of Real-Time Flows with the 1.2. Lower Latency and Better Protection of Real-Time Flows with the
Sliding Window RLC Codes Sliding Window RLC Codes
This document introduces two fully-specified FEC Schemes that follow This document introduces two fully-specified FEC Schemes that follow
a totally different approach: the Sliding Window Random Linear Codes a totally different approach: the Sliding Window Random Linear Codes
(RLC) over either Finite Field GF(2) or GF(2^^8). These FEC Schemes (RLC) over either Galois Fields (A.K.A. Finite Fields) GF(2) (the
are used to protect arbitrary media streams along the lines defined "binary case") or GF(2^^8), each time with the possibility of
by FECFRAME extended to sliding window FEC codes [fecframe-ext]. controlling the code density. These FEC Schemes are used to protect
These FEC Schemes, and more generally Sliding Window FEC codes, are arbitrary media streams along the lines defined by FECFRAME extended
recommended for instance with media that feature real-time to sliding window FEC codes [fecframe-ext]. These FEC Schemes, and
constraints sent within a multicast/broadcast session [Roca17]. more generally Sliding Window FEC codes, are recommended for instance
with media that feature real-time constraints sent within a
multicast/broadcast session [Roca17].
The RLC codes belong to the broad class of sliding window AL-FEC The RLC codes belong to the broad class of sliding window AL-FEC
codes (A.K.A. convolutional codes). The encoding process is based on codes (A.K.A. convolutional codes) [RFC8406]. The encoding process
an encoding window that slides over the set of source packets (in is based on an encoding window that slides over the set of source
fact source symbols as we will see in Section 3.2), and which is packets (in fact source symbols as we will see in Section 3.2), this
either of fixed or variable size (elastic window). Repair packets window being either of fixed size or variable size (A.K.A. an elastic
(symbols) are generated on-the-fly, computing a random linear window). Repair symbols are generated on-the-fly, by computing a
combination of the source symbols present in the current encoding random linear combination of the source symbols present in the
window, and passed to the transport layer. current encoding window, and passed to the transport layer.
At the receiver, a linear system is managed from the set of received At the receiver, a linear system is managed from the set of received
source and repair packets. New variables (representing source source and repair packets. New variables (representing source
symbols) and equations (representing the linear combination of each symbols) and equations (representing the linear combination carried
repair symbol received) are added upon receiving new packets. by each repair symbol received) are added upon receiving new packets.
Variables are removed when they are too old with respect to their Variables and the equations they are involved in are removed when
validity period (real-time constraints), as well as the associated they are too old with respect to their validity period (real-time
equations they are involved in (Appendix B introduces an optimization constraints) . Lost source symbols are then recovered thanks to this
that extends the time a variable is considered in the system). Lost linear system whenever its rank permits to solve it (at least
source symbols are then recovered thanks to this linear system partially).
whenever its rank permits it.
With RLC codes (more generally with sliding window codes), the The protection of any multicast/broadcast session needs to be
protection of a multicast/broadcast session also needs to be
dimensioned by considering the worst communication conditions one dimensioned by considering the worst communication conditions one
wants to support. However the receivers experiencing a good to wants to support. This is also true with RLC (more generally any
sliding window) code. However the receivers experiencing a good to
medium communication quality will observe a reduced FEC-related medium communication quality will observe a reduced FEC-related
latency compared to block codes [Roca17] since an isolated lost latency compared to block codes [Roca17] since an isolated lost
source packet is quickly recovered with the following repair packet. source packet is quickly recovered with the following repair packet.
On the opposite, with a block code, recovering an isolated lost On the opposite, with a block code, recovering an isolated lost
source packet always requires waiting for the first repair packet to source packet always requires waiting for the first repair packet to
arrive after the end of the block. Additionally, under certain arrive after the end of the block. Additionally, under certain
situations (e.g., with a limited FEC-related latency budget and with situations (e.g., with a limited FEC-related latency budget and with
constant bitrate transmissions after FECFRAME encoding), sliding constant bitrate transmissions after FECFRAME encoding), sliding
window codes can more efficiently achieve a target transmission window codes can more efficiently achieve a target transmission
quality (e.g., measured by the residual loss after FEC decoding) by quality (e.g., measured by the residual loss after FEC decoding) by
skipping to change at page 5, line 41 skipping to change at page 5, line 43
over GF(2^^m) (where m is 1 or 8, depending on the FEC Scheme) used over GF(2^^m) (where m is 1 or 8, depending on the FEC Scheme) used
in the linear combination are not individually listed in the repair in the linear combination are not individually listed in the repair
packet header. Instead, each FEC Repair Packet header contains: packet header. Instead, each FEC Repair Packet header contains:
o the Encoding Symbol Identifier (ESI) of the first source symbol in o the Encoding Symbol Identifier (ESI) of the first source symbol in
the encoding window as well as the number of symbols (since this the encoding window as well as the number of symbols (since this
number may vary with a variable size, elastic window). These two number may vary with a variable size, elastic window). These two
pieces of information enable each receiver to reconstruct the set pieces of information enable each receiver to reconstruct the set
of source symbols considered during encoding, the only constraint of source symbols considered during encoding, the only constraint
being that there cannot be any gap; being that there cannot be any gap;
o the seed used by a coding coefficients generation function o the seed and density threshold parameters used by a coding
(Section 3.5). This information enables each receiver to generate coefficients generation function (Section 3.5). These two pieces
the same set of coding coefficients over GF(2^^m) as the sender; of information enable each receiver to generate the same set of
coding coefficients over GF(2^^m) as the sender;
Therefore, no matter the number of source symbols present in the Therefore, no matter the number of source symbols present in the
encoding window, each FEC Repair Packet features a fixed 64-bit long encoding window, each FEC Repair Packet features a fixed 64-bit long
header, called Repair FEC Payload ID (Figure 7). Similarly, each FEC header, called Repair FEC Payload ID (Figure 7). Similarly, each FEC
Source Packet features a fixed 32-bit long trailer, called Explicit Source Packet features a fixed 32-bit long trailer, called Explicit
Source FEC Payload ID (Figure 5), that contains the ESI of the first Source FEC Payload ID (Figure 5), that contains the ESI of the first
source symbol (see the ADUI and source symbol mapping, Section 3.2). source symbol (Section 3.2).
1.4. Document Organization 1.4. Document Organization
This fully-specified FEC Scheme follows the structure required by This fully-specified FEC Scheme follows the structure required by
[RFC6363], section 5.6. "FEC Scheme Requirements", namely: [RFC6363], section 5.6. "FEC Scheme Requirements", namely:
3. Procedures: This section describes procedures specific to this 3. Procedures: This section describes procedures specific to this
FEC Scheme, namely: RLC parameters derivation, ADUI and source FEC Scheme, namely: RLC parameters derivation, ADUI and source
symbols mapping, pseudo-random number generator, and coding symbols mapping, pseudo-random number generator, and coding
coefficients generation function; coefficients generation function;
skipping to change at page 8, line 26 skipping to change at page 8, line 32
SHOULD fix the E parameter and communicate it as part of the FEC SHOULD fix the E parameter and communicate it as part of the FEC
Scheme-Specific Information (Section 4.1.1.2). Scheme-Specific Information (Section 4.1.1.2).
Code rate, cr: The code rate parameter determines the amount of Code rate, cr: The code rate parameter determines the amount of
redundancy added to the flow. More precisely the cr is the ratio redundancy added to the flow. More precisely the cr is the ratio
between the total number of source symbols and the total number of between the total number of source symbols and the total number of
source plus repair symbols and by definition: 0 < cr <= 1. This source plus repair symbols and by definition: 0 < cr <= 1. This
is an input parameter that enables a FECFRAME sender to derive is an input parameter that enables a FECFRAME sender to derive
other internal parameters, as explained below. However there is other internal parameters, as explained below. However there is
no need to communicate the cr parameter per see (it's not required no need to communicate the cr parameter per see (it's not required
to process a repair symbol at a receiver). This code rate to process a repair symbol at a receiver). This code rate
parameter can be fixed. However, in specific use-cases (e.g., parameter can be static. However, in specific use-cases (e.g.,
with unicast transmissions in presence of a feedback mechanism with unicast transmissions in presence of a feedback mechanism
that estimates the communication quality, out of scope of that estimates the communication quality, out of scope of
FECFRAME), the code rate may be adjusted dynamically. FECFRAME), the code rate may be adjusted dynamically.
The FEC Schemes can be used in various manners. They can be used to The FEC Schemes can be used in various manners. They can be used to
protect a source ADU flow having real-time constraints, or a non- protect a source ADU flow having real-time constraints, or a non-
realtime source ADU flow. The source ADU flow may be a Constant realtime source ADU flow. The source ADU flow may be a Constant
Bitrate (CBR) or Variable BitRate (VBR) flow. The features of the Bitrate (CBR) or Variable BitRate (VBR) flow. The flow's minimum/
flow (in particular its minimum/maximum bitrate) may be known or not. maximum bitrate might or might not be known. The FEC Schemes can
The FEC Schemes can also be used over the Internet or over a CBR also be used over the Internet or over a CBR communication path. It
communication path. It follows that the FEC Scheme parameters can be follows that the FEC Scheme parameters can be derived in different
derived in different ways, as described in the following sections. ways, as described in the following sections.
3.1.1. Case of a CBR Real-Time Flow 3.1.1. Case of a CBR Real-Time Flow
In the following, we consider a real-time flow with max_lat latency In the following, we consider a real-time flow with max_lat latency
budget. The encoding symbol size, E, is constant. The code rate, budget. The encoding symbol size, E, is constant. The code rate,
cr, is also constant, its value depending on the expected cr, is also constant, its value depending on the expected
communication loss model (this choice is out of scope of this communication loss model (this choice is out of scope of this
document). document).
In a first configuration, the source ADU flow bitrate at the input of In a first configuration, the source ADU flow bitrate at the input of
skipping to change at page 24, line 41 skipping to change at page 24, line 41
8.1. Attacks Against the Data Flow 8.1. Attacks Against the Data Flow
8.1.1. Access to Confidential Content 8.1.1. Access to Confidential Content
The Sliding Window RLC FEC Scheme specified in this document does not The Sliding Window RLC FEC Scheme specified in this document does not
change the recommendations of [RFC6363]. To summarize, if change the recommendations of [RFC6363]. To summarize, if
confidentiality is a concern, it is RECOMMENDED that one of the confidentiality is a concern, it is RECOMMENDED that one of the
solutions mentioned in [RFC6363] is used with special considerations solutions mentioned in [RFC6363] is used with special considerations
to the way this solution is applied (e.g., is encryption applied to the way this solution is applied (e.g., is encryption applied
before or after FEC protection, within the end-system or in a before or after FEC protection, within the end-system or in a
middlebox) to the operational constraints (e.g., performing FEC middlebox), to the operational constraints (e.g., performing FEC
decoding in a protected environment may be complicated or even decoding in a protected environment may be complicated or even
impossible) and to the threat model. impossible) and to the threat model.
8.1.2. Content Corruption 8.1.2. Content Corruption
The Sliding Window RLC FEC Scheme specified in this document does not The Sliding Window RLC FEC Scheme specified in this document does not
change the recommendations of [RFC6363]. To summarize, it is change the recommendations of [RFC6363]. To summarize, it is
RECOMMENDED that one of the solutions mentioned in [RFC6363] is used RECOMMENDED that one of the solutions mentioned in [RFC6363] is used
on both the FEC Source and Repair Packets. on both the FEC Source and Repair Packets.
8.2. Attacks Against the FEC Parameters 8.2. Attacks Against the FEC Parameters
The FEC Scheme specified in this document defines parameters that can The FEC Scheme specified in this document defines parameters that can
be the basis of attacks. More specifically, the following parameters be the basis of attacks. More specifically, the following parameters
of the FFCI may be modified by an attacker who targets receivers of the FFCI may be modified by an attacker who targets receivers
(Section 4.1.1.2): (Section 4.1.1.2):
o FEC Encoding ID: changing this parameter leads the receivers to o FEC Encoding ID: changing this parameter leads a receiver to
consider a different FEC Scheme, which enables an attacker to consider a different FEC Scheme. The consequences are severe, the
create a Denial of Service (DoS); format of the Explicit Source FEC Payload ID and Repair FEC
Payload ID of received packets will probably differ, leading to
various malfunctions. Even if the original and modified FEC
Schemes share the same format, FEC decoding will either fail or
lead to corrupted decoded symbols. This will happen if an
attacker turns value YYYY (i.e., RLC over GF(2)) to value XXXX
(RLC over GF(2^^8)), an additional consequence being a higher
processing overhead at the receiver. In any case, the attack
results in a form of Denial of Service (DoS);
o Encoding symbol length (E): setting this E parameter to a o Encoding symbol length (E): setting this E parameter to a
different value will confuse the receivers and create a DoS. More different value will confuse a receiver. If the size of a
precisely, the FEC Repair Packets received will probably no longer received FEC Repair Packet is no longer multiple of the modified E
be multiple of E, leading receivers to reject them; value, a receiver quickly detects a problem and SHOULD reject the
packet. If the new E value is a sub-multiple of the original E
value (e.g., half the original value), then receivers may not
detect the problem immediately. For instance a receiver may think
that a received FEC Repair Packet contains more repair symbols
(e.g., twice as many if E is reduced by half), leading to
malfunctions whose nature depends on implementation details. Here
also, the attack always results in a form of DoS;
It is therefore RECOMMENDED that security measures are taken to It is therefore RECOMMENDED that security measures be taken to
guarantee the FFCI integrity, as specified in [RFC6363]. How to guarantee the FFCI integrity, as specified in [RFC6363]. How to
achieve this depends on the way the FFCI is communicated from the achieve this depends on the way the FFCI is communicated from the
sender to the receiver, which is not specified in this document. sender to the receiver, which is not specified in this document.
Similarly, attacks are possible against the Explicit Source FEC Similarly, attacks are possible against the Explicit Source FEC
Payload ID and Repair FEC Payload ID: by modifying the Encoding Payload ID and Repair FEC Payload ID. More specifically, in case of
Symbol ID (ESI), or the repair key, DT, NSS or FSS_ESI. It is a FEC Source Packet, the following value can be modified by an
therefore RECOMMENDED that security measures are taken to guarantee attacker who targets receivers:
the FEC Source and Repair Packets as stated in [RFC6363].
o Encoding Symbol ID (ESI): changing the ESI leads a receiver to
consider a wrong ADU, resulting in severe consequences, including
corrupted content passed to the receiving application;
And in case of a FEC Repair Packet:
o Repair Key: changing this value leads a receiver to generate a
wrong coding coefficient sequence, and therefore any source symbol
decoded using the repair symbols contained in this packet will be
corrupted;
o DT: changing this value also leads a receiver to generate a wrong
coding coefficient sequence, and therefore any source symbol
decoded using the repair symbols contained in this packet will be
corrupted. In addition, if the DT value is significantly
increased, it will generate a higher processing overhead at a
receiver. In case of very large encoding windows, this may impact
the terminal performance;
o NSS: changing this value leads a receiver to consider a different
set of source symbols, and therefore any source symbol decoded
using the repair symbols contained in this packet will be
corrupted. In addition, if the NSS value is significantly
increased, it will generate a higher processing overhead at a
receiver, which may impact the terminal performance;
o FSS_ESI: changing this value also leads a receiver to consider a
different set of source symbols and therefore any source symbol
decoded using the repair symbols contained in this packet will be
corrupted.
It is therefore RECOMMENDED that security measures are taken to
guarantee the FEC Source and Repair Packets as stated in [RFC6363].
8.3. When Several Source Flows are to be Protected Together 8.3. When Several Source Flows are to be Protected Together
The Sliding Window RLC FEC Scheme specified in this document does not The Sliding Window RLC FEC Scheme specified in this document does not
change the recommendations of [RFC6363]. change the recommendations of [RFC6363].
8.4. Baseline Secure FEC Framework Operation 8.4. Baseline Secure FEC Framework Operation
The Sliding Window RLC FEC Scheme specified in this document does not The Sliding Window RLC FEC Scheme specified in this document does not
change the recommendations of [RFC6363] concerning the use of the change the recommendations of [RFC6363] concerning the use of the
skipping to change at page 27, line 14 skipping to change at page 28, line 14
o YYYY refers to the Sliding Window Random Linear Codes (RLC) over o YYYY refers to the Sliding Window Random Linear Codes (RLC) over
GF(2) FEC Scheme for Arbitrary Packet Flows, as defined in GF(2) FEC Scheme for Arbitrary Packet Flows, as defined in
Section 5 of this document. Section 5 of this document.
o XXXX refers to the Sliding Window Random Linear Codes (RLC) over o XXXX refers to the Sliding Window Random Linear Codes (RLC) over
GF(2^^8) FEC Scheme for Arbitrary Packet Flows, as defined in GF(2^^8) FEC Scheme for Arbitrary Packet Flows, as defined in
Section 4 of this document. Section 4 of this document.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Gorry Fairhurst, Jonathan Detchart, The authors would like to thank Spencer Dawkins, Gorry Fairhurst,
Emmanuel Lochin, and Marie-Jose Montpetit for their valuable Jonathan Detchart, Emmanuel Lochin, and Marie-Jose Montpetit for
feedbacks on this document. their valuable feedbacks on this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[fecframe-ext] [fecframe-ext]
Roca, V. and A. Begen, "Forward Error Correction (FEC) Roca, V. and A. Begen, "Forward Error Correction (FEC)
Framework Extension to Sliding Window Codes", Transport Framework Extension to Sliding Window Codes", Transport
Area Working Group (TSVWG) draft-ietf-tsvwg-fecframe-ext Area Working Group (TSVWG) draft-ietf-tsvwg-fecframe-ext
(Work in Progress), July 2018, (Work in Progress), September 2018,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-tsvwg-fecframe-ext>. draft-ietf-tsvwg-fecframe-ext>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363, Correction (FEC) Framework", RFC 6363,
skipping to change at page 28, line 36 skipping to change at page 29, line 36
(FEC) Scheme for FECFRAME", RFC 6816, (FEC) Scheme for FECFRAME", RFC 6816,
DOI 10.17487/RFC6816, December 2012, DOI 10.17487/RFC6816, December 2012,
<https://www.rfc-editor.org/info/rfc6816>. <https://www.rfc-editor.org/info/rfc6816>.
[RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K.
Matsuzono, "Simple Reed-Solomon Forward Error Correction Matsuzono, "Simple Reed-Solomon Forward Error Correction
(FEC) Scheme for FECFRAME", RFC 6865, (FEC) Scheme for FECFRAME", RFC 6865,
DOI 10.17487/RFC6865, February 2013, DOI 10.17487/RFC6865, February 2013,
<https://www.rfc-editor.org/info/rfc6865>. <https://www.rfc-editor.org/info/rfc6865>.
[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek,
F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J.,
Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and
S. Sivakumar, "Taxonomy of Coding Techniques for Efficient
Network Communications", RFC 8406, DOI 10.17487/RFC8406,
June 2018, <https://www.rfc-editor.org/info/rfc8406>.
[Roca16] Roca, V., Teibi, B., Burdinat, C., Tran, T., and C. [Roca16] Roca, V., Teibi, B., Burdinat, C., Tran, T., and C.
Thienot, "Block or Convolutional AL-FEC Codes? A Thienot, "Block or Convolutional AL-FEC Codes? A
Performance Comparison for Robust Low-Latency Performance Comparison for Robust Low-Latency
Communications", HAL open-archive document,hal-01395937 Communications", HAL open-archive document,hal-01395937
https://hal.inria.fr/hal-01395937/en/, November 2016, https://hal.inria.fr/hal-01395937/en/, November 2016,
<https://hal.inria.fr/hal-01395937/en/>. <https://hal.inria.fr/hal-01395937/en/>.
[Roca17] Roca, V., Teibi, B., Burdinat, C., Tran, T., and C. [Roca17] Roca, V., Teibi, B., Burdinat, C., Tran, T., and C.
Thienot, "Less Latency and Better Protection with AL-FEC Thienot, "Less Latency and Better Protection with AL-FEC
Sliding Window Codes: a Robust Multimedia CBR Broadcast Sliding Window Codes: a Robust Multimedia CBR Broadcast
 End of changes. 27 change blocks. 
85 lines changed or deleted 141 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/