| Internet-Draft | Tetrys Network Coding Protocol | November 2022 |
| Detchart, et al. | Expires 21 May 2023 | [Page] |
This document describes Tetrys, an On-The-Fly Network Coding (NC) protocol that can be used to transport delay-sensitive and loss-sensitive data over a lossy network. Tetrys may recover from erasures within an RTT-independent delay, thanks to the transmission of Coded Packets. This document is a record of the experience gained by the authors while developing and testing the Tetrys protocol in real conditions.¶
This document is a product of the Coding for Efficient Network Communications Research Group (NWCRG). It conforms to the NWCRG taxonomy[RFC8406].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 May 2023.¶
Copyright (c) 2022 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document is a product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It is not an IETF product and is not an IETF standard.¶
This document describes Tetrys, a novel erasure coding protocol. Network codes were introduced in the early 2000s [AHL-00] to address the limitations of transmission over the Internet (delay, capacity and packet loss). While network codes have seen some deployment fairly recently in the Internet community, the use of application layer erasure codes in the IETF has already been standardized in the RMT [RFC3452] and the FECFRAME [RFC8680] working groups. The protocol presented here may be seen as a network coding extension to standard unicast transport protocols (or even multicast or anycast with a few modifications). The current proposal may be considered a combination of network erasure coding and feedback mechanisms [Tetrys], [Tetrys-RT] .¶
The main innovation of the Tetrys protocol is in the generation of Coded Packets from an Elastic Encoding Window. This window is filled by any Source Packets coming from an input flow and is periodically updated with the receiver feedback. These feedback messages provide to the sender with information about the highest sequence number received or rebuilt, which can enable flushing the corresponding Source Packets stored in the encoding window. The size of this window may be fixed or dynamically updated. If the window is full, incoming Source Packets replace older sources packets which are dropped. As a matter of fact, its limit should be correctly sized. Finally, Tetrys allows to deal with losses on both the forward and return paths and in particular, is resilient to acknowledgment losses. All these operations are further detailed in Section 4.¶
With Tetrys, a Coded Packet is a linear combination over a finite field of the data Source Packets belonging to the coding window. The coefficients finite field's choice is a trade-off between the best erasure recovery performance (finite fields of 256 elements) and the system constraints (finite fields of 16 elements is preferred) and is driven by the application.¶
Thanks to the Elastic Encoding Window, the Coded Packets are built on-the-fly, by using a predefined method to choose the coefficients. The redundancy ratio may be dynamically adjusted, and the coefficients may be generated in different ways, during the transmission. Compared to FEC block codes, this allows reducing the bandwidth use and the decoding delay.¶
The description of the design of the Tetrys protocol in this document is complemented by a record of the experience gained by the authors while developing and testing the Tetrys protocol in realistic conditions. In particular, several research issues are discussed in Section 6 following our own experience and observations.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The notation used in this document is based on the NWCRG taxonomy [RFC8406] .¶
Tetrys is well suited, but not limited to, the use case where there is a single flow originated by a single source, with intra stream coding at a single encoding node. Note that the input stream MAY be a multiplex of several upper layer streams. Transmission MAY be over a single path or multiple paths. This is the simplest use-case, that is very much aligned with currently proposed scenarios for end-to-end streaming.¶
+----------+ +----------+
| | | |
| App | | App |
| | | |
+----------+ +----------+
| ^
| Source Source |
| Symbols Symbols |
| |
v |
+----------+ +----------+
| | output packets | |
| Tetrys |--------------->| Tetrys |
| Encoder |Feedback Packets| Decoder |
| |<---------------| |
+----------+ +----------+
The Tetrys protocol features several key functionalities. The mandatory features are:¶
and the optional features are :¶
Several building blocks provide these functionalities:¶
To ease the addition of future components and services, Tetrys adds a header extension mechanism, compatible with that of LCT [RFC5651], NORM [RFC5740], FECFRAME [RFC8680].¶
At the beginning of a transmission, a Tetrys Encoder MUST choose an initial Code Rate (added redundancy) as it doesn't know the packet loss rate of the channel. In the steady state, depending on the Code Rate, the Tetrys Encoder MAY generate Coded Symbols when it receives a Source Symbol from the application or some feedback from the decoding blocks.¶
When a Tetrys Encoder needs to generate a Coded Symbol, it considers the set of Source Symbols stored in the Elastic Encoding Window and generates an Encoding Vector with the Coded Symbol. These Source Symbols are the set of Source Symbols that are not yet acknowledged by the receiver. For each Source Symbol, a finite field coefficient is determined using a Coding Coefficient Generator. This generator MAY take as input the Source Symbol IDs and the Coded Symbol ID and MAY determine a coefficient in a deterministic way as presented in Section 5.3. Finally, the Coded Symbol is the sum of the Source Symbols multiplied by their corresponding coefficients.¶
A Tetrys Encoder SHOULD set a limit to the Elastic Encoding Window maximum size. This controls the algorithmic complexity at the encoder and decoder by limiting the size of linear combinations. It is also needed in situations where window update packets are all lost or absent.¶
When an input Source Symbol is passed to a Tetrys Encoder, it is added to the Elastic Encoding Window. This window MUST have a limit set by the encoding building Block. If the Elastic Encoding Window reached its limit, the window slides over the symbols: the first (oldest) symbol is removed, and the newest symbol is added. As an element of the coding window, this symbol is included in the next linear combinations created to generate the Coded Symbols.¶
As explained below, the Tetrys Decoder sends periodic feedback indicating the received or decoded Source Symbols. When the sender receives the information that a Source Symbol was received or decoded by the receiver, it removes this symbol from the coding window.¶
All types of Tetrys packets share the same common header format (see Figure 2).¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | C |S| Reserved | HDR_LEN | PKT_TYPE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Congestion Control Information (CCI, length = 32*C bits) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Session Identifier (TSI, length = 32*S bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header Extensions (if applicable) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As already noted above in the document, this format is inspired and inherits from the LCT header format [RFC5651] with slight modifications.¶
Header Extensions are used in Tetrys to accommodate optional header fields that are not always used or have variable size. The presence of Header Extensions MAY be inferred by the Tetrys header length (HDR_LEN). If HDR_LEN is larger than the length of the standard header, then the remaining header space is taken by Header Extensions.¶
If present, Header Extensions MUST be processed to ensure that they are recognized before performing any congestion control procedure or otherwise accepting a packet. The default action for unrecognized Header Extensions is to ignore them. This allows the future introduction of backward-compatible enhancements to Tetrys without changing the Tetrys version number. Non-backward-compatible Header Extensions CANNOT be introduced without changing the Tetrys version number.¶
There are two formats for Header Extensions as depicted in Figure 3 :¶
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 (<=127) | HEL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Header Extension Content (HEC) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 (>=128) | Header Extension Content (HEC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Type (HET): 8 bits¶
The type of the Header Extension. This document defines several possible types. Additional types may be defined in future versions of this specification. HET values from 0 to 127 are used for variable-length Header Extensions. HET values from 128 to 255 are used for fixed-length 32-bit Header Extensions.¶
Header Extension Length (HEL): 8 bits¶
The length of the whole Header Extension field, expressed in multiples of 32-bit words. This field MUST be present for variable-length extensions (HETs between 0 and 127) and MUST NOT be present for fixed-length extensions (HETs between 128 and 255).¶
Header Extension Content (HEC): variable length¶
The content of the Header Extension. The format of this subfield depends on the Header Extension Type. For fixed-length Header Extensions, the HEC is 24 bits. For variable-length Header Extensions, the HEC field has variable size, as specified by the HEL field. Note that the length of each Header Extension MUST be a multiple of 32 bits. Also, note that the total size of the Tetrys header, including all Header Extensions and all optional header fields, cannot exceed 255 32-bit words.¶
A Source Packet is a Common Packet Header encapsulation, a Source Symbol ID and a Source Symbol (payload). The Source Symbols MAY have variable sizes.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Common Packet Header / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Symbol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Payload / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Common Packet Header: a common packet header (as common header format) where Packet Type=0.¶
Source Symbol ID: the sequence number to identify a Source Symbol.¶
Payload: the payload (Source Symbol)¶
A Coded Packet is the encapsulation of a Common Packet Header, a Coded Symbol ID, the associated Encoding Vector, and a Coded Symbol (payload). As the Source Symbols MAY have variable sizes, all the Source Symbol sizes need to be encoded. To generate this encoded payload size, as a 16-bit unsigned value, the linear combination uses the same coefficients as the coded payload. The result MUST be stored in the Coded Packet as the Encoded Payload Size (16 bits): as it is an optional field, the Encoding Vector MUST signal the use of variable Source Symbol sizes with the field V (see Section 5.3.1).¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Common Packet Header / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Coded Symbol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Encoding Vector / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Payload Size | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | / Payload / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Common Packet Header: a common packet header (as common header format) where Packet Type=1.¶
Coded Symbol ID: the sequence number to identify a Coded Symbol.¶
Encoding Vector: an Encoding Vector to define the linear combination used (coefficients and Source Symbols).¶
Encoded Payload Size: the coded payload size used if the Source Symbols have a variable size (optional,Section 5.3.1).¶
Payload: the Coded Symbol.¶
An Encoding Vector contains all the information about the linear combination used to generate a Coded Symbol. The information includes the source identifiers and the coefficients used for each Source Symbol. It MAY be stored in different ways depending on the situation.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EV_LEN | CCGI | I |C|V| NB_IDS | NB_COEFS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FIRST_SOURCE_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | b_id | | +-+-+-+-+-+-+-+-+ id_bit_vector +-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + coef_bit_vector +-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Coding Coefficient Generator Identifier (CCGI): 4-bit ID to identify the algorithm or the function used to generate the coefficients. As a CCGI is included in each encoded vector, it MAY dynamically change between the generation of 2 Coded Symbols. The CCGI builds the coding coefficients used to generate the Coded Symbols. They MUST be known by all the Tetrys encoders or decoders. The two RLC FEC schemes specified in this document reuse the Finite Fields defined in [RFC5510], Section 8.1. More specifically, the elements of the field GF(2^(m)) are represented by polynomials with binary coefficients (i.e., over GF(2)) and degree lower or equal to m-1. The addition between two elements is defined as the addition of binary polynomials in GF(2), which is equivalent to a bitwise XOR operation on the binary representation of these elements. With GF(2^(8)), multiplication between two elements is the multiplication modulo a given irreducible polynomial of degree 8. The following irreducible polynomial is used for GF(2^(8)): x^(8) + x^(4) + x^(3) + x^(2) + 1 With GF(2^(4)), multiplication between two elements is the multiplication modulo a given irreducible polynomial of degree 4. The following irreducible polynomial is used for GF(2^(4)): x^(4) + x + 1¶
Store the Source Symbol ID Format (I) (2 bits):¶
The Source Symbol IDs are organized as a sorted list of 32-bit unsigned integers. Depending on the feedback, the Source Symbol IDs MAY be successive or not in the list. If they are successive, the boundaries are stored in the Encoding Vector: it just needs 2*32-bit of information. If not, the full list or the edge blocks MAY be stored, and a differential transform to reduce the number of bits needed to represent an identifier MAY be used.¶
For the following subsections, let's take as an example the generation of an encoding vector for a Coded Symbol which is a linear combination of the Source Symbols with IDs 1,2,3,5,6,8,9 and 10 (or as edge blocks: [1..3],[5..6],[8..10])¶
There are several ways to store the Source Symbols IDs into the encoding vector:¶
Let's continue with our Coded Symbol defined in the previous section. The Source Symbols IDs used in the linear combination are: [1..3],[5..6],[8..10].¶
If we want to compress and store this list into the encoding vector, we MUST follow this procedure:¶
When a Tetrys Decoding Block wants to reverse the operations, this algorithm is used:¶
A Tetrys Decoder MAY send back to another building block some Window Update packets. They contain information about what the packets received, decoded or dropped, and other information such as a packet loss rate or the size of the decoding buffers. They are used to optimize the content of the encoding window. The window update packets are OPTIONAL, and hence they could be omitted or lost in transmission without impacting the protocol behavior.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Common Packet Header / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | nb_missing_src | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | nb_not_used_coded_symb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | first_src_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | plr | sack_size | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | / SACK Vector / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Common Packet Header: a common packet header (as common header format) where Packet Type=2.¶
nb_missing_src: the number of missing Source Symbols in the receiver since the beginning of the session.¶
nb_not_used_coded_symb: the number of Coded Symbols at the receiver that have not already been used for decoding (e.g., the linear combinations contain at least 2 unknown Source Symbols).¶
first_src_id: ID of the first Source Symbol to consider in the SACK vector.¶
plr: packet loss ratio expressed as a percentage normalized to a 8-bit unsigned integer. For example, 2.5 % will be stored as floor(2.5 * 256/100) = 6. Conversely, if 6 is the stored value, the corresponding packet loss ratio expressed as a percentage is 6*100/256 = 2.34 %. This value is used in the case of dynamic Code Rate or for statistical purpose. The choice of calculation is left to the Tetrys Decoder, depending on a window observation, but should be the PLR seen before decoding.¶
sack_size: the size of the SACK vector in 32-bit words. For instance, with value 2, the SACK vector is 64 bits long.¶
SACK vector: bit vector indicating symbols that must be removed in the encoding window from the first Source Symbol ID. In most cases, these symbols were received by the receiver. The other cases concern some events with non-recoverable packets (for example in the case of a burst of losses) where it is better to drop and abandon some packets, and thus to remove them from the encoding window, to allow the recovery of the following packets. The "First Source Symbol" is included in this bit vector. A bit equal to 1 at the i-th position means that this window update packet removes the Source Symbol of ID equal to "First Source Symbol ID" + i from the encoding window.¶
The present document describes the baseline protocol, allowing communications between a Tetrys encoder and a Tetrys decoder. In practice, Tetrys can be used either as a standalone protocol or embedded inside an existing protocol, and either above, within or below the transport layer. There are different research questions related to each of these scenarios that should be investigated for future protocol improvements. We summarize them in the following subsections.¶
The Tetrys and congestion control components generate two separate channels (see [RFC9265], section 2.1):¶
In practice, depending on how Tetrys is deployed (i.e., above, within or below the transport layer), [RFC9265] identifies and discusses several topics. They are briefly listed below and adapted to the particular case of Tetrys:¶
When the network conditions (e.g., delay and loss rate) strongly vary over time, an adaptive coding rate can be used to increase or reduce the amount of Coded Packets among a transmission dynamically (i.e., the added redundancy), with the help of a dedicated algorithm, similarly to [A-FEC]. Once again, the strategy differs, depending on which layer Tetrys is deployed (i.e., above, within or below the transport layer). Basically, we can slice these strategies in two distinct classes: when Tetrys is deployed inside the transport layer, versus outside (i.e., above or below). A deployment within the transport layer obviously means that interactions between transport protocol micro-mechanisms, such as the error recovery mechanism, the congestion control, the flow control or both, are envisioned. Otherwise, deploying Tetrys within a non congestion controlled transport protocol, like UDP, would not bring out any other advantage than deploying it below or above the transport layer.¶
The impact deploying a FEC mechanism within the transport layer is further discussed in [RFC9265], section 4, where considerations concerning the interactions between congestion control and coding rates, or the impact of fairness, are investigated. This adaptation may be done jointly with the congestion control mechanism of a transport layer protocol, as proposed by [CTCP]. This allows the use of monitored congestion control metrics (e.g., RTT, congestion events, or current congestion window size) to adapt the coding rate conjointly with the computed transport sending rate. The rationale is to compute an amount of repair traffic that does not lead to congestion. This joint optimization is mandatory to prevent flows to consume the whole available capacity as also discussed in [I-D.singh-rmcat-adaptive-fec] where the authors point out that an increase in the repair ratio should be done conjointly with a decrease in the source sending rate.¶
Finally, adapting a coding rate can also be done outside the transport layer and without considering transport layer metrics. In particular, this adaptation may be done jointly with the network as proposed in [RED-FEC]. In this paper, the authors propose a Random Early Detection FEC mechanism in the context of video transmission over wireless networks. Briefly, the idea is to add more redundancy packets if the queue at the access point is less occupied and vice versa. A first theoretical attempt for video delivery has been proposed [THAI] with Tetrys. This approach is interesting as it illustrates a joint collaboration between the application requirements and the network conditions and combines both signals coming from the application needs and the network state (i.e., signals below or above the transport layer).¶
To conclude, there are multiple ways to enable an adaptive coding rate. However, all of them depend on:¶
The use of Tetrys to protect an aggregate of flows, typically when Tetrys is used for tunneling, to recover from IP datagram losses, raises research questions. When redundancy is applied without flow differentiation, this may come in contradiction with the service requirements of individual flows, some of them may be more penalized by high latency and jitter than by partial reliability, while other flows may have opposite requirements. In practice head-of-line blocking will impact all flows in a similar manner despite their different needs, which asks for more elaborate strategies inside Tetrys.¶
First of all, it must be clear that the use of FEC protection to a data stream does not provide, per se, any kind of security, but, on the contrary, raises security risks. The situation with Tetrys is mostly similar to that of other content delivery protocols making use of FEC protection, and this is well described in FECFRAME [RFC6363]. This section leverages on this reference, adding new considerations to comply with Tetrys specificities when meaningful.¶
An attacker can either target the content, the protocol, or the network. The consequences will largely differ, reflecting various types of goals, like gaining access to confidential content, corrupting the content, compromizing the Tetrys Encoder and/or Tetrys Decoder, or compromizing the network behavior. In particular, several of these attacks aim at creating a Denial-of-Service (DoS), with consequences that may be limited to a single node (e.g., the Tetrys Decoder), or that may impact all the nodes attached to the targeted network (e.g., by making flows non-responsive to congestion signals).¶
In the following sections, we discuss these attacks, according to the component targeted by the attacker.¶
An attacker may want to access a confidential content, by eavesdropping the traffic between the Tetrys Encoder/Decoder. Traffic encryption is the usual approach to mitigate this risk, and this encryption can be done either on the source flow, above Tetrys, or below Tetrys, on the output packets, both Source and Coded Packets. The choice on where to apply encryption depends on various criteria, in particular the attacker model (e.g., when encryption happens below Tetrys, the security risk is assumed to be on the interconnection network).¶
An attacker may also want to corrupt the content (e.g., by injecting forged or modified Source and Coded Packets to prevent the Tetrys Decoder to recover the original source flow). Content integrity and source authentication services at the packet level are then needed to mitigate this risk. Here, these services need to be provided below Tetrys in order to enable the receiver to drop undesired packets and only transfer legitimate packets to the Tetrys Decoder. It should be noted that forging or modifying Feedback Packets will not corrupt the content, although it will certainly compromize Tetrys operation (see next section).¶
Attacks on signaling information (e.g., by forging or modifying Feedback Packets to pretend the good reception or recovery of source content) can easily prevent the Tetrys Decoder to recover the source flow, thereby creating a DoS. In order to prevent this type of attack, content integrity and source authentication services at the packet level are needed for the feedback flow, from the Tetrys Decoder to the Tetrys Encoder, as well. These services need to be provided below Tetrys, in order to drop undesired packets and only transfer legitimate Feedback Packets to the Tetrys Encoder.¶
On the opposite, an attacker in position to selectively drop Feedback Packets (instead of modifying them) will not severily impact Tetrys functionning, since Tetrys is naturally robust in front of such losses. However it will have side impacts, like the use of bigger linear systems (since the Tetrys Encoder cannot remove well received or decoded source packets from its linear system), which mechanically increases computational costs on both sides, encoder and decoder.¶
Tetrys can react to congestion signals (Section 6.1) in order to provide a certain level of fairness with other flows on a shared network. This ability could be exploited by an attacker to create or reinforce congestion events (e.g., by forging or modifying Feedback Packets), which can potentially impact a significant number of nodes attached to the network. Here also, in order to mitigate the risk, content integrity and source authentication services at the packet level are needed to enable the receiver to drop undesired packets and only transfer legitimate packets to the Tetrys Encoder and Decoder.¶
Tetrys can benefit from an IPsec/Encapsulating Security Payload (IPsec/ESP) [RFC4303], that provides in particular confidentiality, origin authentication, integrity, and anti-replay services. IPsec/ESP can be useful to protect the Tetrys data flows (both directions) against attackers located within the interconnection network, in position to eavesdrop traffic, or inject forged traffic, or replay legitimate traffic.¶
This document does not ask for any IANA registration.¶
Editor's notes: RFC Editor, please remove this section motivated by RFC 7942 before publishing the RFC. Thanks!¶
An implementation of Tetrys exists:¶
First, the authors want sincerely to thank Marie-Jose Montpetit for continuous help and support on Tetrys. Marie-Jo, many thanks!¶
The authors also wish to thank NWCRG group members for numerous discussions on on-the-fly coding that helped finalize this document.¶
Finally, the authors would like to thank Colin Perkins for providing comments and feedback on the document.¶