Delay-Tolerant Networking QUIC Convergence Layer Protocol Version 1

1.1. Document Description

This document describes the QUIC convergence-layer protocol (adapter) for Delay-/Disruption-Tolerant Networking (DTN). DTN is an end-to-end architecture enabling communications in "challenged networks", including networks with at least one of the following challenges: intermittent connectivity, long and/or variable delays, high packet loss due to link impairments. Among challenged networks, we have interplanetary networks, other space networks, and a variety of peculiar terrestrial and maritime networks. See [RFC4838].¶

The goal of the DTN architecture is to enable communications in challenged networks; to this aim it relies on the insertion of a new layer, called Bundle layer, in between the Application layer and (usually) the Transport layer. The corresponding protocol is the Bundle Protocol (BP), whose version 7 (BPv7) has been standardized in [RFC9171]. BPv7 requires the services of a "Convergence Layer Adapter" (CLA) to send and receive bundles using the services offered by a lower protocol. This document describes one such convergence-layer adapter that uses the QUIC protocol [RFC9000], including its Datagram extension [RFC9221]. This CLA is referred to as QUIC Convergence Layer version 1 (QUICCLv1); the A of adapter is dropped to be consistent with the acronyms in use for other CLAs, such as TCPCL, UDPCL, etc. For the remainder of this document:¶

• the abbreviation "BP" without the version suffix refers to BPv7¶
• the abbreviation "QUICCL" without the version suffix refers to QUICCLv1, the QUICCL version described in this document.¶

QUICCL and the Bundle Protocol do not fit well in the Internet model protocol stack, because the DTN architecture differs from the usual TCP/IP architecture, as a result of the addition of the Bundle layer. Note that the Bundle layer, being present on all DTN nodes, not only on end-points, cannot be interpreted as an Application sublayer (Application is present only on end-nodes). As an example, a possible protocol stack, referring to an end-node, is presented in Figure 1. QUICCL is a slim protocol located between BP and QUIC; as its only possible use is below BP, we have located it in the Bundle layer. Note that QUIC and UDP are both at Transport, as QUIC makes use of UDP. A DTN intermediate node would have the same stack, but without the DTN application on top of BP. Non DTN nodes may be present in between two adjacent DTN nodes, i.e. inside one DTN hop. In such a case, they will be transparent to the DTN architecture.¶

+-------------------------+
|     DTN Application     | ------> Application layer
+-------------------------+--
|   Bundle Protocol (BP)  | |
+-------------------------+ |------->Bundle layer
|          QUICCL         | |
+-------------------------+--
|           QUIC          | |
|-------------------------+ |-----> Transport layer
|           UDP           | |
+-------------------------+--
|        IPv4/IPv6        |-------> Network layer
+-------------------------+
|   Link-Layer Protocol   |-------> Link layer
+-------------------------+

1.2. Scope

This document describes the services provided by QUICCL to BP, the data to be exchanged between the BP and the QUICCL interface, the format of the protocol messages passed between QUICCL peers, and the internal mechanism of QUICCL necessary to provide the services offered to BP.¶

2.1. Security Incorporated in QUIC

QUIC design incorporates TLS (Transport Layer Security) security, thus all TCPCLv4 specifications related to TLS security have been omitted in QUICCL. This also made redundant the exchange of TCPCLv4 CONTACT_HEADER messages, whose primary aim was to indicate that the sending peer had enabled TLS security. CONTACT_HEADERs are thus no more present in QUICCL.¶

2.2. QUICCL Transport Services

A second fundamental difference with TCPCLv4 is that QUICCL provides three different transport services, reliable, unreliable and notified, instead of the sole reliable service. Under this respect, it is like LTP [RFC5326], which was designed to provide both a reliable and an unreliable service. The third transport service, notified, is similar to the analogous service introduced in Multicolor LTP, an LTP enhancement proposed by Unibo and DLR in [Bisacchi_2022]. In most BP/LTP implementations, such as ION [Burleigh_2007] and Unibo-BP [Caini_2024], the transport service selection of LTP is made bundle by bundle, on the basis of QoS elements contained in a QoS extension of the bundle itself. For example, in the ION implementation by NASA-JPL, by default LTP provides BP with a reliable service (LTP red), but the bundle source can override this deafault in favor of the unreliable service (LTP green), by setting the "best effort" flag in the ECOS (Extended Class of Service) bundle extension [I-D.burleigh-dtn-ecos]. A similar mechanism is present in Unibo-BP. QUICCL formalizes and extends this mechanism, as shown below, by taking advantage of the fact that although QUIC was initially designed as a reliable-only Transport protocol, based on QUIC streams [RFC9000] , it was later extended to offer also an unreliable service, with QUIC datagrams [RFC9221].¶

2.3. Priorities

The use of multiple QUIC streams is advantageous in HTTP, as in case of a loss on a stream, data sent on other streams can be delivered before the loss is recovered, which solves the "head of line blocking problem". This distinctive feature of QUIC, however, when applied to bundles has two significant drawbacks. First, bundles (of the same dimension) sent in parallel on N streams tend to arrive in a burst, instead of one by one, as when sent on a single stream. Note that the total transfer time is roughly the same, because when bundles are sent in parallel the bandwidth is shared (QUIC congestion control works on the aggregate of streams and includes also also QUIC datagram, as previously said), but now bundles tend to arrive together instaed of paced, which is per se a disadvantage. Moreover, bundles may arrive out of order, either becasue of minimal time differences between streams, or because one tranfer needed more time in order to recover from a loss (loss recovery is per stream in QUIC). Although not forbidden by BP specification, the introduction of disordered delivery is generally undesired; there is however an important exception, i.e. when bundles have different priorities. In this case, disordered delivery is actually what the user wants, if this means that bundles with higher priority arrive before bundles with lower priority.¶

3.1. Convergence-Layer Interface to BPA

The QUICCL protocol defines the following services/notifications to support the overlaying BPA. This is not an API definition but a logical description of how the CL can interact with the BPA. Some services/notifications are optional as indicated below. Each of these interactions can be associated with any number of additional metadata items as necessary to support the operation of the CL or BPA.¶

BPA commands to QUICCL:¶

Attempt Session:

The QUICCL MUST allow the BPA to preemptively attempt to establish a QUICCL session with a peer entity. Each session attempt may have a different set of session negotiation parameters as directed by the BPA.¶

Terminate Session:

The QUICCL MUST allow the BPA to preemptively terminate an established QUICCL session with a peer entity.¶

Begin Transmission:

The QUICCL MUST allow the BPA to transmit a bundle over an established QUICCL session.¶

Interrupt Reception (OPTIONAL):

The QUICCL MAY allow the BPA to interrupt the reception of a transfer before it has fully completed. Interruption can occur any time after the reception is initialized.¶

QUICCL notifications to BPA¶

Session State Changed:

The QUICCL entity can indicate some session state changes to the BPA. Unless marked as OPTIONAL, the following changes MUST be provided.¶

Connecting (OPTIONAL):

A QUIC connection is being established (active entity only).¶

Session Negotiating (OPTIONAL):

After the QUIC connection has been established, session negotiation has begun.¶

Established:

The session has entered the established state and is ready for its first transfer. The peer node ID and the negotiated session parameters are also to be communicated to the BPA.¶

Ending (OPTIONAL):

The entity sent a SESS_TERM message and has entered the Ending state.¶

Terminated:

The session has completed the normal termination sequencing.¶

Failed:

The session ended without normal termination sequencing.¶

Session Idle Changed (OPTIONAL):

The QUICCL entity MAY indicate to the BPA when the Live/Idle substate of the session changes. This occurs only when the top-level session state is "Established". The session transitions from Idle to Live at the start of a transfer in transfer streams; the session transitions from Live to Idle at the end of a transfer when the other transfer stream does not have an ongoing transfer. Note that because the QUICCL transmits in parallel over QUIC connection streams, by contrast to TCPCL it does not suffer from "head-of-queue blocking".¶

Transmission Success:

The QUICCL entity MUST indicate to the BPA when a bundle has been fully transferred to a peer entity.¶

Transmission Intermediate Progress (OPTIONAL):

The QUICCL entity MAY indicate the intermediate progress of a transfer to a peer entity. This intermediate progress is at the granularity of each transferred segment.¶

Transmission Failure:

The QUICCL entity MUST indicate certain reasons for bundle transmission failure, notably when the peer entity rejects the bundle or when a QUICCL session ends before transfer success, or when the transmission timer expires (notified service only).¶

Reception Initialized (OPTIONAL):

The QUICCL entity MAY indicate the reception of the XFER_SEGMENT message with the START flag set to 1.¶

Reception Success:

The QUICCL entity MUST indicate to the BPA when a bundle has been fully transferred from a peer entity.¶

Reception Intermediate Progress (OPTIONAL):

The QUICCL entity MAY indicate the intermediate progress of a transfer from the peer entity. This intermediate progress is at the granularity of each transferred segment. An indication of intermediate reception gives a BPA the chance to inspect bundle header contents before the entire bundle is available and thus supports the "Interrupt Reception" capability.¶

Reception Failure (OPTIONAL):

The QUICCL entity MAY indicate certain reasons for reception failure, notably when the local entity rejects an attempted transfer for some local policy reason or when a QUICCL session ends before transfer success, or when the reception timer fires (unreliable and notified services only).¶

3.2. Overview of a basic QUICCL session

This overview will give a brief description of a regular QUICCL session (i.e., without session failures). Its states and transitions are shown in Figure 4. Details and format of messages exchanged will be defined later.¶

One entity establishes a QUICCL session to the other by initiating a QUIC connection in accordance with [RFC9000]. Note that the exchange of "contact headers" of TCPCLv4 has been dropped, the reasons are fully detailed in Section 3.2.1. After the QUIC connection is established, session negatiation starts, with the exchange of two SESS_INIT messages (see Section 3.3.1) . In this phase the parameters to be used during the QUICCL session are set. Once negotiated, the QUICCL session is established and its parameters cannot change.¶

Once the session is established, bundles can be transferred in either direction; bundle tranmission is "full duplex": one side's bundle transfer does not have to complete before the other side can start sending bundles on its own. Each transfer is performed by segmenting the transfer data into one or more XFER_SEGMENT messages (see Section 3.5). By contrast to TCPCLv4, multiple bundles can be transmitted in parallel in the same direction, by exploiting QUIC streams and Datagrams.¶

XFER_SEGMENTs are usually acknowledged by XFER_ACK messages. Although there is no explicit flow control on QUICCL, congestion and flow controls are performed by QUIC, running below.¶

A QUICCL receiver can interrupt the transmission of a bundle at any point in time by replying to a XFER_SEGMENT with a XFER_REFUSE message, which causes the sender to stop transmission of the associated bundle (if it has not already finished transmission).¶

An esatablised session can either be live, if transfers are on going, or idle, otherwise. For sessions that are idle, KEEPALIVE messages are sent at a negotiated interval.¶

Every peer can start the session termination procedure by sending a SESS_TERM message to the other peer, which will respond with another SESS_TERM message (see Section 3.3.3). During termination sequencing, in-progress transfers can be completed but no new transfers can be initiated. A SESS_TERM message can also be used to refuse a session setup by a peer.¶

At the end of the session termination procedure the QUIC connection is released.¶

  +-------+
  | START |
  +-------+
      |
  QUIC Establishment
      |
      V
+-----------+            +---------------------+
|   QUIC    |----------->|     Session         |
| Connected |            |     Negotiation     |
+-----------+            +---------------------+
                                    |
       +-----Session Parameters-----+
       |         Negotiated
       V
+-------------+                     +-------------+
| Established |----New Transfer---->| Established |
|   Session   |                     |   Session   |
|    Idle     |<---Transfers Done---|     Live    |
+-------------+                     +-------------+
      |                                    |
      +------------------------------------+
      |
      V
+-------------+
| Established |                    +-------------+
|   Session   |----Transfers------>|     QUIC     |
|   Ending    |      Done          | Terminating |
+-------------+                    +-------------+
                                           |
     +----------QUIC Close Message----------+
     |
     V
 +-------+
 |  END  |
 +-------+

Notes on established session states:¶

• Session "Live" means transmitting or receiving over at least a Transfer flow.¶
• Session "Idle" means no transmission/reception over any Transfer flows.¶
• Session "Ending" means no new transfers will be allowed.¶

3.4. Session-Keeping Policies

This specification defines requirements regarding how to initiate, sustain, and terminate a QUICCL session but does not impose any requirements on how sessions need to be managed by a BPA. It is a network administration matter to determine an appropriate session-keeping policy. Guidance given in [RFC9174] for TCPCL is still valid for QUICCL; the interested reader is referred to this document for further information.¶

3.6. Example (reliable service)

To complete the general escription of the protocol, an example is in order. Figure 12 depicts the protocol exchange for a simple session, showing the session establishment and the transmission of a single bundle with the reliable service. The bundle is split into three data segments (of lengths "L1", "L2)", and "L3") from Entity A to Entity B. One bundle transfer is always performed by using one Transfer flow, i.e. one stream when in a relaible way, as here. This means that if the bundle is large enough to require multiple XFER_SEGMENTS, each segment must be transferred on the same QUIC stream. Different bundles may be sent either sequentially on the same stream, or in parallel on multiple streams.¶

Note that the sending entity can transmit multiple XFER_SEGMENT messages without waiting for the corresponding XFER_ACK responses. This enables pipelining of messages on one stream. Although this example only demonstrates a single bundle transmission, it is also possible to pipeline multiple XFER_SEGMENT messages for different bundles without necessarily waiting for XFER_ACK messages to be returned for each one. However, interleaving data segments from different bundles on the same stream is never allowed. No errors or rejections are shown in this example.¶

             Entity A                             Entity B
             ========                             ========
    +-------------------------+
    | Open QUIC Connection    | ->      +-------------------------+
    +-------------------------+      <- |    Accept Connection    |
                                        +-------------------------+
    +-------------------------+
    |        SESS_INIT        | ->      +-------------------------+
    +-------------------------+      <- |        SESS_INIT        |
                                        +-------------------------+

    +-------------------------+
    |   XFER_SEGMENT (start)  | ->
    |     Transfer ID (I1)    |
    |       Length (L1)       |
    |  Bundle Data 0..(L1-1)  |
    +-------------------------+
    +-------------------------+         +-------------------------+
    |     XFER_SEGMENT        | ->   <- |     XFER_ACK (start)    |
    |     Transfer ID (I1)    |         |     Transfer ID (I1)    |
    |       Length   (L2)     |         |        Length   (L1)    |
    |Bundle Data L1..(L1+L2-1)|         +-------------------------+
    +-------------------------+
    +-------------------------+         +-------------------------+
    |    XFER_SEGMENT (end)   | ->   <- |         XFER_ACK        |
    |     Transfer ID (I1)    |         |     Transfer ID (I1)    |
    |        Length   (L3)    |         |      Length   (L1+L2)   |
    |Bundle Data              |         +-------------------------+
    |    (L1+L2)..(L1+L2+L3-1)|
    +-------------------------+
                                        +-------------------------+
                                     <- |      XFER_ACK (end)     |
                                        |     Transfer ID (I1)    |
                                        |     Length   (L1+L2+L3) |
                                        +-------------------------+

    +-------------------------+
    |       SESS_TERM         | ->      +-------------------------+
    +-------------------------+      <- |        SESS_TERM        |
                                        +-------------------------+
    +-------------------------+         +-------------------------+
    |       QUIC Close        | ->   <- |        QUIC Close        |
    +-------------------------+         +-------------------------+

The general protcol description given so far will be complemented by details and message formats in the next main section.¶

4.1. QUIC Connection Establishment notes

As QUIC is a transport protocol that makes use of UDP (essentially to bypass NATs), QUICCL must be associated to a UDP port. IANA is requested to assign the UDP port number 4560 to QUICCL, see Section 6.1, and the use of this port number as a default for a QUICCL passive entity is RECOMMENDED while waiting for the official IANA assignment. Other destination port numbers MAY be used per local configuration. Determining a peer's destination port number (if different from the default QUICCL port number) is left up to the implementation. Any source port number MAY be used for QUICCL sessions. Typically, an operating system assigned number in the UDP ephemeral range (49152-65535) is used.¶

The TLS Application-Layer Protocol Negotiation identifier which MUST be used by the QUICCL peers when opening a QUIC session is "quicclav1".¶

A node may choose to either initiate a new session for each bundle transfer or keep a session open for as long as possible, using it when necessary. In the former case, it is convenient to make use of QUIC 0-RTT feature [RFC9000] [RFC9308], if available.¶

If the entity is unable to establish a QUIC connection for any reason, then it is an implementation matter to determine how to handle the connection failure. An entity MAY decide to reattempt to establish the connection. If it does so, it MUST NOT overwhelm its target with repeated connection attempts. Therefore, the entity MUST NOT retry the connection setup earlier than some delay time from the last attempt, and it SHOULD use a (binary) exponential backoff mechanism to increase this delay in the case of repeated failures. The upper limit on a reattempt backoff is implementation defined but SHOULD be no longer than one minute (60 seconds) before signaling to the BPA that a connection cannot be made.¶

4.2. QUIC Stream Types in QUICCL

QUIC streams are not negotiated when a QUIC connection is established, but are simply declared by a QUIC engine when data are sent. Streams can be of four types, depending whether they are unidirectional or bidirectional, and client or server-initiated. Unidirectional streams carry data in one direction, from the initiator of the stream to its peer; bidirectional streams allow for data to be sent in both directions. Each stream is identified by an integer number, the stream ID, which also identify its type. For bidirectional streams, the only used by QUICCL, we have 0, 4, 8, 12, 16, etc. for the streams initiated by the client, and 1, 5, 9, 13, 17, etc. for those initiated by the server.¶

In QUICCL the stream 0 is reserved to the transmission of signalling QUICCL messages that are not associated to a Transfer flow, and it is the only stream used by QUICCL in a logical bidirectional way, i.e. by both the QUICCL active peer (the QUIC client) and passive peer (the QUIC server). The QUICCL active peer by default will use streams 4, 8, 12 and 16 to send XFER_SEGMENTs corresponding to bundles of expedited, normal, bulk and no priority; the return direction of these streams will be used only for corresponding XFER_ACKs. In a dual way, the passive peer will use streams 1, 5, 9, 13, to send data in the opposite direction.¶

These streams SHOULD be associated to decreasing QUIC priorities, in order to offer the fastest transmission to signalling messages on stream 0 and then to expedited, normal, bulk and no priority XFER_SEGMENTS. The way by which priority are associated to QUIC streams is left by [RFC9000] to the QUIC implementation. In the presence of many levels of QUIC priorities (e.g. 256), as in the Picoquic implementation used by Unibo-BP, the full priority range SHOULD be used to ensure a significant interval between QUIC priorities associated to the four streams.¶

A QUICCL implementation SHOULD allow the user to override the default priority mapping, e.g. by selecting the use of N streams without priorities. In the particular case of one stream only, i.e. N=1, the streams to be used should be 4 and 1 for the client and the server, respectively. Analogously for other values of N. When QUIC streams are not associated to bundle priorities, they SHOULD have the same priority, but stream 0, which MAY have a higher priority.¶

4.3. Message Types

Once the QUIC connection is established, the two QUICCL peers exchange QUICCL messages of various kind, most of which have been anticipated above. All messages have a header whose format is very simple, as it consists of a unique field, the message type, shown in Figure 13¶

0 1 2 3 4 5 6 7
+---------------+
| Message Type  |
+---------------+

Message types codes are shown in Table 2.¶

The format and use of these messages will be shown in the next sub-sections.¶

4.4. Session Initialization (SESS_INIT)

Once the QUIC connection is established, both peers must send a SESS_INIT message on QUIC stream 0. Since stream 0 is client-initiated according to the QUIC specification, it follows that the passive QUICCL peer must receive the active peer's SESS_INIT before sending its own. The SESS_INIT message exchange is used to determine the per-session parameters.¶

+-----------------------------+
|       Message Header        |
+-----------------------------+
|   Keepalive Interval (U16)  |
+-----------------------------+
|       Segment MRU (U64)     |
+-----------------------------+
|      Datagram MRU (U64)     |
+-----------------------------+
|      Transfer MRU (U64)     |
+-----------------------------+
|     Node ID Length (U16)    |
+-----------------------------+
|    Node ID Data (variable)  |
+-----------------------------+
|      Session Extension      |
|      Items Length (U32)     |
+-----------------------------+
|      Session Extension      |
|         Items (var.)        |
+-----------------------------+

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+---------------+---------------+---------------+---------------+
|  Item Flags   |           Item Type           | Item Length...|
+---------------+---------------+---------------+---------------+
| length contd. | Item Value...                                 |
+---------------+---------------+---------------+---------------+

4.5. Bundle Transfer (XFER_SEGMENT)

A single QUICCL transfer consists in the transmission of a bundle (handled by the convergence layer as opaque data) between two QUICCL entities. Bundle data is transmitted in one or more segments, each carried by a XFER_SEGMENT message.¶

In the QUICCL reliable service, based on QUIC streams, a transfer is accomplished by dividing a single bundle up into "segments" based on the receiving-side Segment MRU, which is defined in Section 4.4.1. The choice of the length to use for segments is an implementation matter, but each segment MUST NOT be larger than the receiving entity's Segment MRU. The first segment for a bundle is indicated by the START flag, and the last segment is indicated by the END flag.¶

In unreliable and notified services, based on QUIC datagrams, a transfer is accomplished exactly as before, with the only notable difference that segments now must fit into QUIC Datagrams, thus their dimension is based on the receiving-side Datagram MRU, instead of Segment MRU.¶

A single transfer (and, by extension, a single segment) SHALL NOT contain data of more than a single bundle.¶

+------------------------------+
|       Message Header         |
+------------------------------+
|     Message Flags (U8)       |
+------------------------------+
|      Segment ID (U16)        |
+------------------------------+
|      Total Segments (U16)    |
+------------------------------+
|      Transfer ID (U64)       |
+------------------------------+
|     Transfer Extension       |
|      Items Length (U32)      |
|   (only for START segment)   |
+------------------------------+
|     Transfer Extension       |
|         Items (var.)         |
|   (only for START segment)   |
+------------------------------+
|      Segment Length (U64)    |(length in Moffa, Data l. in TCPCLv4)
+------------------------------+
|      Bundle Length (U64)     | It was total length in Moffa's thesis
+------------------------------+
|      Service Mode (U8)       |
+------------------------------+
| Data Contents (octet string) |
+------------------------------+

4.6. Segment Acknowledgment (XFER_ACK)

The QUICCL protocol usually acknowledges reception of data segments, as TCPCLv4 does. The notable exception is when data segments are sent by using the unreliable service. XFER_ACKs are sent back on the same stream used by the corresponding XFER_SEGMENT in the reliable service, or as Datagarams, in the notified service.¶

+-----------------------------+
|       Message Header        |
+-----------------------------+
|     Message Flags (U8)      |
+-----------------------------+
|     Segment ID (U16)        |
+-----------------------------+
|      Transfer ID (U64)      |
+-----------------------------+
| Acknowledged Length (U64)   |
+-----------------------------+

4.7. Transfer Refusal (XFER_REFUSE)

QUICCL supports a mechanism by which a receiving entity can indicate to the sender that it does not want to receive other segments of a partiually received bundle. To do so, upon receiving a XFER_SEGMENT message, the entity MAY transmit a XFER_REFUSE message, reporting the Transfer ID of the refused bundle. The XFER_REFUSE messages must be sent back on the same stream used by the corresponding XFER_SEGMENT in the reliable service, or as Datagram, in the notified or unreliable services, as XFER_ACKs do. There is no required relationship between the Transfer MRU of a QUICCL entity (which is supposed to represent a firm limitation of what the entity will accept) and the sending of a XFER_REFUSE message. A XFER_REFUSE can be used in cases where the agent's bundle storage is temporarily depleted or somehow constrained. A XFER_REFUSE can also be used after the bundle header or any bundle data is inspected by an agent and determined to be unacceptable.¶

A transfer receiver MAY send a XFER_REFUSE message as soon as it receives any XFER_SEGMENT message. The transfer sender MUST be prepared for this and MUST associate the refusal with the correct bundle via the Transfer ID fields.¶

The QUICCL itself does not have any required behavior related to responding to a XFER_REFUSE based on its reason code; the refusal is passed up as an indication to the BPA that the transfer has been refused. If a transfer refusal has a reason code that is not decodable to the BPA, the agent SHOULD treat the refusal as having a reason code of "Unknown".¶

For each transfer preceding (on the same Transfer flow) the one to be refused, the reciever MUST have either acknowledged all related XFER_SEGMENT messages or refused the bundle transfer.¶

The bundle transfer refusal MAY be sent also before an entire data segment is received. If a sender receives a XFER_REFUSE message, the sender MUST complete the transmission of any partially sent XFER_SEGMENT message. There is no way to interrupt an individual QUICCL message partway through sending it. The sender MUST NOT subsequently commence transmission of any further segments of the refused bundle. Note, however, that this requirement does not ensure that an entity will not receive another XFER_SEGMENT for the same bundle after transmitting a XFER_REFUSE message, since messages can cross on the wire; if this happens, subsequent segments of the bundle SHALL also be refused with a XFER_REFUSE message.¶

Note: If a bundle transmission is aborted in this way, the receiver does not receive a segment with the END flag set to 1 for the aborted bundle. The beginning of the next bundle is identified by the START flag set to 1, indicating the start of a new transfer, and with a distinct Transfer ID value.¶

+-----------------------------+
|       Message Header        |
+-----------------------------+
|      Reason Code (U8)       |
+-----------------------------+
|      Transfer ID (U64)      |
+-----------------------------+

4.9. KEEPALIVE Format

The format of a KEEPALIVE message is a one-octet Message Type code of KEEPALIVE (as described in Table 2) with no additional data. Both sides SHALL send a KEEPALIVE message whenever the negotiated interval has elapsed with no transmission of any message (KEEPALIVE or other).¶

If no message (KEEPALIVE or other) has been received in a session after some implementationdefined time duration, then the entity SHALL terminate the session by transmitting a SESS_TERM message (as described in Section 4.10) with a reason code of "Idle timeout". If configurable, the idle timeout duration SHOULD be no shorter than twice the Keepalive Interval. If not configurable, the idle timeout duration SHOULD be exactly twice the Keepalive Interval.¶

4.11. Message Rejection (MSG_REJECT)

The purpose of this message type is to let the peer know why the current entity is not responding as expected to its messages. The MSG_REJECT messages must be sent back on the same stream used by the corresponding message, in the reliable service, or as Datagram, in the notified or unreliable services.¶

If a QUICCL entity receives a message type that is unknown to it (possibly due to an unhandled protocol version mismatch or an incorrectly negotiated session extension that defines a new message type), the entity SHALL send a MSG_REJECT message with a reason code of "Message Type Unknown" and close the QUIC connection. If a QUICCL entity receives a message type that is known but is inappropriate for the negotiated session parameters (possibly due to an incorrectly negotiated session extension), the entity SHALL send a MSG_REJECT message with a reason code of "Message Unsupported". If a QUICCL entity receives a message that is inappropriate for the current session state (e.g., a SESS_INIT after the session has already been established or a XFER_ACK message with an unknown Transfer ID), the entity SHALL send a MSG_REJECT message with a reason code of "Message Unexpected".¶

+-----------------------------+
|       Message Header        |
+-----------------------------+
|      Reason Code (U8)       |
+-----------------------------+
|   Rejected Message Header   |
+-----------------------------+

5.1. Threat: Passive Leak of Bundle Data

The QUICCL can be used to provide point-to-point transport security, but it does not provide security of data at rest and does not guarantee end-to-end bundle security. The bundle security mechanisms defined in [RFC9172] are to be used instead.¶

5.2. Threat: Denial of Service

The behaviors described in this section all amount to a potential denial of service to a quicCL entity. The denial of service could be limited to an individual QUICCL session, could affect other well-behaved sessions on an entity, or could affect all sessions on a host.¶

A malicious entity can trigger timeouts by continually establishing QUICCL sessions and delaying the sending of protocol-required data. The victim entity can block QUIC connections from network peers that are thought to behave incorrectly within the QUICCL.¶

An entity can send a large amount of data over a QUICCL session, requiring the receiving entity to handle the data. The victim entity can attempt to stop the flood of data by sending a XFER_REFUSE message or can forcibly terminate the session.¶

A "data dribble" attack is also possible, in which an entity presents a very small Segment MRU that causes transfers to be split among a large number of very small segments and causes the resultant segmentation overhead to overwhelm the actual bundle data segments. Similarly, an entity can present a very small Transfer MRU that will cause resources to be wasted on establishment and upkeep of a QUICCL session over which a bundle could never be transferred. The victim entity can terminate the session during parameter negotiation (Section 4.7) if the MRUs are unacceptable. An abusive entity could cause the keepalive mechanism to waste throughput within a network link that would otherwise be usable for bundle transmissions. Due to the quantization of the Keepalive Interval parameter, the smallest Session Keepalive is one second, which should be long enough to not flood the link. The victim entity can terminate the session during parameter negotiation (Section 4.7) if the Keepalive Interval is unacceptable.¶

Finally, an attacker or a misconfigured entity can cause issues at the QUIC connection that will cause unnecessary QUIC retransmissions or connection resets, effectively denying the use of the overlying QUICCL session.¶

7.1. Normative References

[IANA-BUNDLE]

IANA, "Bundle Protocol", <https://www.iana.org/assignments/bundle/>.

[IANA-PORTS]

IANA, "Service Name and Transport Protocol Port Number Registry", <https://www.iana.org/assignments/service-names-port-numbers/>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3552]

Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC9171]

Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, <https://www.rfc-editor.org/info/rfc9171>.

[RFC9172]

Birrane, III, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022, <https://www.rfc-editor.org/info/rfc9172>.

[RFC9174]

Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4", RFC 9174, DOI 10.17487/RFC9174, January 2022, <https://www.rfc-editor.org/info/rfc9174>.

[RFC9221]

Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, March 2022, <https://www.rfc-editor.org/info/rfc9221>.

7.2. Informative References

[RFC4838]

Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, <https://www.rfc-editor.org/info/rfc4838>.

[RFC5050]

Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, DOI 10.17487/RFC5050, November 2007, <https://www.rfc-editor.org/info/rfc5050>.

[RFC5326]

Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, DOI 10.17487/RFC5326, September 2008, <https://www.rfc-editor.org/info/rfc5326>.

[RFC7301]

Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC9308]

Kühlewind, M. and B. Trammell, "Applicability of the QUIC Transport Protocol", RFC 9308, DOI 10.17487/RFC9308, September 2022, <https://www.rfc-editor.org/info/rfc9308>.

[I-D.burleigh-dtn-ecos]

Burleigh, S. and F. Templin, "Bundle Protocol Extended Class of Service (ECOS)", Work in Progress, Internet-Draft, draft-burleigh-dtn-ecos-00, 5 May 2021, <https://datatracker.ietf.org/doc/html/draft-burleigh-dtn-ecos-00>.

[Bisacchi_2022]

Bisacchi, A., Caini, C., and T. de Cola, "Multicolor Licklider Transmission Protocol: An LTP Version for Future Interplanetary Links", IEEE Transactions on Aerospace and Electronic Systems, vol. 58, no. 5, pp. 3859-3869, DOI 10.1109/TAES.2022.3176847, October 2022, <https://doi.org/10.1109/TAES.2022.3176847>.

[Burleigh_2007]

Burleigh, S., "Interplanetary Overlay Network: An Implementation of the DTN Bundle Protocol", IEEE Consumer Commun. and Networking Conference, 2007, pp. 222-226, DOI 10.1109/CCNC.2007.51, January 2007, <https://doi.org/10.1109/CCNC.2007.51>.

[Caini_2024]

Caini, C. and L. Persampieri, "Design and Features of Unibo-BP, the Unibo Implementation of the DTN Bundle Protocol", IEEE Journal of Radio Frequency Identification, vol. 8, pp. 458-467, DOI 10.1109/JRFID.2024.3358012, January 2024, <https://doi.org/10.1109/JRFID.2024.3358012>.