]> Aalyria Technologies

<rtaylor@aalyria.com>

Aalyria Technologies

<ek.ietf@gmail.com>

INT Delay/Disruption Tolerant Networking DTN BPv7 QUIC Convergence Layer This document specifies a minimal convergence layer protocol for transferring Bundle Protocol version 7 (BPv7) bundles over QUIC. The protocol leverages QUIC's native capabilities for reliable streaming, connection management, and security, requiring no application-layer framing for reliable transfers. Unreliable transfers use the Bundle Transfer Protocol - Unidirectional (BTP-U) over QUIC datagrams. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Bundle Protocol version 7 (BPv7) requires Convergence Layer Adapters (CLAs) to transfer bundles between nodes. This document specifies the QUIC Bundle Protocol Convergence Layer (QBCL or "qubicle"), a minimal CLA using QUIC that embraces QUIC's native capabilities rather than layering additional protocol machinery. The design philosophy is simple: QUIC already provides reliable streams, multiplexing, flow control, congestion control, and integrated security. This specification adds only what is strictly necessary to transfer bundles. The protocol provides two services:

Reliable Service:

Bundles are transferred on QUIC streams with guaranteed delivery.

Unreliable Service:

Bundles are transferred via QUIC datagrams using framing.

Conventions and Definitions 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 BCP 14 when, and only when, they appear in all capitals, as shown here.

Client:

The Qubicle peer that initiates the QUIC connection. This is a connection-level role and does not imply any restriction on bundle transfer direction.

Server:

The Qubicle peer that accepts the QUIC connection. This is a connection-level role and does not imply any restriction on bundle transfer direction.

Qubicle Session:

The period during which a QUIC connection is established between two Qubicle peers. A session begins when the QUIC handshake completes and ends when the QUIC connection closes. Both client and server are equal peers for the purpose of bundle transfer.

Protocol Overview

Connection Establishment A Qubicle session is established by initiating a QUIC connection to a peer. The QUIC handshake provides mutual authentication via TLS 1.3 . The ALPN identifier for Qubicle is qbcl.

Reliable Bundle Transfer For reliable transfer, each bundle is sent on a dedicated QUIC unidirectional stream:

1. The sender creates a new unidirectional stream.
2. The sender writes the complete bundle (CBOR-encoded per ) to the stream.
3. The sender closes the stream by sending a STREAM frame with the FIN bit set.

The bundle is implicitly framed by the stream boundaries. No length prefix or application-layer framing is required. The receiver reads data from the stream until FIN is received, then delivers the complete bundle to the BPA. Receipt of more than one Bundle on a given stream is a protocol error, and the receiver MUST abort the connection with QBCL_PROTOCOL_ERROR. QUIC guarantees reliable, in-order delivery of stream data. No application-layer acknowledgment is required; the sender can consider the transfer complete when QUIC confirms the stream data has been acknowledged by the peer. Completed transfer at the convergence layer does not guarantee successful receipt at the receiving Bundle Protocol Agent, so this signal alone does not suffice to indicate when a Bundle can be deleted from the sender. Additional information at the Bundle Protocol layer is required to confirm successful transfer.

Bidirectional Bundle Flow Both peers can send bundles simultaneously. Each peer creates unidirectional streams to send its bundles. QUIC stream IDs inherently separate client-initiated streams (IDs 2, 6, 10...) from server-initiated streams (IDs 3, 7, 11...), ensuring no collision between the two directions of bundle flow.

Stream Selection and Priority Senders MAY use QUIC stream priorities to expedite higher-priority bundles. The mapping of bundle priority to QUIC stream priority is an implementation matter.

Stream Exhaustion QUIC stream identifiers are 62-bit values, providing an effectively unlimited number of streams per connection. The MAX_STREAMS transport parameter limits concurrent streams, not the total number of streams over a connection's lifetime. If an implementation reaches practical limits on stream creation, it SHOULD close the connection and establish a new one.

Unreliable Bundle Transfer For unreliable transfer, bundles are sent using QUIC datagrams with framing. Each QUIC datagram contains one or more messages. The specification defines segmentation, reassembly, transfer identification, and optional repetition for probabilistic reliability. Implementations MUST negotiate the QUIC max_datagram_frame_size transport parameter to enable datagram support. The mapping of bundle priority to transfer interleaving is an implementation matter.

Connection Termination To terminate a session, a peer closes the QUIC connection using CONNECTION_CLOSE. Application-specific error codes are defined in . A peer MAY close the connection at any time. In-flight reliable transfers on incomplete streams will fail; the BPA is notified of the failure.

Transfer Cancellation TODO(ek): describe how a receiver can cancel a transfer via STOP_SENDING.

Keepalive Qubicle relies on QUIC's native idle timeout mechanism. Peers negotiate the max_idle_timeout transport parameter during connection establishment. If application-layer liveness detection is required, implementations MAY send QUIC PING frames.

Error Codes The following application error codes are defined for use with QUIC CONNECTION_CLOSE: Qubicle Error Codes

Code	Name	Description
0x00	QBCL_NO_ERROR	Graceful closure, no error
0x01	QBCL_PROTOCOL_ERROR	Qubicle protocol error encountered

Security Considerations

Transport Security QUIC mandates TLS 1.3 for all connections, providing confidentiality, integrity, and authentication. Qubicle inherits these security properties. Implementations SHOULD require peer certificate authentication. The Node ID in the transport parameter SHOULD match an identity in the peer's certificate. The BundleEID OtherName form defined in provides a standard mechanism for embedding DTN Node IDs in X.509 certificates. Automated certificate provisioning is available via the ACME extensions defined in .

Bundle Security Transport security protects bundles in transit between adjacent nodes. For end-to-end bundle security, implementations SHOULD use BPSec .

Denial of Service QUIC provides built-in protection against many denial-of-service attacks, including address validation and amplification prevention. Implementations SHOULD apply rate limiting on bundle reception to prevent resource exhaustion.

0-RTT Considerations QUIC 0-RTT data is subject to replay attacks. Implementations that enable 0-RTT SHOULD only send bundles that are safe to replay (e.g., bundles with replay protection at the bundle layer).

Operational Considerations

Version Negotiation Qubicle endpoints wishing to combat various ossification vectors are RECOMMENDED to support version negotiation and the same Bundle transfer operations described in this memo over QUIC v2 .

Convergence Layer Fallback As noted in , some networks block UDP traffic such that Qubicle connections cannot be established. Bundle Protocol Agents that employ Qubicle are RECOMMENDED to support additional Convergence Layers, e.g. TCPCLv4 .

Coexistence With Other UDP-based Convergence Layers It is RECOMMENDED that Qubicle implementations use a dedicated UDP port for operational simplicity. Bundle Protocol Agents that employ Qubicle and other UDP-based Convergence Layers on the same UDP port MUST be able to disambiguate received datagrams in order to route them to the correct CLA. For UDP CLs that use DTLS, provides the required guidance to disambiguate QUIC traffic from DTLS-encapsulated CL traffic.

Finding a Qubicle Endpoint Via DNS Qubicle senders may be manually provisioned with a hostname (or IP addresses) and UDP port corresponding to the listening Qubicle endpoint for a peer Bundle Protocol Agent. If only a hostname is known but a port is not, SVCB Resource Records may be looked up to find a listening UDP port and confirm expected ALPN configuration. Consider this zone file for example.: A BPA supporting both may attempt to resolve an SRV record for the _dtn-bundle._tcp prefixed hostname. A BPA that support Qubicle might also issue DNS SVCB queries for the prefix "_qbcl". The sample above indicates that mars-orbiter.example. has an SVCB record in AliasMode referring to cloud-agent.example. The SVCB record associated with cloud-agent.example. contains all required QUIC transport rendezvous information.

IANA Considerations

ALPN Identifier IANA is requested to register the following ALPN identifier in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry: ALPN Registration

Protocol	Identification Sequence	Reference
Qubicle	0x71 0x62 0x63 0x6C ("qbcl")	This document

AttrLeaf Node Name Per , IANA is request to add the following entry to the DNS "Underscored and Globally Scoped DNS Node Names" registry: AttrLeaf Registration

RR Type	_NODE NAME	Reference
SVCB	_qbcl	this document

Application Error Codes IANA is requested to create a new registry "Qubicle Error Codes" with the following initial values: Error Code Registry

Code	Name	Reference
0x00	QBCL_NO_ERROR	This document
0x01	QBCL_PROTOCOL_ERROR	This document
0x02-0xEF	Unassigned
0xF0-0xFF	Reserved for Private Use	This document

References Normative References Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. Aalyria Technologies This document defines a protocol for the unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by a unidirectional, unreliable, frame- based link-layer protocol, without requiring IP services. The protocol does not require a return path for acknowledgements, but instead supports data repetition as a mechanism to protect against data loss. It fully supports the disaggregation of flows of binary objects of different priority, preventing head-of-line blocking impacting performance. The wire format of the protocol is designed to enable performant implementation in hardware or software, with the aim of enabling protocol implementations to run at the line-rate of the underlying link-layer protocol. This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes how Transport Layer Security (TLS) is used to secure QUIC. This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL version also includes security and extensibility mechanisms. This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC. Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks. RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) receiver to demultiplex Datagram Transport Layer Security (DTLS), Session Traversal Utilities for NAT (STUN), Secure Real-time Transport Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP), ZRTP, and Traversal Using Relays around NAT (TURN) channel packets arriving on a single port. This document updates RFC 7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a single receiving socket. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Informative References This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC and implementors of these application protocols. This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol that allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint": an endpoint that is registered on a single BP Node. The DTN Node ID is encoded both as a certificate Subject Alternative Name (SAN) identity of type otherName with an Other Name form of BundleEID and as an ACME Identifier type "bundleEID".