]> Nanjing University

jianhaoyu@smail.nju.edu.cn

Internet Delay/Disruption Tolerant Networking DTN Bundle Protocol IP edge network access gateway Delay- and disruption-tolerant networking (DTN) is used in environments with long propagation delay, constrained links, intermittent connectivity, and scheduled contacts. At the edge of such systems, local IP networks may exist, such as lunar surface networks, spacecraft internal networks, and edge computing networks. End systems in these IP edge networks may continue to use conventional IP stacks and may not process DTN-specific semantics such as endpoint identifiers, Bundle lifetimes, contact schedules, or DTN storage constraints. This document describes a DTN access gateway for IP edge networks. The gateway is placed at the boundary between an IP edge network and a DTN domain. It organizes authorized IP-side data into Bundle payloads, submits those payloads to the DTN side under controlled admission, and reflects DTN-side admission constraints back to IP edge senders through bounded pre-admission state and passive back-pressure. The main focus is edge-to-edge transit mode, in which a pair of gateways connects two IP edge networks across a DTN domain. This document also discusses an optional edge-to-DTN service access extension, in which selected IP-side requests are mapped, under local rules, to service transactions in the DTN domain. This document does not define a new BP extension block, convergence-layer protocol, Bundle payload encoding, routing protocol, contact-plan exchange protocol, or mandatory gateway implementation.

Introduction DTN provides store-and-forward communication for environments such as cislunar and Mars networks, where communication may be affected by long propagation delay, constrained links, intermittent connectivity, and scheduled contacts. BPv7 and the Licklider Transmission Protocol (LTP) are common parts of DTN protocol stacks. Not all systems attached to a DTN domain are themselves DTN endpoints. At the edge, there may be local IP networks with low delay and continuous connectivity, such as lunar surface networks, spacecraft internal networks, and edge computing networks. End systems in these networks may continue to use existing IP stacks, application interfaces, and local security mechanisms. They may not handle DTN endpoint identifiers (EIDs), Bundle lifetimes, contact plans, storage limits, or other DTN-specific semantics. This creates a boundary access problem. IP-side data streams and requests cannot be injected into a DTN domain as unbounded IP traffic. They need to be admitted at the boundary, organized into Bundle payloads, and paced according to DTN-side contacts, storage, link capacity, and admission state. This document describes a DTN access gateway for this boundary function. The gateway is deployed at the edge of a DTN domain. On the IP side, it acts as an authorized proxy or receiving function for local TCP or QUIC connections according to local policy. On the DTN side, it acts as a Bundle Protocol Agent (BPA), or uses BPA functionality, to submit and receive Bundles. This can reduce the need to make edge applications BP-native. The main operating case is edge-to-edge transit mode. In this mode, a pair of DTN access gateways connects two IP edge networks across a DTN backbone. The ingress gateway receives IP-side data units or logical flows, constructs Bundle payloads, and submits them into the DTN domain under controlled admission. The egress gateway receives delivered Bundles, recovers the carried data, and delivers it into the target IP edge network. This document also discusses an optional edge-to-DTN service access extension. The extension reuses the same IP-side control, Bundle construction, DTN-side admission, finite pre-admission state, and passive back-pressure mechanisms. It applies only when local service mapping rules are configured and the gateway is authorized to terminate or process the relevant IP-side connection. It is a rule-constrained service access mechanism, not a general application semantic translation framework. The gateway also reflects DTN-side constraints to the IP edge network. DTN domains may be limited by contact windows, storage capacity, link rate, and admission availability, which are usually not visible to IP-side end systems. The gateway limits the amount of data held before DTN-side admission and uses passive back-pressure to convey DTN-side constraints back to IP edge senders without defining new cross-domain back-pressure signaling. This document focuses on reference architecture, boundary processing, state and failure semantics, and security implications. It does not define a new convergence-layer protocol, Bundle payload encoding, routing protocol, contact-plan exchange protocol, service mapping rule format, or mandatory implementation behavior. This document is intended as Experimental and is not a Standards Track specification.

Terminology and Scope

Terminology This document uses the following terms:

DTN access gateway:

A boundary function between an IP edge network and a DTN domain. Under local authorization policy, it acts as an authorized proxy for IP-side TCP or QUIC connections. On the DTN side, it acts as a BPA, or uses BPA functionality, to submit and receive Bundles.

IP edge network:

A local IP network at the edge of a DTN system. Examples include a lunar surface network, a spacecraft internal network, and an edge computing network.

Edge-to-edge transit mode:

An operating case in which a pair of gateways connects two IP edge networks through a DTN domain. The ingress gateway organizes IP-side byte streams into Bundle payloads. The egress gateway recovers the byte streams and delivers them into the target IP edge network.

Edge-to-DTN service access extension:

An optional extension in which a gateway maps selected IP-side requests to DTN-side service transactions under local service mapping rules. The extension reuses the basic mechanisms of edge-to-edge transit mode.

Logical flow:

A gateway-internal abstraction of an admitted IP-side connection or data stream. A logical flow keeps the information needed to identify the flow and recover byte order.

Shared aggregation buffer:

A bounded gateway buffer shared by multiple logical flows before data is admitted into the DTN side as Bundle payloads.

Pre-admission control domain:

The state controlled by the gateway before DTN-side admission. It includes data authorized by IP-side flow control but not yet consumed by the gateway. It also includes data read by the gateway and stored in the shared aggregation buffer.

Passive back-pressure:

The feedback effect created by gateway read suspension, bounded pre-admission state, and IP-side transport flow control. It carries DTN-side service limits back to the IP edge sender without new cross-domain back-pressure signaling.

Payload subframing:

Gateway-local organization inside a Bundle payload. A pair of gateways uses it to distinguish logical flows and recover byte order. Payload subframing is not a BP extension block or convergence-layer frame.

Service mapping rule:

A local gateway rule that describes when an IP-side request can generate a DTN-side service transaction. The rule binds the target object, endpoint, service parameters, and response handling.

Relationship to the BPv7 Architecture A DTN access gateway is a boundary node that contains or invokes BPA functionality. On the IP edge side, it acts as a proxy or receiving function for local TCP or QUIC connections. On the DTN side, it uses BP services to construct, submit, and receive Bundles. The following figure shows the gateway position. The gateway is not a replacement for the BPA. It does not modify BP semantics. It uses BP service functions such as Bundle submission and delivery. The interface between the gateway application and the local DTN stack is deployment-specific and is outside the scope of this document. The gateway is complementary to DTN convergence layers. For example, TCPCL version 4 defines a TCP-based convergence layer for transferring Bundles between BPAs over an IP network. The gateway described here performs a higher-layer boundary function. It handles IP-side connections, multi-flow aggregation, contact-aware admission, and optional service mapping. A gateway can use TCPCL or any other configured convergence layer to communicate with a peer BPA.

Scope and Non-Goals This document discusses:

1. the reference architecture of a DTN access gateway;
2. boundary processing between IP-side data and DTN-side Bundle admission;
3. dynamic Bundle payload construction in edge-to-edge transit mode;
4. contact-aware admission and passive back-pressure;
5. finite gateway-controlled state before DTN-side admission;
6. a rule-constrained edge-to-DTN service access extension; and
7. security considerations introduced by this gateway function.

This document does not define:

1. a new BP extension block;
2. a new convergence-layer protocol;
3. a new Bundle payload encoding;
4. a new cross-domain signaling protocol;
5. a routing protocol;
6. a contact-plan exchange protocol;
7. a general application-layer semantic translation framework;
8. a data model, encoding, or distribution protocol for service mapping rules; or
9. changes to BP , BPSec , LTP , TCPCL , TLS , QUIC , or HTTP .

This document also does not modify CFDP.

Edge-to-Edge Transit Mode Edge-to-edge transit mode is used when two IP edge networks exchange data through a DTN domain. A pair of DTN access gateways is deployed at each side of the DTN domain. The ingress gateway acts as an authorized proxy for local IP-side connections and organizes their byte sequences into Bundle payloads. The egress gateway receives Bundles delivered through the DTN domain, recovers the data, and delivers it into the target IP edge network. This section describes the general boundary function. It does not define a specific application-over-BP encapsulation. It describes how a gateway handles IP-side connections, constructs Bundle payloads, controls DTN-side admission, and reflects DTN-side constraints to the IP edge side.

Reference Architecture and Trust Boundary The following figure shows the reference architecture for edge-to-edge transit mode. | DTN access GW | +------------------+ +------------------+ | | Bundles v +------------------+ | DTN backbone | +------------------+ | | Bundles v +------------------+ +------------------+ | Target IP edge | <---- | Egress gateway | | network | | DTN access GW | +------------------+ +------------------+ Figure 1: Edge-to-edge transit mode ]]> Connections from the source IP edge network can reach the ingress gateway through local routing, service discovery, proxy configuration, or other deployment-specific mechanisms. The ingress gateway acts as an authorized proxy for the source IP edge network. It converts ordered IP-side byte streams into Bundle payloads. After Bundles enter the DTN domain, they are handled by DTN store-and-forward processing, contact scheduling, and configured transport mechanisms. The egress gateway extracts payload data from delivered Bundles. It recovers the carried data units or byte streams and delivers them to service endpoints in the target IP edge network. The gateway is not a transparent forwarding device. It is an authorized boundary function. For protected IP-side connections, the gateway can parse requests or perform application-layer processing only when it has the required authorization and security context. Cases where the gateway is not authorized to terminate the relevant IP-side connection or access the information needed for gateway processing are outside the scope of this document. However, this trust model also limits what edge-to-edge transit mode provides. The mode can carry byte sequences generated by IP-side connections across a DTN domain through a pair of gateways. It does not transparently preserve the original TCP or QUIC session, original end-to-end security context, or application semantics.

Dynamic Bundle Payload Construction The ingress gateway converts IP-side data into Bundle payloads. IP edge networks can have short RTT and high local injection rate. The DTN backbone can be constrained by contacts, link capacity, storage, and forwarding opportunities. The gateway therefore performs controlled aggregation and admission before data enters the DTN side.

Logical-Flow Abstraction The ingress gateway represents each admitted IP-side connection as a logical flow. The logical flow is a gateway-internal abstraction. It maintains the flow identifier, byte ordering information, and state needed by the egress gateway. The number of concurrent logical flows is limited by local configuration. Connections beyond that limit can be delayed, blocked, or rejected according to local policy. This bounds the number of flows that can enter the pre-admission control domain.

Shared Aggregation Buffer The ingress gateway maintains a shared aggregation buffer between IP-side logical flows and the DTN-side submission interface. The buffer capacity is configured locally. Multiple logical flows share the buffer. The gateway does not need to reserve a fixed buffer for each connection. Readable flows can write data to the shared buffer. Idle or temporarily unreadable flows do not consume additional reserved space. When the shared aggregation buffer reaches its capacity limit, the gateway stops reading new data from IP-side connections. During this read suspension, data already in the buffer remains available for Bundle payload construction when admission conditions are met.

Gateway-Defined Payload Subframing When a Bundle payload carries bytes from multiple logical flows, the egress gateway needs to distinguish those flows and recover byte order. A pair of gateways can use gateway-defined payload subframing inside the Bundle payload for this purpose. A subframe needs to carry at least: The logical-flow identifier identifies a gateway-internal flow. The byte offset or sequence number supports ordering within that flow. The payload length identifies the fragment length. The payload bytes are the carried data. The logical-flow identifier is allocated locally or agreed by the paired gateways. It is not required to match an original TCP or QUIC connection identifier. Payload subframing is interpreted only by the paired gateways. It is not a BP extension block, convergence-layer frame, or DTN protocol structure. It is carried inside the Bundle payload and is transparent to BP processing.

Bundle Payload Assembly During an admission attempt, the ingress gateway extracts bytes from the shared aggregation buffer and assembles them into a Bundle payload. A Bundle payload can contain data from one or more logical flows. If one logical flow contributes adjacent fragments during the same cycle, the gateway can combine them into one subframe. Let S_k be the service bytes in the k-th Bundle payload. Let H_k be the subframing overhead. The admission size is: The gateway uses a configured maximum Bundle payload budget, B_max, to limit one admission: Here, B_max is the payload budget exposed by the gateway. It does not include BP internal overhead, convergence-layer overhead, or other DTN stack overhead. The gateway does not need to wait until the shared aggregation buffer is full before constructing a Bundle. As long as the admission conditions are satisfied, the gateway can extract the resident data from the buffer to construct a smaller Bundle payload. This behavior facilitates early progress during startup, small‑object transfer, or low‑load connections, while keeping the payload size admitted to the DTN side bounded.

Contact-Aware Bundle Admission The gateway does not pre-construct Bundle payloads for later admission. Bundle payload construction and DTN-side submission occur as one admission action. When the admission conditions are met, the gateway takes data from the shared aggregation buffer, assembles a Bundle payload, and submits it to the DTN side. The ingress gateway can make admission decisions based on DTN contact availability, DTN-side admission capacity, and local pacing. A Bundle payload is typically constructed and submitted when: Let chi(t) be a contact availability indicator. chi(t)=1 means that a serviceable DTN contact is available. chi(t)=0 means that no such contact is available. Let I_dtn(t) be a DTN-side admission indicator. I_dtn(t)=1 means that the DTN-side interface can accept a new Bundle payload. For the k-th Bundle payload, the contact, pacing, and DTN-side admission conditions can be described by: = T_wait(k-1) I_dtn(tau_k) = 1 ]]> Here, tau_k is the admission time of the k-th Bundle payload, and T_wait(k-1) is the waiting time after the previous admission. In addition to these conditions, the shared aggregation buffer is non-empty at admission time. One implementation strategy is two-boundary admission pacing. Let C_eff(t) be the estimated effective DTN-side service rate during a serviceable contact. For the k-th Bundle payload, the bandwidth-bound interval is: The gateway can also use a configured minimum admission interval, T_min, to avoid generating small Bundles too often in low-load or small-object cases. The waiting time can be: When backlog persists, Bundle payloads usually approach the configured payload budget. The bandwidth boundary then dominates. During startup, low-load periods, or small-object transfer, the minimum interval may dominate and reduce the small-Bundle generation rate. This pacing method is only an example. Other admission strategies can be used if they limit DTN-side admission rate and bound pre-admission state. The architectural point is that the gateway controls admission at the DTN boundary and avoids unbounded injection of IP-side data into the DTN domain.

Pre-Admission State Bound and Passive Back-Pressure Dynamic Bundle construction determines how IP-side bytes are assembled into Bundle payloads. The pre-admission control domain determines how much data the gateway can hold before DTN-side admission. Passive back-pressure reflects DTN-side service limits back to the IP edge sender without a new signaling protocol.

Finite Pre-Admission Control Domain The pre-admission control domain is the state controlled by the gateway before DTN-side admission. It includes:

• data authorized by IP-side flow control but not yet consumed by the gateway; and
• data read by the gateway and stored in the shared aggregation buffer.

Data already admitted to the DTN side is outside this control domain. It is managed by the DTN stack. The number of concurrent logical flows is bounded. Each logical flow also has a bounded flow-control budget. Therefore, the total amount of authorized but unconsumed IP-side data is bounded. Together with the shared aggregation buffer capacity, this gives a finite bound on data controlled by the gateway before DTN-side admission. Data already admitted to the DTN side but not yet released by the DTN stack is managed by that stack. It is not part of the pre-admission control process described here.

Establishing Passive Back-Pressure Passive back-pressure is created by the loop between DTN-side admission, finite gateway state, and IP-side transport flow control. When admission conditions are met, the gateway takes data from the shared aggregation buffer, constructs a Bundle payload, and submits it to the DTN side as one admission action. When the IP-side input rate is higher than the DTN-side admission rate, the shared aggregation buffer first absorbs the difference. As the buffer fills, the gateway stops reading from IP-side connections. Backlog then moves to the IP-side TCP or QUIC flow-control boundary. When remaining flow-control credit is consumed, the sender is limited by its existing transport flow-control mechanism. As a result, DTN-side contact loss, admission blocking, or service-rate reduction can be reflected back to the IP edge sender through gateway read suspension and IP-side flow control. This document defines no new cross-domain back-pressure signaling. DTN-side admission can be limited by two kinds of conditions. The first is gateway-side admission pacing. DTN-side interface availability alone is not sufficient for admission; the gateway may also enforce a configured admission interval. The second is DTN-side unavailability, such as no serviceable contact or no DTN-side admission capacity. During admission suspension, the pre-admission control domain can absorb only a finite amount of extra IP-side data. After that bound is reached, the gateway stops consuming more IP-side data. IP-side transport flow control then limits further injection. When contact availability or DTN-side admission availability returns, the gateway resumes Bundle construction and submission according to local policy.

Gateway-Controlled Boundary The gateway directly controls the data path only up to the DTN-side admission boundary. Before admission, it can limit active connections, constrain IP-side flow-control budgets, limit shared buffer occupancy, control Bundle payload size, and pace submission. After admission, data is handled by the DTN stack and configured DTN forwarding behavior. This separation matters when a high-rate IP edge network connects to a constrained DTN domain. The gateway uses finite pre-admission state and IP-side back-pressure to avoid becoming an unbounded cache. It also avoids unlimited injection from the IP edge side into the DTN domain. It does not modify the internal forwarding behavior of the DTN domain.

Contact-Plan Interaction The gateway does not generate, modify, or maintain the contact plan. It obtains current contact availability from the DTN stack or other deployment-specific mechanisms. When a serviceable contact is available, the gateway can perform Bundle construction and submission according to Section 3.2.5. When no serviceable contact is available, the gateway suspends new Bundle submission. IP-side backlog is then reflected through the passive back-pressure mechanism in Section 3.3.2. The gateway does not expose the contact plan directly to IP edge end systems. IP edge end systems can interact with the gateway without understanding the DTN contact plan.

Delivery Considerations After the ingress gateway submits a Bundle to the DTN side, retention, forwarding, retransmission, expiration, and delivery-status handling are performed by the DTN stack and configured DTN mechanisms. This document does not define any new retention, retransmission, custody-transfer, or delivery-guarantee mechanism for admitted Bundles. If a Bundle is not delivered because it expires, no route is available, no return path exists, or another DTN-side failure occurs, the gateway may learn about the failure through Bundle status reports, return Bundles, or deployment-specific feedback paths. How the gateway handles such failures is a matter of local policy and is not specified here.

Optional Edge-to-DTN Service Access Extension The edge-to-DTN service access extension is used when an IP edge network accesses service endpoints within the DTN domain. In this extension, the target is not another IP edge network. The target is a DTN-side endpoint that can execute a selected service transaction. This extension is optional and is not required for the edge-to-edge transit mode described in Section 3. It reuses the same gateway mechanisms: IP-side authorization and control, Bundle construction, DTN-side admission, finite pre-admission state, and passive back-pressure. The difference is the interpretation of admitted data. In edge-to-edge transit mode, a paired egress gateway recovers Bundle payload data and delivers it into a target IP edge network. In the service access extension, local rules map selected IP-side requests to DTN-side service transactions. A paired egress gateway is not required. The following figure shows the basic form of the extension. | | +------------------+ +------------------+ | | Bundles v +------------------+ | DTN Backbone | | +--------------+ | | | Service | | | | Endpoint(s) | | | +--------------+ | +------------------+ Figure 2: Edge-to-DTN service access extension ]]> The gateway can perform service mapping only when it is authorized to terminate or process the relevant IP-side connection. If the IP-side connection is protected by TLS or QUIC security, the gateway needs the required authorization and security context before it can parse the request or perform mapping. Otherwise, the request cannot be mapped by this extension.

Rule-Constrained Service Mapping Service mapping is driven by local configuration. A service mapping rule describes when a class of IP-side requests can generate a DTN-side service transaction. This document discusses the information such rules need to express. It does not define a rule data model, rule encoding, or rule distribution protocol. A service mapping rule can include:

• the supported source-side protocol, method, or service entry point;
• the binding from a source-side object name to a DTN-side object or service endpoint;
• the target DTN endpoint identifier or service endpoint;
• the target service type and transaction parameters;
• Bundle lifetime, priority, and status-handling policy; and
• local failure handling and response recovery behavior.

Before generating a DTN-side service transaction, the gateway determines whether:

1. the request can be parsed within the authorized security context;
2. the request matches a local service mapping rule;
3. the target object can be bound;
4. the target service is available for the requested operation; and
5. required attributes can be preserved, explicitly degraded, rejected, or locally compensated.

If these conditions are not satisfied, the gateway returns a local error on the source side. This avoids consuming DTN backbone resources for requests that cannot be executed. Service mapping can take different forms. In transport adaptation, the application protocol remains the same, but transport changes from an IP-side transport to BP delivery in the DTN domain. This form assumes that an application-over-BP encapsulation exists or is defined elsewhere, and that the target DTN-side endpoint supports the corresponding application protocol. HTTP-over-BP is one possible related case , but this document does not define or replace such an encapsulation. In native service mapping, the gateway maps an IP-side request to a DTN-side service transaction with different native semantics. For example, a configured rule could interpret an authorized source-side retrieve request as a DTN-side file or object retrieval transaction. This document does not define HTTP-to-CFDP mapping, CFDP proxy behavior, or any CFDP transaction profile.

Response Recovery and Failure Boundary The service access extension needs to distinguish local mapping failures from DTN-side or target-side failures. Local mapping failures include request parsing failure, rule mismatch, object binding failure, and policy rejection. These failures occur before DTN-side admission. They do not generate a target DTN service transaction and do not consume DTN backbone resources. The gateway returns an error through the source-side protocol. Failures after DTN-side admission are DTN-side or target-side failures. They can include Bundle expiration, target service rejection, target transaction failure, or lack of a return path. The gateway may learn about these failures through status reports, return Bundles, or deployment-specific feedback paths. When a target transaction succeeds, the gateway can generate a successful source-side response if the source-side protocol can represent the result. When a target transaction fails, the gateway maps the failure to an explicit source-side error. For source-side protocols with connection lifetime limits, the source-side connection may close or time out before the DTN transaction completes. In that case, the gateway can cancel the wait, cache the result, return a timeout error, or make the result available through a deployment-specific asynchronous retrieval mechanism.

Scope and Limits of the Extension The edge-to-DTN service access extension describes rule-driven, capability-constrained, rejectable, and recoverable gateway-side mapping. It is not a general application semantic translation framework. The extension does not require DTN-side services to understand HTTP, TCP, QUIC, or other IP application semantics. It also does not assume that arbitrary IP application requests can be converted into DTN service transactions. If there is no valid mapping rule, if the target object cannot be bound, if required attributes cannot be preserved or explicitly handled, or if the result cannot be recovered, the request is expected to fail locally or return an explicit source-side error rather than generating a DTN service transaction.

Security Considerations The DTN access gateway is placed between an IP edge network and a DTN domain. It can terminate authorized IP-side connections, construct Bundle payloads, generate DTN-side service transactions for IP-side requests, and perform local service mapping and response recovery. The gateway therefore creates a trust boundary and a state boundary. This document does not define new cryptographic mechanisms. It does not replace BP , BPSec , TLS , QUIC , TCPCL , or convergence-layer security mechanisms. This section discusses security considerations introduced by the gateway architecture.

Gateway Trust Boundary The gateway is not a transparent forwarding device. It is an authorized boundary function. If the gateway terminates an IP-side connection, security semantics are segmented at the gateway. Deployments need to decide which connections the gateway can terminate, which application content it can inspect, and when it can generate Bundles or service transactions for IP-side entities. A compromised gateway can forge IP-side requests, modify Bundle payloads, bind requests to wrong target EIDs, or access DTN-side services without authorization. The gateway therefore needs protection appropriate to a component at a DTN trust boundary. Relevant protections include authentication, authorization, key management, access control, audit logging, and operational monitoring.

Identity and Authorization Mapping IP-side identity is not automatically equivalent to DTN-side identity. IP addresses, TLS client identity, HTTP Authorization information, local accounts, DTN EIDs, and DTN service permissions do not have a natural one-to-one mapping. When the gateway constructs Bundles or service transactions for IP-side connections, it needs a local policy that binds source identity, target EID, service permission, and allowed operations. In the service access extension, incorrect identity mapping or object binding can cause unauthorized access, unintended service invocation, or data disclosure. Service mapping rules need to constrain accessible target objects, service endpoints, and operations. If authorization, target binding, or required attributes cannot be determined, the request is expected to fail locally rather than being silently mapped to a DTN service transaction.

Applicability of BPSec BPSec provides integrity protection through the Block Integrity Block (BIB) and confidentiality protection through the Block Confidentiality Block (BCB). In this gateway architecture, BPSec applicability depends on the gateway role in Bundle construction and payload processing. The gateway can act as the BPSec security source for Bundles that it constructs. It can apply BIB protection to provide integrity protection for the Bundle payload in the DTN domain. If confidentiality is required, it can apply BCB protection to the Bundle payload. In edge-to-edge transit mode, BPSec protection is typically configured so that the egress gateway, or the security domain represented by that gateway, can verify integrity protection or decrypt protected payloads. In the service access extension, the corresponding processing entity is typically the DTN-side service endpoint or its security domain. If the IP-side connection uses TLS over TCP or QUIC for IP-side security, BPSec protects a different security segment. Deployments need to define the trust assumptions, responsible parties, and protection scope for each segment. This document does not specify a BPSec configuration. Deployments select BPSec policies according to their threat model, contact characteristics, resource constraints, and operational requirements.

Bundle Payload and Subframing Protection In edge-to-edge transit mode, the Bundle payload can contain gateway-defined payload subframing. The logical-flow identifier, byte offset, length field, and payload bytes can affect demultiplexing and byte-order recovery at the egress gateway. If these fields are modified, the result can be incorrect demultiplexing, out-of-order release, flow confusion, or data injection. Bundle payloads that carry subframing information therefore need integrity protection appropriate to the deployment risk. If the payload contains sensitive data, object names, or access context, confidentiality protection also needs to be considered. Such protection can be provided by BPSec, convergence-layer security, or other deployment-specific mechanisms. This document does not define a new payload protection format.

Resource Exhaustion and Admission Control An IP edge network can have short RTT and high local injection rate. A DTN domain can be constrained by contacts, link rate, and storage capacity. A malicious or misconfigured IP-side entity can try to exhaust gateway resources or DTN-side admission capacity by opening many connections, sending at high rate, generating many small objects, or submitting requests that cannot be executed. The mechanisms in Section 3 also have security relevance. The logical-flow concurrency limit, shared aggregation buffer, Bundle payload budget, contact-aware admission, and finite pre-admission state limit how much data the gateway holds before DTN-side admission. They also allow DTN-side unavailability or admission blocking to be reflected to the IP edge sender through transport flow control. Deployments need to configure these limits according to link capacity, contact schedules, storage resources, and service policy. Otherwise, the gateway can become an unbounded buffer or a resource exhaustion point.

Service Mapping and Response Recovery Risks The service access extension applies only to configured service classes. Incorrect mapping rules, silent degradation of required attributes, incorrect object binding, or incorrect response recovery can cause wrong service invocation or misleading responses. When the gateway cannot preserve required attributes, bind the target object, or recover a meaningful source-side response, it needs to return an explicit error rather than generating a semantically uncertain success response. Long delay and asynchronous delivery in DTN environments also create request-response binding risks. A source-side connection may have closed or timed out before the target DTN transaction completes. The gateway needs a local policy for delayed results, duplicate results, and expired results, so that old results are not incorrectly bound to new source-side requests. Deployments that use service mapping should log mapping decisions, rejection reasons, target EIDs, Bundle admission state, and failure categories. Such logging supports audit, troubleshooting, and incident analysis.

IANA Considerations This document makes no IANA requests.

References Normative References 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. Informative References This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). 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 describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. 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 describes how Transport Layer Security (TLS) is used to secure QUIC. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document describes the encapsulation of HTTP requests and responses in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications.

Acknowledgements TBD.