• the abbreviation "BP" without the version suffix refers to BPv7.
• the abbreviation "TCPCL" without the version suffix refers to TCPCLv4.

+-------------------------+
|     DTN Application     | -\
+-------------------------|   |
|  Bundle Protocol (BP)   |   -> Application Layer
+-------------------------+   |
| TCP Conv. Layer (TCPCL) |   |
+-------------------------+   |
|     TLS (optional)      | -/
+-------------------------+
|          TCP            | ---> Transport Layer
+-------------------------+
|       IPv4/IPv6         | ---> Network Layer
+-------------------------+
|   Link-Layer Protocol   | ---> Link Layer
+-------------------------+

• The format of protocol data units of the Bundle Protocol, as those are defined elsewhere in [RFC 9171].This includes the concept of bundle fragmentation or bundle encapsulation.The TCPCL transfers bundles as opaque data blocks.
• Mechanisms for locating or identifying other bundle entities (peers) within a network or across an internet.The mapping of a node ID to a potential convergence layer (CL) protocol and network address is left to implementation and configuration of the BP Agent (BPA) and its various potential routing strategies, as is the mapping of a DNS name and/or address to a choice of an end-entity certificate to authenticate a node to its peers.
• Logic for routing bundles along a path toward a bundle's endpoint.This CL protocol is involved only in transporting bundles between adjacent entities in a routing sequence.
• Policies or mechanisms for issuing Public Key Infrastructure Using X.509 (PKIX) certificates; provisioning, deploying, or accessing certificates and private keys; deploying or accessing certificate revocation lists (CRLs); or configuring security parameters on an individual entity or across a network.
• Uses of TLS that are not based on PKIX certificate authentication (see Section 7.12.2) or in which authentication of both entities is not possible (see Section 7.12.1).

Network Byte Order:

Here, "network byte order" means most significant byte first, a.k.a. big endian.All of the integer encodings in this protocol SHALL be transmitted in network byte order.

TCPCL Entity:

This is the notional TCPCL application that initiates TCPCL sessions. This design, implementation, configuration, and specific behavior of such an entity is outside of the scope of this document. However, the concept of an entity has utility within the scope of this document as the container and initiator of TCPCL sessions. The relationship between a TCPCL entity and TCPCL sessions is defined as follows:

• A TCPCL entity MAY actively initiate any number of TCPCL sessions and should do so whenever the entity is the initial transmitter of information to another entity in the network.
• A TCPCL entity MAY support zero or more passive listening elements that listen for connection requests from other TCPCL entities operating on other entities in the network.
• A TCPCL entity MAY passively initiate any number of TCPCL sessions from requests received by its passive listening element(s) if the entity uses such elements.

These relationships are illustrated in Figure 2. For most TCPCL behavior within a session, the two entities are symmetric and there is no protocol distinction between them. Some specific behavior, particularly during session establishment, distinguishes between the active entity and the passive entity. For the remainder of this document, the term "entity" without the prefix "TCPCL" refers to a TCPCL entity.

TCP Connection:

The term "connection" in this specification exclusively refers to a TCP connection and any and all behaviors, sessions, and other states associated with that TCP connection.

TCPCL Session:

A TCPCL session (as opposed to a TCP connection) is a TCPCL communication relationship between two TCPCL entities.A TCPCL session operates within a single underlying TCP connection, and the lifetime of a TCPCL session is bound to the lifetime of that TCP connection.A TCPCL session is terminated when the TCP connection ends, due to either (1) one or both entities actively closing the TCP connection or (2) network errors causing a failure of the TCP connection.Within a single TCPCL session, there are two possible transfer streams: one in each direction, with one stream from each entity being the outbound stream and the other being the inbound stream (see Figure 3).From the perspective of a TCPCL session, the two transfer streams do not logically interact with each other.The streams do operate over the same TCP connection and between the same BPAs, so there are logical relationships at those layers (message and bundle interleaving, respectively).For the remainder of this document, the term "session" without the prefix "TCPCL" refers to a TCPCL session.

Session Parameters:

These are a set of values used to affect the operation of the TCPCL for a given session.The manner in which these parameters are conveyed to the bundle entity and thereby to the TCPCL is implementation dependent.However, the mechanism by which two entities exchange and negotiate the values to be used for a given session is described in Section 4.3.

Transfer Stream:

A transfer stream is a unidirectional user-data path within a TCPCL session.Transfers sent over a transfer stream are serialized, meaning that one transfer must complete its transmission prior to another transfer being started over the same transfer stream.At the stream layer, there is no logical relationship between transfers in that stream; it's only within the BPA that transfers are fully decoded as bundles.Each unidirectional stream has a single sender entity and a single receiver entity.

Transfer:

This refers to the procedures and mechanisms for conveyance of an individual bundle from one node to another.Each transfer within the TCPCL is identified by a Transfer ID number, which is guaranteed to be unique only to a single direction within a single session.

Transfer Segment:

A transfer segment is a subset of a transfer of user data being communicated over a transfer stream.

Idle Session:

A TCPCL session is idle while there is no transmission in progress in either direction.While idle, the only messages being transmitted or received are KEEPALIVE messages.

Live Session:

A TCPCL session is live while there is a transmission in progress in either direction.

Reason Codes:

The TCPCL uses numeric codes to encode specific reasons for individual failure/error message types.

+--------------------------------------------+
|                 TCPCL Entity               |
|                                            |      +----------------+
|   +--------------------------------+       |      |                |-+
|   | Actively Initiated Session #1  +------------->| Other          | |
|   +--------------------------------+       |      | TCPCL Entity's | |
|                  ...                       |      | Passive        | |
|   +--------------------------------+       |      | Listener       | |
|   | Actively Initiated Session #n  +------------->|                | |
|   +--------------------------------+       |      +----------------+ |
|                                            |       +-----------------+
|      +---------------------------+         |
|  +---| +---------------------------+       |      +----------------+
|  |   | | Optional Passive          |       |      |                |-+
|  |   +-| Listener(s)               +<-------------+                | |
|  |     +---------------------------+       |      |                | |
|  |                                         |      | Other          | |
|  |    +---------------------------------+  |      | TCPCL Entity's | |
|  +--->| Passively Initiated Session #1  +-------->| Active         | |
|  |    +---------------------------------+  |      | Initiator(s)   | |
|  |                                         |      |                | |
|  |    +---------------------------------+  |      |                | |
|  +--->| Passively Initiated Session #n  +-------->|                | |
|       +---------------------------------+  |      +----------------+ |
|                                            |       +-----------------+
+--------------------------------------------+

+---------------------------+              +---------------------------+
|    "Own" TCPCL Session    |              |   "Other" TCPCL Session   |
|                           |              |                           |
| +----------------------+  |              |  +----------------------+ |
| |   TCP Connection     |  |              |  |    TCP Connection    | |
| |                      |  |              |  |                      | |
| | +-----------------+  |  |   Messages   |  |  +-----------------+ | |
| | |   Own Inbound   |  +--------------------+  |  Peer Outbound  | | |
| | | Transfer Stream |                          | Transfer Stream | | |
| | |       -----     |<---[Seg]--[Seg]--[Seg]---|       -----     | | |
| | |     RECEIVER    |---[Ack]----[Ack]-------->|      SENDER     | | |
| | +-----------------+                          +-----------------+ | |
| |                                                                  | |
| | +-----------------+                          +-----------------+ | |
| | | Own Outbound    |-------[Seg]---[Seg]----->|  Peer Inbound   | | |
| | | Transfer Stream |<---[Ack]----[Ack]-[Ack]--| Transfer Stream | | |
| | |       -----     |                          |       -----     | | |
| | |      SENDER     |   +--------------------+ |     RECEIVER    | | |
| | +-----------------+   |  |              |  | +-----------------+ | |
| +-----------------------+  |              |  +---------------------+ |
+----------------------------+              +--------------------------+

Attempt Session:

The TCPCL allows a BPA to preemptively attempt to establish a TCPCL session with a peer entity.Each session attempt can send a different set of session negotiation parameters as directed by the BPA.

Terminate Session:

The TCPCL allows a BPA to preemptively terminate an established TCPCL session with a peer entity.The terminate request is done on a per-session basis.

Session State Changed:

The TCPCL entity indicates to the BPA when the session state changes. The top-level session states indicated are as follows:

Connecting:

A TCP connection is being established. This state only applies to the active entity.

Contact Negotiating:

A TCP connection has been made (as either the active or passive entity), and contact negotiation has begun.

Session Negotiating:

Contact negotiation has been completed (including possible TLS use), and session negotiation has begun.

Established:

The session has been fully established and is ready for its first transfer.When the session is established, the peer node ID (along with an indication of whether or not it was authenticated) and the negotiated session parameters (see Section 4.7) are also communicated to the BPA.

Ending:

The entity sent a SESS_TERM message and is in the Ending state.

Terminated:

The session has finished normal termination sequencing.

Failed:

The session ended without normal termination sequencing.

Session Idle Changed:

The TCPCL entity indicates 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 either transfer stream; the session transitions from Live to Idle at the end of a transfer when the other transfer stream does not have an ongoing transfer.Because the TCPCL transmits serially over a TCP connection, it suffers from "head-of-queue blocking", so a transfer in either direction can block an immediate start of a new transfer in the session.

Begin Transmission:

The principal purpose of the TCPCL is to allow a BPA to transmit bundle data over an established TCPCL session.Transmission requests are done on a per-session basis, and the CL does not necessarily perform any per-session or inter-session queueing.Any queueing of transmissions is the obligation of the BPA.

Transmission Success:

The TCPCL entity indicates to the BPA when a bundle has been fully transferred to a peer entity.

Transmission Intermediate Progress:

The TCPCL entity indicates to the BPA the intermediate progress of a transfer to a peer entity.This intermediate progress is at the granularity of each transferred segment.

Transmission Failure:

The TCPCL entity indicates to the BPA certain reasons for bundle transmission failure, notably when the peer entity rejects the bundle or when a TCPCL session ends before transfer success.The TCPCL itself does not have a notion of transfer timeout.

Reception Initialized:

The TCPCL entity indicates this status to the receiving BPA just before any transmission data is sent.This corresponds to reception of the XFER_SEGMENT message with the START flag set to 1.

Interrupt Reception:

The TCPCL entity allows a BPA to interrupt an individual transfer before it has fully completed (successfully or not).Interruption can occur any time after the reception is initialized.

Reception Success:

The TCPCL entity indicates to the BPA when a bundle has been fully transferred from a peer entity.

Reception Intermediate Progress:

The TCPCL entity indicates to the BPA 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:

The TCPCL entity indicates to the BPA certain reasons for reception failure, notably when the local entity rejects an attempted transfer for some local policy reason or when a TCPCL session ends before transfer success.The TCPCL itself does not have a notion of transfer timeout.

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

• Session "Live" means transmitting or receiving over a transfer stream.
• Session "Idle" means no transmission/reception over a transfer stream.
• Session "Ending" means no new transfers will be allowed.

+-------+
| START |
+-------+
    |
TCP Connecting
    V
+-----------+
|    TCP    |            +---------+
| Connected |--Send CH-->| Waiting |--Timeout-->[TCPCLOSE]
+-----------+            +---------+
                              |
                          Received CH
                              V
                            [PCH]

+-----------+             +---------+
|   TCP     |--Wait for-->| Waiting |--Timeout-->[TCPCLOSE]
| Connected |     CH      +---------+
+-----------+                  |
                          Received CH
                               V
                       +-----------------+
                       | Preparing reply |--Send CH-->[PCH]
                       +-----------------+

+-----------+
|  Peer CH  |
| available |
+-----------+
      |
 Validate and
  Negotiate
      V
 +------------+
 | Negotiated |--Failure-->[TCPCLOSE]
 +------------+
    |       |
  No TLS    +----Negotiate---+      [ST]
    |               TLS      |       ^
    V                        |    Failure
  +-----------+              V       |
  |   TCPCL   |            +---------------+
  | Messaging |<--Success--| TLS Handshake |
  | Available |            +---------------+
  +-----------+

+-----------+
|   TCPCL   |                   +---------+
| Messaging |--Send SESS_INIT-->| Waiting |--Timeout-->[ST]
| Available |                   +---------+
+-----------+                       |
                            Received SESS_INIT
                                    |
                                    V
                                  [PSI]

+-----------+
|   TCPCL   |                  +---------+
| Messaging |----Wait for ---->| Waiting |--Timeout-->[ST]
| Available |    SESS_INIT     +---------+
+-----------+                       |
                            Received SESS_INIT
                                    |
                            +-----------------+
                            | Preparing reply |--Send SESS_INIT-->[PSI]
                            +-----------------+

+----------------+
| Peer SESS_INIT |
|   available    |
+----------------+
        |
   Validate and
    Negotiate
        V
   +------------+
   | Negotiated |---Failure--->[ST]
   +------------+
        |
     Success
        V
  +--------------+
  | Established  |
  | Session Idle |
  +--------------+

                                       +--Send XFER_SEGMENT--+
+--------+                             |                     |
| Stream |                       +-------------+             |
|  Idle  |---Send XFER_SEGMENT-->| In Progress |<------------+
+--------+                       +-------------+
                                       |
     +---------All segments sent-------+
     |
     V
+---------+                       +--------+
| Waiting |---- Receive Final---->| Stream |
| for Ack |       XFER_ACK        |  Idle  |
+---------+                       +--------+

                                         +-Receive XFER_SEGMENT-+
+--------+                               |    Send XFER_ACK     |
| Stream |                         +-------------+              |
|  Idle  |--Receive XFER_SEGMENT-->| In Progress |<-------------+
+--------+                         +-------------+
                                         |
     +--------Sent Final XFER_ACK--------+
     |
     V
+--------+
| Stream |
|  Idle  |
+--------+

+-----------+                   +---------+
|  Session  |--Send SESS_TERM-->| Session |
| Live/Idle |                   | Ending  |
+-----------+                   +---------+

+-----------+                   +---------+
|  Session  |--Send SESS_TERM-->| Session |
| Live/Idle |                   | Ending  |
+-----------+<------+           +---------+
      |             |
 Receive SESS_TERM  |
      |             |
      +-------------+

DTN-Aware CAs:

In the ideal case, the CA or CAs issuing certificates for TCPCL entities are aware of the end use of the certificate, have a mechanism for verifying ownership of a node ID, and are issuing certificates directly for that node ID.In this environment, the ability to authenticate a peer entity node ID directly avoids the need to authenticate a network name or address and then implicitly trust the node ID of the peer.The TCPCL authenticates the node ID whenever possible; this is preferred over lower-level PKIX identities.

DTN-Ignorant CAs:

It is expected that Internet-scale "public" CAs will continue to focus on DNS names as the preferred PKIX identifier.There are large infrastructures already in place for managing network-level authentication and protocols to manage identity verification in those environments [RFC 8555].The TCPCL allows for this type of environment by authenticating a lower-level identifier for a peer and requiring the entity to trust that the node ID given by the peer (during session initialization) is valid.This situation is not ideal, as it allows the vulnerabilities described in Section 7.9, but it still provides some amount of mutual authentication to take place for a TCPCL session.

Persistent Session:

This policy preemptively establishes a single session to known entities in the network and keeps the session active using KEEPALIVEs.Benefits of this policy include reducing the total amount of TCP data that needs to be exchanged for a set of transfers (assuming that the KEEPALIVE size is significantly smaller than the transfer size) and allowing the session state to indicate peer connectivity.Drawbacks include wasted network resources when a session is mostly idle or when network connectivity is inconsistent (which requires that failed sessions be reestablished), and potential queueing issues when multiple transfers are requested simultaneously.This policy assumes that there is agreement between pairs of entities as to which of the peers will initiate sessions; if there is no such agreement, there is potential for duplicate sessions to be established between peers.

Ephemeral Sessions:

This policy only establishes a session when an outgoing transfer needs to be sent.Benefits of this policy include not wasting network resources on sessions that are idle for long periods of time and avoiding potential queueing issues as can be seen when using a single persistent session. Drawbacks include the TCP and TLS overhead of establishing a new session for each transfer.This policy assumes that each entity can function in a passive role to listen for session requests from any peer that needs to send a transfer; when that is not the case, the polling behavior discussed below needs to happen.This policy can be augmented to keep the session established as long as any transfers are queued.

Active-Only Polling Sessions:

When naming and/or addressing of one entity is variable (i.e., a dynamically assigned IP address or domain name) or when firewall or routing rules prevent incoming TCP connections, that entity can only function in the active role.In these cases, sessions also need to be established when an incoming transfer is expected from a peer or based on a periodic schedule.This polling behavior causes inefficiencies compared to as-needed ephemeral sessions.

Minimum Overhead:

For a simple network expected to exchange relatively small bundles, the Segment MRU can be set to be identical to the Transfer MRU, which indicates that all transfers can be sent with a single data segment (i.e., no actual segmentation).If the network is closed and all transmitters are known to follow a single-segment transfer policy, then receivers can avoid the necessity of segment reassembly.Because this CL operates over a TCP stream, which suffers from a form of head-of-queue blocking between messages, while one entity is transmitting a single XFER_SEGMENT message it is not able to transmit any XFER_ACK or XFER_REFUSE messages for any associated received transfers.

Predictable Message Sizing:

In situations where the maximum message size is desired to be well controlled, the Segment MRU can be set to the largest acceptable size (the message size less the XFER_SEGMENT header size) and transmitters can always segment a transfer into maximum-size chunks no larger than the Segment MRU.This guarantees that any single XFER_SEGMENT will not monopolize the TCP stream for too long, which would prevent outgoing XFER_ACK and XFER_REFUSE messages associated with received transfers.

Dynamic Segmentation:

Even after negotiation of a Segment MRU for each receiving entity, the actual transfer segmentation only needs to guarantee that any individual segment is no larger than that MRU.In a situation where TCP throughput is dynamic, the transfer segmentation size can also be dynamic in order to control message transmission duration.

                     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
+---------------+---------------+---------------+---------------+
|                          magic='dtn!'                         |
+---------------+---------------+---------------+---------------+
|     Version   |   Flags       |
+---------------+---------------+

magic:

A four-octet field that always contains the octet sequence 0x64 0x74 0x6E 0x21, i.e., the text string "dtn!" in US-ASCII (and UTF-8).

Version:

A one-octet field value containing the value 4 (current version of the TCPCL protocol).

Flags:

A one-octet field of single-bit flags, interpreted according to the descriptions in Table 1.All reserved header flag bits SHALL be set to 0 by the sender.All reserved header flag bits SHALL be ignored by the receiver.

TCPCL Version:

Both Contact Headers of a successful contact negotiation have identical TCPCL version numbers as described above.Only upon response of a Contact Header from the passive entity is the TCPCL protocol version established and session negotiation begun.

Enable TLS:

Negotiation of the Enable TLS parameter is performed by taking the logical AND of the two Contact Headers' CAN_TLS flags. A local security policy is then applied to determine whether the negotiated value of Enable TLS is acceptable. A reasonable security policy would require or disallow the use of TLS, depending upon the desired network flows. The RECOMMENDED policy is to require TLS for all sessions, even if security policy does not allow or require authentication. Because this state is negotiated over an unsecured medium, there is a risk of TLS Stripping as described in Section 7.4.

If the Enable TLS state is unacceptable, the entity SHALL terminate the session with a reason code of "Contact Failure". Note that this "Contact Failure" reason is different than a failure of a TLS handshake or TLS authentication after an agreed-upon and acceptable Enable TLS state. If the negotiated Enable TLS value is "true" and acceptable, then the TLS negotiation feature described in Section 4.4 begins immediately following the Contact Header exchange.

Node ID:

The ideal certificate identity is the node ID of the entity using the NODE-ID, as defined below.When the node ID is identified, there is no need for any lower-level identification to be present (though it can still be present, and if so it is also validated).

DNS Name:

If CA policy forbids a certificate to contain an arbitrary NODE-ID but allows a DNS-ID to be identified, then one or more stable DNS names can be identified in the certificate.The use of wildcard DNS-IDs is discouraged due to the complex rules for matching and dependence on implementation support for wildcard matching (see Section 6.4.3 of RFC 6125).

Network Address:

If no stable DNS name is available but a stable network address is available and CA policy allows a certificate to contain an IPADDR-ID (as defined below), then one or more network addresses can be identified in the certificate.

ClientHello:

When a resolved DNS name was used to establish the TCP connection, the TLS ClientHello SHOULD include a "server_name" extension in accordance with [RFC 6066]. When present, the server_name extension SHALL contain a "HostName" value taken from the DNS name (of the passive entity) that was resolved.

Server Certificate:

The passive entity SHALL supply a certificate within the TLS handshake to allow authentication of its side of the session.The supplied end-entity certificate SHALL conform to the profile described in Section 4.4.2.The passive entity MAY use the SNI DNS name to choose an appropriate server-side certificate that authenticates that DNS name.

Certificate Request:

During the TLS handshake, the passive entity SHALL request a client-side certificate.

Client Certificate:

The active entity SHALL supply a certificate chain within the TLS handshake to allow authentication of its side of the session.The supplied end-entity certificate SHALL conform to the profile described in Section 4.4.2.

1. Validating the certification path from the end-entity certificate up to a trusted root CA.
2. Validating the EKU and other properties of the end-entity certificate.
3. Authenticating identities from a valid end-entity certificate.
4. Applying security policy to the result of each identity type authentication.

Absent:

Indicating that no such claims are present in the certificate and the identity cannot be authenticated.

Success:

Indicating that one or more such claims are present and at least one matches the peer identity value.

Failure:

Indicating that one or more such claims are present and none match the peer identity.

• If the active entity resolved a DNS name (of the passive entity) in order to initiate the TCP connection, that DNS name SHALL be used as a DNS-ID reference identifier.
• The IP address of the other side of the TCP connection SHALL be used as an IPADDR-ID reference identifier.

• enabling the use of OCSP checking during the TLS handshake.
• instructing that, if an EKU extension is present, the extension needs to contain id-kp-bundleSecurity (Section 4.4.2.1) to be usable with TCPCL security.
• requiring a validated node ID (Section 4.4.4.3) and ignoring any network-level identifier (Section 4.4.4.2).

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

Message Type:

Indicates the type of the message as per Table 2 below.Encoded values are listed in Section 8.5.

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

Keepalive Interval:

A 16-bit unsigned integer indicating the minimum interval, in seconds, to negotiate as the Session Keepalive using the method described in Section 4.7.

Segment MRU:

A 64-bit unsigned integer indicating the largest allowable single-segment data payload size to be received in this session.Any XFER_SEGMENT sent to this peer SHALL have a data payload no longer than the peer's Segment MRU.The two entities of a single session MAY have different Segment MRUs, and no relationship between the two is required.

Transfer MRU:

A 64-bit unsigned integer indicating the largest allowable total-bundle data size to be received in this session.Any bundle transfer sent to this peer SHALL have a Total Bundle Length payload no longer than the peer's Transfer MRU.This value can be used to perform proactive bundle fragmentation.The two entities of a single session MAY have different Transfer MRUs, and no relationship between the two is required.

Node ID Length and Node ID Data:

Together, these fields represent a variable-length text string.The Node ID Length is a 16-bit unsigned integer indicating the number of octets of Node ID Data to follow.A zero-length node ID SHALL be used to indicate the lack of a node ID rather than a truly empty node ID.This case allows an entity to avoid exposing node ID information on an untrusted network.A non-zero-length Node ID Data SHALL contain the UTF-8 encoded node ID of the entity that sent the SESS_INIT message.Every node ID SHALL be a URI consistent with the requirements in [RFC 3986] and the URI schemes of the IANA "Bundle Protocol URI Scheme Types" registry [IANA-BUNDLE].The node ID itself can be authenticated as described in Section 4.4.4.

Session Extension Items Length and Session Extension Items list:

- Together, these fields represent protocol extension data not defined by this specification.The Session Extension Items Length is the total number of octets to follow that are used to encode the Session Extension Items list. The encoding of each Session Extension Item is within a consistent data container as described in Section 4.8.The full set of Session Extension Items apply for the duration of the TCPCL session to follow.The order and multiplicity of these Session Extension Items are significant, as defined in the associated type specification(s).If the content of the Session Extension Items list disagrees with the Session Extension Items Length (e.g., the last item claims to use more or fewer octets than are indicated in the Session Extension Items Length), the reception of the SESS_INIT is considered to have failed.

Transfer MTU and Segment MTU:

The Maximum Transmission Unit (MTU) for whole transfers and individual segments is identical to the Transfer MRU and Segment MRU, respectively, of the received SESS_INIT message. A transmitting peer can send individual segments with any size smaller than the Segment MTU, depending on local policy, dynamic network conditions, etc.Determining the size of each transmitted segment is an implementation matter.If either the Transfer MRU or Segment MRU is unacceptable, the entity SHALL terminate the session with a reason code of "Contact Failure".

Session Keepalive:

Negotiation of the Session Keepalive parameter is performed by taking the minimum of the two Keepalive Interval values from the two SESS_INIT messages. The Session Keepalive Interval is a parameter for the behavior described in Section 5.1.1. If the Session Keepalive Interval is unacceptable, the entity SHALL terminate the session with a reason code of "Contact Failure".

Item Flags:

A one-octet field containing generic bit flags related to the Item, which are listed in Table 3.All reserved header flag bits SHALL be set to 0 by the sender.All reserved header flag bits SHALL be ignored by the receiver.If a TCPCL entity receives a Session Extension Item with an unknown Item Type and the CRITICAL flag set to 1, the entity SHALL terminate the TCPCL session with a SESS_TERM reason code of "Contact Failure".If the CRITICAL flag is 0, an entity SHALL skip over and ignore any item with an unknown Item Type.

Item Type:

A 16-bit unsigned integer field containing the type of the extension item.This specification does not define any extension types directly but does create an IANA registry for such codes (see Section 8.3).

Item Length:

A 16-bit unsigned integer field containing the number of Item Value octets to follow.

Item Value:

A variable-length data field that is interpreted according to the associated Item Type.This specification places no restrictions on an extension's use of available Item Value data.Extension specifications SHOULD avoid the use of large data lengths, as no bundle transfers can begin until the full extension data is sent.

                     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...                                 |
+---------------+---------------+---------------+---------------+

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

Reason Code:

A one-octet refusal reason code interpreted according to the descriptions in Table 4.

Rejected Message Header:

The Rejected Message Header is a copy of the Message Header to which the MSG_REJECT message is sent as a response.

+------------------------------+
|       Message Header         |
+------------------------------+
|     Message Flags (U8)       |
+------------------------------+
|      Transfer ID (U64)       |
+------------------------------+
|     Transfer Extension       |
|      Items Length (U32)      |
|   (only for START segment)   |
+------------------------------+
|     Transfer Extension       |
|         Items (var.)         |
|   (only for START segment)   |
+------------------------------+
|      Data length (U64)       |
+------------------------------+
| Data contents (octet string) |
+------------------------------+

Message Flags:

A one-octet field of single-bit flags, interpreted according to the descriptions in Table 5.All reserved header flag bits SHALL be set to 0 by the sender.All reserved header flag bits SHALL be ignored by the receiver.

Transfer ID:

A 64-bit unsigned integer identifying the transfer being made.

Transfer Extension Items Length and Transfer Extension Items list:

- Together, these fields represent protocol extension data for this specification.The Transfer Extension Items Length and Transfer Extension Items list SHALL only be present when the START flag is set to 1 on the message.The Transfer Extension Items Length is the total number of octets to follow that are used to encode the Transfer Extension Items list.The encoding of each Transfer Extension Item is within a consistent data container, as described in Section 5.2.5.The full set of Transfer Extension Items apply only to the associated single transfer.The order and multiplicity of these Transfer Extension Items are significant, as defined in the associated type specification(s).If the content of the Transfer Extension Items list disagrees with the Transfer Extension Items Length (e.g., the last item claims to use more or fewer octets than are indicated in the Transfer Extension Items Length), the reception of the XFER_SEGMENT is considered to have failed.

Data length:

A 64-bit unsigned integer indicating the number of octets in Data contents to follow.

Data contents:

The variable-length data payload of the message.

+-----------------------------+
|       Message Header        |
+-----------------------------+
|     Message Flags (U8)      |
+-----------------------------+
|      Transfer ID (U64)      |
+-----------------------------+
| Acknowledged length (U64)   |
+-----------------------------+

Message Flags:

A one-octet field of single-bit flags, interpreted according to the descriptions in Table 5.All reserved header flag bits SHALL be set to 0 by the sender.All reserved header flag bits SHALL be ignored by the receiver.

Transfer ID:

A 64-bit unsigned integer identifying the transfer being acknowledged.

Acknowledged length:

A 64-bit unsigned integer indicating the total number of octets in the transfer that are being acknowledged.

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

Reason Code:

A one-octet refusal reason code interpreted according to the descriptions in Table 6.

Transfer ID:

A 64-bit unsigned integer identifying the transfer being refused.

Item Flags:

A one-octet field containing generic bit flags related to the Item, which are listed in Table 7.All reserved header flag bits SHALL be set to 0 by the sender.All reserved header flag bits SHALL be ignored by the receiver.If a TCPCL entity receives a Transfer Extension Item with an unknown Item Type and the CRITICAL flag is 1, the entity SHALL refuse the transfer with a XFER_REFUSE reason code of "Extension Failure".If the CRITICAL flag is 0, an entity SHALL skip over and ignore any item with an unknown Item Type.

Item Type:

A 16-bit unsigned integer field containing the type of the extension item.This specification creates an IANA registry for such codes (see Section 8.4).

Item Length:

A 16-bit unsigned integer field containing the number of Item Value octets to follow.

Item Value:

A variable-length data field that is interpreted according to the associated Item Type.This specification places no restrictions on an extension's use of available Item Value data.Extension specifications SHOULD avoid the use of large data lengths, as the associated transfer cannot begin until the full extension data is sent.

                     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...                                 |
+---------------+---------------+---------------+---------------+

+----------------------+
|  Total Length (U64)  |
+----------------------+

Total Length:

A 64-bit unsigned integer indicating the size of the data to be transferred.The Total Length field SHALL be treated as authoritative by the receiver.If, for whatever reason, the actual total length of bundle data received differs from the value indicated by the Total Length value, the receiver SHALL treat the transmitted data as invalid and send a XFER_REFUSE with a reason code of "Not Acceptable".

• an entity MAY finish an in-progress transfer in either direction.
• an entity SHALL NOT begin any new outgoing transfer for the remainder of the session.
• an entity SHALL NOT accept any new incoming transfer for the remainder of the session.

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

Message Flags:

A one-octet field of single-bit flags, interpreted according to the descriptions in Table 8.All reserved header flag bits SHALL be set to 0 by the sender.All reserved header flag bits SHALL be ignored by the receiver.

Reason Code:

A one-octet refusal reason code interpreted according to the descriptions in Table 9.

[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/>.

[IANA-SMI]

IANA, "Structure of Management Information (SMI) Numbers (MIB Module Registrations)",
<https://www.iana.org/assignments/smi-numbers/>.

[RFC0793]

J. Postel, "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.

[RFC1122]

R. Braden, "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.

[RFC2119]

S. Bradner, "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>.

[RFC3986]

T. Berners-Lee, R. Fielding, 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>.

[RFC5280]

D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.

[RFC6066]

D. Eastlake 3rd, "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.

[RFC6125]

P. Saint-Andre, and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011,
<https://www.rfc-editor.org/info/rfc6125>.

[RFC6960]

S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.

[RFC7525]

Y. Sheffer, R. Holz, and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015,
<https://www.rfc-editor.org/info/rfc7525>.

[RFC8126]

M. Cotton, B. Leiba, 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>.

[RFC8174]

B. Leiba, "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>.

[RFC8446]

E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.

[RFC9171]

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

[X.680]

ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", February 2021,
<https://www.itu.int/rec/T-REC-X.680-202102-I/en>.

[AEAD-LIMITS]

A. Luykx, and K. Paterson, "Limits on Authenticated Encryption Use in TLS", August 2017,
<https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.

[RFC2595]

C. Newman, "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999,
<https://www.rfc-editor.org/info/rfc2595>.

[RFC3552]

E. Rescorla, 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>.

[RFC4511]

J. Sermersheim, "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511, June 2006,
<https://www.rfc-editor.org/info/rfc4511>.

[RFC4838]

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

[RFC5489]

M. Badra, and I. Hajjeh, "ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)", RFC 5489, DOI 10.17487/RFC5489, March 2009,
<https://www.rfc-editor.org/info/rfc5489>.

[RFC5912]

P. Hoffman, and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.

[RFC6698]

P. Hoffman, and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012,
<https://www.rfc-editor.org/info/rfc6698>.

[RFC7122]

H. Kruse, S. Jero, and S. Ostermann, "Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)", RFC 7122, DOI 10.17487/RFC7122, March 2014,
<https://www.rfc-editor.org/info/rfc7122>.

[RFC7242]

M. Demmer, J. Ott, and S. Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol", RFC 7242, DOI 10.17487/RFC7242, June 2014,
<https://www.rfc-editor.org/info/rfc7242>.

[RFC7250]

P. Wouters, H. Tschofenig, J. Gilmore, S. Weiler, and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014,
<https://www.rfc-editor.org/info/rfc7250>.

[RFC7435]

V. Dukhovni, "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014,
<https://www.rfc-editor.org/info/rfc7435>.

[RFC7457]

Y. Sheffer, R. Holz, and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015,
<https://www.rfc-editor.org/info/rfc7457>.

[RFC8555]

R. Barnes, J. Hoffman-Andrews, D. McCarney, and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.

[RFC9172]

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

[DTN-BIBECT]

JPL, Calif. Inst. Of Technology, , "Bundle-in-Bundle Encapsulation", Internet-Draft draft-ietf-dtn-bibect-03, February 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bibect-03>.

• Split Contact Header into pre-TLS protocol negotiation and SESS_INIT parameter negotiation. The Contact Header is now fixed length.
• Changed Contact Header content to limit number of negotiated options.
• Added session option to negotiate maximum segment size (per each direction).
• Renamed "endpoint ID" to "node ID" to conform with BPv7 terminology.
• Added session extension capability.
• Added transfer extension capability. Moved transfer total length into an extension item.
• Defined new IANA registries for message / type / reason codes to allow renaming some codes for clarity.
• Pointed out that segments of all new IANA registries are reserved for private/experimental use.
• Expanded Message Header to octet-aligned fields instead of bit-packing.
• Added a bundle transfer identification number to all bundle-related messages (XFER_SEGMENT, XFER_ACK, XFER_REFUSE).
• Added flags in XFER_ACK to mirror flags from XFER_SEGMENT.
• Removed all uses of Self-Delimiting Numeric Value (SDNV) fields and replaced with fixed-bit-length (network byte order) fields.
• Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown" related to TCP connections.
• Removed the notion of a reconnection delay parameter.

• Added MSG_REJECT message to indicate that an unknown or unhandled message was received.
• Added TLS connection security mechanism.
• Added "Not Acceptable", "Extension Failure", and "Session Terminating" XFER_REFUSE reason codes.
• Added "Contact Failure" (contact negotiation failure) and "Resource Exhaustion" SESS_TERM reason codes.

Brian Sipos

Michael Demmer

Jörg Ott

Simon Perreault