rfc9174.original.xml   rfc9174.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" <!DOCTYPE rfc [
docName="draft-ietf-dtn-tcpclv4-28" ipr="trust200902" submissionType="IETF" tocI <!ENTITY nbsp "&#160;">
nclude="true" version="3" xml:lang="en"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
submissionType="IETF"
category="std"
consensus="true"
docName="draft-ietf-dtn-tcpclv4-26"
number="9174"
ipr="trust200902"
tocInclude="true"
symRefs="true"
version="3"
xml:lang="en">
<front> <front>
<title abbrev="DTN TCPCLv4"> <title abbrev="DTN TCPCLv4">
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4
</title> </title>
<seriesInfo name="Internet-Draft" value="draft-ietf-dtn-tcpclv4-28"/> <seriesInfo name="RFC" value="9174"/>
<author fullname="Brian Sipos" initials="B." surname="Sipos"> <author fullname="Brian Sipos" initials="B." surname="Sipos">
<organization abbrev="RKF Engineering"> <organization abbrev="RKF Engineering">
RKF Engineering Solutions, LLC RKF Engineering Solutions, LLC
</organization> </organization>
<address> <address>
<postal> <postal>
<street>7500 Old Georgetown Road</street> <street>7500 Old Georgetown Road</street>
<street>Suite 1275</street> <street>Suite 1275</street>
<city>Bethesda</city> <city>Bethesda</city>
<region>MD</region> <region>MD</region>
<code>20814-6198</code> <code>20814-6198</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>brian.sipos+ietf@gmail.com</email> <email>brian.sipos+ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Michael Demmer" initials="M." surname="Demmer"> <author fullname="Michael Demmer" initials="M." surname="Demmer">
<organization abbrev="UC Berkeley">
University of California, Berkeley
</organization>
<address> <address>
<postal> <email>demmer@gmail.com</email>
<street>Computer Science Division</street>
<street>445 Soda Hall</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720-1776</code>
<country>United States of America</country>
</postal>
<email>demmer@cs.berkeley.edu</email>
</address> </address>
</author> </author>
<author fullname="Joerg Ott" initials="J." surname="Ott"> <author fullname="Jรถrg Ott" initials="J." surname="Ott">
<organization> <organization>
Aalto University Technical University of Munich
</organization> </organization>
<address> <address>
<postal> <postal>
<street>Department of Communications and Networking</street> <extaddr>Department of Informatics</extaddr>
<street>PO Box 13000</street> <extaddr>Chair of Connected Mobility</extaddr>
<city>Aalto</city> <street>Boltzmannstrasse 3</street>
<code>02015</code> <city>Garching</city>
<country>Finland</country> <code>DE-85748</code>
<country>Germany</country>
</postal> </postal>
<email>ott@in.tum.de</email> <email>ott@in.tum.de</email>
</address> </address>
</author> </author>
<author fullname="Simon Perreault" initials="S." surname="Perreault"> <author fullname="Simon Perreault" initials="S." surname="Perreault">
<organization> <organization>LogMeIn</organization>
</organization>
<address> <address>
<postal> <postal>
<street/> <street>410 boulevard Charest Est</street>
<street>Suite 250</street>
<city>Quebec</city> <city>Quebec</city>
<region>QC</region> <region>QC</region>
<code>G1K 8G3</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>simon@per.reau.lt</email> <email>simon.perreault@logmein.com</email>
</address> </address>
</author> </author>
<date/> <date month="January" year="2022"/>
<area>Transport</area> <area>Transport</area>
<workgroup>Delay-Tolerant Networking</workgroup> <workgroup>Delay-Tolerant Networking</workgroup>
<keyword>DTN</keyword> <keyword>DTN</keyword>
<keyword>TCP</keyword>
<keyword>TLS</keyword>
<keyword>PKIX</keyword>
<abstract> <abstract>
<t> <t>
This document describes a TCP-based convergence layer (TCPCL) for Delay-Tolerant This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Netwo
Networking (DTN). rking (DTN). This version of the TCPCL protocol resolves implementation issues i
This version of the TCPCL protocol resolves implementation issues in the earlier n the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the
TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol (BP) contents, en Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in
codings, and convergence layer requirements in BP Version 7. BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Con
Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data uni cise Binary Object Representation (CBOR) as its service data unit being transpor
t being transported and provides a reliable transport of such bundles. ted and provides a reliable transport of such bundles.
This version of TCPCL also includes security and extensibility mechanisms. This TCPCL version also includes security and extensibility mechanisms.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sec-intro"> <section anchor="sec-intro">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
This document describes the TCP-based convergence-layer protocol for Delay-Toler This document describes the TCP convergence-layer protocol for Delay-Tolerant Ne
ant Networking. tworking (DTN).
Delay-Tolerant Networking is an end-to-end architecture providing communications DTN is an end-to-end architecture providing communications in and/or through hig
in and/or through highly stressed environments, including those with intermitte hly stressed environments, including those with intermittent connectivity, long
nt connectivity, long and/or variable delays, and high bit error rates. and/or variable delays, and high bit error rates.
More detailed descriptions of the rationale and capabilities of these networks c More detailed descriptions of the rationale and capabilities of these networks c
an be found in "Delay-Tolerant Network Architecture" <xref target="RFC4838"/>. an be found in "<xref target="RFC4838" format="title"/>" <xref target="RFC4838"
format="default"/>.
</t> </t>
<t> <t>
An important goal of the DTN architecture is to accommodate a wide range of netw orking technologies and environments. An important goal of the DTN architecture is to accommodate a wide range of netw orking technologies and environments.
The protocol used for DTN communications is the Bundle Protocol Version 7 (BPv7) <xref target="I-D.ietf-dtn-bpbis"/>, an application-layer protocol that is used to construct a store-and-forward overlay network. The protocol used for DTN communications is the Bundle Protocol version 7 (BPv7) <xref target="RFC9171"/>, an application-layer protocol that is used to constru ct a store-and-forward overlay network.
BPv7 requires the services of a "convergence-layer adapter" (CLA) to send and re ceive bundles using the service of some "native" link, network, or Internet prot ocol. BPv7 requires the services of a "convergence-layer adapter" (CLA) to send and re ceive bundles using the service of some "native" link, network, or Internet prot ocol.
This document describes one such convergence-layer adapter that uses the well-kn own Transmission Control Protocol (TCP). This document describes one such convergence-layer adapter that uses the well-kn own Transmission Control Protocol (TCP).
This convergence layer is referred to as TCP Convergence Layer Version 4 (TCPCLv This convergence layer is referred to as TCP Convergence Layer version 4 (TCPCLv
4). 4).
For the remainder of this document, the abbreviation "BP" without the version su For the remainder of this document,</t>
ffix refers to BPv7.
For the remainder of this document, the abbreviation "TCPCL" without the version <ul spacing="normal">
suffix refers to TCPCLv4. <li>the abbreviation "BP" without the version suffix refers to BPv7.</li>
</t> <li>the abbreviation "TCPCL" without the version suffix refers to TCPCLv4.</l
i>
</ul>
<t> <t>
The locations of the TCPCL and the BP in the Internet model protocol stack (desc The locations of the TCPCL and the Bundle Protocol in the Internet model protoco
ribed in <xref target="RFC1122"/>) are shown in Figure 1. l stack (described in <xref target="RFC1122"/>) are shown in <xref target="fig-t
In particular, when BP is using TCP as its bearer with TCPCL as its convergence cpcl-ip-stack"/>.
layer, both BP and TCPCL reside at the application layer of the Internet model. In particular, when BP is using TCP as its bearer with the TCPCL as its converge
nce layer, both BP and the TCPCL reside at the application layer of the Internet
model.
</t> </t>
<figure anchor="fig-tcpcl-ip-stack"> <figure anchor="fig-tcpcl-ip-stack">
<name>The Locations of the Bundle Protocol and the TCP Convergence-Layer Protocol above the Internet Protocol Stack</name> <name>The Locations of the Bundle Protocol and the TCP Convergence-Layer Protocol above the Internet Protocol Stack</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+-------------------------+ +-------------------------+
| DTN Application | -\ | DTN Application | -\
+-------------------------| | +-------------------------| |
| Bundle Protocol (BP) | -&gt; Application Layer | Bundle Protocol (BP) | -&gt; Application Layer
+-------------------------+ | +-------------------------+ |
| TCP Conv. Layer (TCPCL) | | | TCP Conv. Layer (TCPCL) | |
skipping to change at line 131 skipping to change at line 144
</artwork> </artwork>
</figure> </figure>
<section> <section>
<name>Scope</name> <name>Scope</name>
<t> <t>
This document describes the format of the protocol data units passed between ent ities participating in TCPCL communications. This document describes the format of the protocol data units passed between ent ities participating in TCPCL communications.
This document does not address: This document does not address:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
The format of protocol data units of the Bundle Protocol, as those are defined e lsewhere in <xref target="I-D.ietf-dtn-bpbis"/>. The format of protocol data units of the Bundle Protocol, as those are defined e lsewhere in <xref target="RFC9171"/>.
This includes the concept of bundle fragmentation or bundle encapsulation. This includes the concept of bundle fragmentation or bundle encapsulation.
The TCPCL transfers bundles as opaque data blocks. The TCPCL transfers bundles as opaque data blocks.
</li> </li>
<li> <li>
Mechanisms for locating or identifying other bundle entities (peers) within a ne twork or across an internet. Mechanisms for locating or identifying other bundle entities (peers) within a ne twork or across an internet.
The mapping of Node ID to potential convergence layer (CL) protocol and network The mapping of a node ID to a potential convergence layer (CL) protocol and netw
address is left to implementation and configuration of the BP Agent and its vari ork address is left to implementation and configuration of the BP Agent (BPA) an
ous potential routing strategies. d its various potential routing strategies, as is the mapping of a DNS name and/
The mapping of DNS name and/or address to a choice of end-entity certificate to or address to a choice of an end-entity certificate to authenticate a node to it
authenticate a node to its peers. s peers.
</li> </li>
<li> <li>
Logic for routing bundles along a path toward a bundle's endpoint. Logic for routing bundles along a path toward a bundle's endpoint.
This CL protocol is involved only in transporting bundles between adjacent entit ies in a routing sequence. This CL protocol is involved only in transporting bundles between adjacent entit ies in a routing sequence.
</li> </li>
<li> <li>
Policies or mechanisms for issuing Public Key Infrastructure Using X.509 (PKIX) certificates; provisioning, deploying, or accessing certificates and private key s; deploying or accessing certificate revocation lists (CRLs); or configuring se curity parameters on an individual entity or across a network. Policies or mechanisms for issuing Public Key Infrastructure Using X.509 (PKIX) certificates; provisioning, deploying, or accessing certificates and private key s; deploying or accessing certificate revocation lists (CRLs); or configuring se curity parameters on an individual entity or across a network.
</li> </li>
<li> <li>
Uses of TLS which are not based on PKIX certificate authentication (see <xref ta rget="sec-security-tlsnopki"/>) or in which authentication of both entities is n ot possible (see <xref target="sec-security-tlsnoauth"/>). Uses of TLS that are not based on PKIX certificate authentication (see <xref tar get="sec-security-tlsnopki"/>) or in which authentication of both entities is no t possible (see <xref target="sec-security-tlsnoauth"/>).
</li> </li>
</ul> </ul>
<t> <t>
Any TCPCL implementation requires a BP agent to perform those above listed funct ions in order to perform end-to-end bundle delivery. Any TCPCL implementation requires a BPA to perform those above-listed functions in order to perform end-to-end bundle delivery.
</t> </t>
</section> </section>
</section> </section>
<section> <section>
<name>Requirements Language</name> <name>Requirements Language</name>
<t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
HOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this docu "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
ment are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref "<bcp14>SHOULD NOT</bcp14>",
target="RFC8174"/> when, and only when, they appear in all capitals, as shown h "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
ere. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
</t> are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<section anchor="sec-term-defs"> <section anchor="sec-term-defs">
<name>Definitions Specific to the TCPCL Protocol</name> <name>Definitions Specific to the TCPCL Protocol</name>
<t> <t>
This section contains definitions specific to the TCPCL protocol. This section contains definitions specific to the TCPCL protocol.
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Network Byte Order:</dt> <dt>Network Byte Order:</dt>
<dd> <dd>
Most significant byte first, a.k.a., big endian. 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 by All of the integer encodings in this protocol <bcp14>SHALL</bcp14> be transmitte
te order. d in network byte order.
</dd> </dd>
<dt>TCPCL Entity:</dt> <dt>TCPCL Entity:</dt>
<dd> <dd>
<t> <t>
This is the notional TCPCL application that initiates TCPCL sessions. This is the notional TCPCL application that initiates TCPCL sessions.
This design, implementation, configuration, and specific behavior of such an ent ity is outside of the scope of this document. This design, implementation, configuration, and specific behavior of such an ent ity 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. 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 : The relationship between a TCPCL entity and TCPCL sessions is defined as follows :
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
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 enti ty in the network. A TCPCL entity <bcp14>MAY</bcp14> 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.
</li> </li>
<li> <li>
A TCPCL Entity MAY support zero or more passive listening elements that listen f or connection requests from other TCPCL Entities operating on other entities in the network. A TCPCL entity <bcp14>MAY</bcp14> support zero or more passive listening element s that listen for connection requests from other TCPCL entities operating on oth er entities in the network.
</li> </li>
<li> <li>
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. A TCPCL entity <bcp14>MAY</bcp14> passively initiate any number of TCPCL session s from requests received by its passive listening element(s) if the entity uses such elements.
</li> </li>
</ul> </ul>
<t> <t>
These relationships are illustrated in <xref target="fig-entity-session-relation s"/>. These relationships are illustrated in <xref target="fig-entity-session-relation s"/>.
For most TCPCL behavior within a session, the two entities are symmetric and the re is no protocol distinction between them. For most TCPCL behavior within a session, the two entities are symmetric and the re is no protocol distinction between them.
Some specific behavior, particularly during session establishment, distinguishes between the active entity and the passive entity. 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. For the remainder of this document, the term "entity" without the prefix "TCPCL" refers to a TCPCL entity.
</t> </t>
</dd> </dd>
<dt>TCP Connection:</dt> <dt>TCP Connection:</dt>
<dd> <dd>
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. The term "connection" in this specification exclusively refers to a TCP connecti on and any and all behaviors, sessions, and other states associated with that TC P connection.
</dd> </dd>
<dt>TCPCL Session:</dt> <dt>TCPCL Session:</dt>
<dd> <dd>
A TCPCL session (as opposed to a TCP connection) is a TCPCL communication relati onship between two TCPCL entities. A TCPCL session (as opposed to a TCP connection) is a TCPCL communication relati onship between two TCPCL entities.
A TCPCL session operates within a single underlying TCP connection and the lifet A TCPCL session operates within a single underlying TCP connection, and the life
ime of a TCPCL session is bound to the lifetime of that TCP connection. time of a TCPCL session is bound to the lifetime of that TCP connection.
A TCPCL session is terminated when the TCP connection ends, due either to one or A TCPCL session is terminated when the TCP connection ends, due to either (1)&nb
both entities actively closing the TCP connection or due to network errors caus sp;one or both entities actively closing the TCP connection or (2)&nbsp;network
ing a failure of the TCP connection. errors causing a failure of the TCP connection.
Within a single TCPCL session there are two possible transfer streams; one in ea Within a single TCPCL session, there are two possible transfer streams: one in e
ch direction, with one stream from each entity being the outbound stream and the ach direction, with one stream from each entity being the outbound stream and th
other being the inbound stream (see <xref target="fig-session-stream"/>). e other being the inbound stream (see <xref target="fig-session-stream"/>).
From the perspective of a TCPCL session, the two transfer streams do not logical ly interact with each other. From the perspective of a TCPCL session, the two transfer streams do not logical ly interact with each other.
The streams do operate over the same TCP connection and between the same BP agen ts, so there are logical relationships at those layers (message and bundle inter leaving respectively). The streams do operate over the same TCP connection and between the same BPAs, s o there are logical relationships at those layers (message and bundle interleavi ng, respectively).
For the remainder of this document, the term "session" without the prefix "TCPCL " refers to a TCPCL session. For the remainder of this document, the term "session" without the prefix "TCPCL " refers to a TCPCL session.
</dd> </dd>
<dt>Session parameters:</dt> <dt>Session Parameters:</dt>
<dd> <dd>
These are a set of values used to affect the operation of the TCPCL for a given session. 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 there by to the TCPCL is implementation dependent. The manner in which these parameters are conveyed to the bundle entity and there by to the TCPCL is implementation dependent.
However, the mechanism by which two entities exchange and negotiate the values t o be used for a given session is described in <xref target="sec-contact-negotiat e"/>. However, the mechanism by which two entities exchange and negotiate the values t o be used for a given session is described in <xref target="sec-contact-negotiat e"/>.
</dd> </dd>
<dt>Transfer Stream:</dt> <dt>Transfer Stream:</dt>
<dd> <dd>
A Transfer stream is a uni-directional user-data path within a TCPCL Session. 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. 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 s At the stream layer, there is no logical relationship between transfers in that
tream; it's only within the BP agent that transfers are fully decoded as bundles 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 enti
Each uni-directional stream has a single sender entity and a single receiver ent ty.
ity.
</dd> </dd>
<dt>Transfer:</dt> <dt>Transfer:</dt>
<dd> <dd>
This refers to the procedures and mechanisms for conveyance of an individual bun dle from one node to another. This refers to the procedures and mechanisms for conveyance of an individual bun dle from one node to another.
Each transfer within TCPCL is identified by a Transfer ID number which is guaran teed to be unique only to a single direction within a single Session. Each transfer within the TCPCL is identified by a Transfer ID number, which is g uaranteed to be unique only to a single direction within a single session.
</dd> </dd>
<dt>Transfer Segment:</dt> <dt>Transfer Segment:</dt>
<dd> <dd>
A subset of a transfer of user data being communicated over a transfer stream. A transfer segment is a subset of a transfer of user data being communicated ove r a transfer stream.
</dd> </dd>
<dt>Idle Session:</dt> <dt>Idle Session:</dt>
<dd> <dd>
A TCPCL session is idle while there is no transmission in-progress in either dir ection. A TCPCL session is idle while there is no transmission in progress in either dir ection.
While idle, the only messages being transmitted or received are KEEPALIVE messag es. While idle, the only messages being transmitted or received are KEEPALIVE messag es.
</dd> </dd>
<dt>Live Session:</dt> <dt>Live Session:</dt>
<dd> <dd>
A TCPCL session is live while there is a transmission in-progress in either dire ction. A TCPCL session is live while there is a transmission in progress in either dire ction.
</dd> </dd>
<dt>Reason Codes:</dt> <dt>Reason Codes:</dt>
<dd> <dd>
The TCPCL uses numeric codes to encode specific reasons for individual failure/e rror message types. The TCPCL uses numeric codes to encode specific reasons for individual failure/e rror message types.
</dd> </dd>
</dl> </dl>
<t> <t>
The relationship between connections, sessions, and streams is shown in <xref ta rget="fig-session-stream"/>. The relationship between connections, sessions, and streams is shown in <xref ta rget="fig-session-stream"/>.
</t> </t>
<figure anchor="fig-entity-session-relations"> <figure anchor="fig-entity-session-relations">
<name>The relationships between TCPCL entities</name> <name>The Relationships between TCPCL Entities</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+--------------------------------------------+ +--------------------------------------------+
| TCPCL Entity | | TCPCL Entity |
| | +----------------+ | | +----------------+
| +--------------------------------+ | | |-+ | +--------------------------------+ | | |-+
| | Actively Initiated Session #1 +-------------&gt;| Other | | | | Actively Initiated Session #1 +-------------&gt;| Other | |
| +--------------------------------+ | | TCPCL Entity's | | | +--------------------------------+ | | TCPCL Entity's | |
| ... | | Passive | | | ... | | Passive | |
| +--------------------------------+ | | Listener | | | +--------------------------------+ | | Listener | |
| | Actively Initiated Session #n +-------------&gt;| | | | | Actively Initiated Session #n +-------------&gt;| | |
skipping to change at line 283 skipping to change at line 301
| | +---------------------------------+ | | Initiator(s) | | | | +---------------------------------+ | | Initiator(s) | |
| | | | | | | | | | | |
| | +---------------------------------+ | | | | | | +---------------------------------+ | | | |
| +---&gt;| Passively Initiated Session #n +--------&gt;| | | | +---&gt;| Passively Initiated Session #n +--------&gt;| | |
| +---------------------------------+ | +----------------+ | | +---------------------------------+ | +----------------+ |
| | +-----------------+ | | +-----------------+
+--------------------------------------------+ +--------------------------------------------+
</artwork> </artwork>
</figure> </figure>
<figure anchor="fig-session-stream"> <figure anchor="fig-session-stream">
<name>The relationship within a TCPCL Session of its two streams</name > <name>The Relationship within a TCPCL Session of its Two Streams</name >
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
| "Own" TCPCL Session | | "Other" TCPCL Session | | "Own" TCPCL Session | | "Other" TCPCL Session |
| | | | | | | |
| +----------------------+ | | +----------------------+ | | +----------------------+ | | +----------------------+ |
| | TCP Connection | | | | TCP Connection | | | | TCP Connection | | | | TCP Connection | |
| | | | | | | | | | | | | | | |
| | +-----------------+ | | Messages | | +-----------------+ | | | | +-----------------+ | | Messages | | +-----------------+ | |
| | | Own Inbound | +--------------------+ | Peer Outbound | | | | | | Own Inbound | +--------------------+ | Peer Outbound | | |
| | | Transfer Stream | | Transfer Stream | | | | | | Transfer Stream | | Transfer Stream | | |
skipping to change at line 313 skipping to change at line 331
| | +-----------------+ | | | | +-----------------+ | | | | +-----------------+ | | | | +-----------------+ | |
| +-----------------------+ | | +---------------------+ | | +-----------------------+ | | +---------------------+ |
+----------------------------+ +--------------------------+ +----------------------------+ +--------------------------+
</artwork> </artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="sec-prococol"> <section anchor="sec-prococol">
<name>General Protocol Description</name> <name>General Protocol Description</name>
<t> <t>
The service of this protocol is the transmission of DTN bundles via the Transmis sion Control Protocol (TCP). The service of this protocol is the transmission of DTN bundles via TCP.
This document specifies the encapsulation of bundles, procedures for TCP setup a nd teardown, and a set of messages and entity requirements. This document specifies the encapsulation of bundles, procedures for TCP setup a nd teardown, and a set of messages and entity requirements.
The general operation of the protocol is as follows. The general operation of the protocol is as follows.
</t> </t>
<section anchor="sec-cl-services"> <section anchor="sec-cl-services">
<name>Convergence Layer Services</name> <name>Convergence-Layer Services</name>
<t> <t>
This version of the TCPCL provides the following services to support the overlay This version of the TCPCL protocol provides the following services to support th
ing Bundle Protocol agent. e overlaying BPA.
In all cases, this is not an API definition but a logical description of how the In all cases, this is not an API definition but a logical description of how the
CL can interact with the BP agent. CL can interact with the BPA.
Each of these interactions can be associated with any number of additional metad Each of these interactions can be associated with any number of additional metad
ata items as necessary to support the operation of the CL or BP agent. ata items as necessary to support the operation of the CL or BPA.
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Attempt Session:</dt> <dt>Attempt Session:</dt>
<dd> <dd>
The TCPCL allows a BP agent to preemptively attempt to establish a TCPCL session The TCPCL allows a BPA to preemptively attempt to establish a TCPCL session with
with a peer entity. a peer entity.
Each session attempt can send a different set of session negotiation parameters Each session attempt can send a different set of session negotiation parameters
as directed by the BP agent. as directed by the BPA.
</dd> </dd>
<dt>Terminate Session:</dt> <dt>Terminate Session:</dt>
<dd> <dd>
The TCPCL allows a BP agent to preemptively terminate an established TCPCL sessi The TCPCL allows a BPA to preemptively terminate an established TCPCL session wi
on with a peer entity. th a peer entity.
The terminate request is on a per-session basis. The terminate request is done on a per-session basis.
</dd> </dd>
<dt>Session State Changed:</dt> <dt>Session State Changed:</dt>
<dd> <dd>
<t> <t>
The TCPCL entity indicates to the BP agent when the session state changes. The TCPCL entity indicates to the BPA when the session state changes.
The top-level session states indicated are: The top-level session states indicated are as follows:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Connecting:</dt> <dt>Connecting:</dt>
<dd>A TCP connection is being established. This state only applies to the active entity.</dd> <dd>A TCP connection is being established. This state only applies to the active entity.</dd>
<dt>Contact Negotiating:</dt> <dt>Contact Negotiating:</dt>
<dd>A TCP connection has been made (as either active or passive en tity) and contact negotiation has begun.</dd> <dd>A TCP connection has been made (as either the active or passiv e entity), and contact negotiation has begun.</dd>
<dt>Session Negotiating:</dt> <dt>Session Negotiating:</dt>
<dd>Contact negotiation has been completed (including possible TLS use) and session negotiation has begun.</dd> <dd>Contact negotiation has been completed (including possible TLS use), and session negotiation has begun.</dd>
<dt>Established:</dt> <dt>Established:</dt>
<dd> <dd>
The session has been fully established and is ready for its first transfer. The session has been fully established and is ready for its first transfer.
When the session is established, the peer Node ID (along with indication of whet her or not it was authenticated) and the negotiated session parameters (see <xre f target="sec-session-negotiate"/>) are also communicated to the BP agent. When the session is established, the peer node ID (along with an indication of w hether or not it was authenticated) and the negotiated session parameters (see < xref target="sec-session-negotiate"/>) are also communicated to the BPA.
</dd> </dd>
<dt>Ending:</dt> <dt>Ending:</dt>
<dd>The entity sent SESS_TERM message and is in the ending state.< /dd> <dd>The entity sent a SESS_TERM message and is in the Ending state .</dd>
<dt>Terminated:</dt> <dt>Terminated:</dt>
<dd>The session has finished normal termination sequencing.</dd> <dd>The session has finished normal termination sequencing.</dd>
<dt>Failed:</dt> <dt>Failed:</dt>
<dd>The session ended without normal termination sequencing.</dd> <dd>The session ended without normal termination sequencing.</dd>
</dl> </dl>
</dd> </dd>
<dt>Session Idle Changed:</dt> <dt>Session Idle Changed:</dt>
<dd> <dd>
The TCPCL entity indicates to the BP agent when the live/idle sub-state of the s ession changes. 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". This occurs only when the top-level session state is "Established".
The session transitions from Idle to Live at the at the start of a transfer in e The session transitions from Idle to Live at the start of a transfer in either t
ither transfer stream; the session transitions from Live to Idle at the end of a ransfer stream; the session transitions from Live to Idle at the end of a transf
transfer when the other transfer stream does not have an ongoing transfer. er when the other transfer stream does not have an ongoing transfer.
Because TCPCL transmits serially over a TCP connection it suffers from "head of Because the TCPCL transmits serially over a TCP connection, it suffers from "hea
queue blocking," so a transfer in either direction can block an immediate start d-of-queue blocking", so a transfer in either direction can block an immediate s
of a new transfer in the session. tart of a new transfer in the session.
</dd> </dd>
<dt>Begin Transmission:</dt> <dt>Begin Transmission:</dt>
<dd> <dd>
The principal purpose of the TCPCL is to allow a BP agent to transmit bundle dat The principal purpose of the TCPCL is to allow a BPA to transmit bundle data ove
a over an established TCPCL session. r an established TCPCL session.
Transmission request is on a per-session basis and the CL does not necessarily p Transmission requests are done on a per-session basis, and the CL does not neces
erform any per-session or inter-session queueing. sarily perform any per-session or inter-session queueing.
Any queueing of transmissions is the obligation of the BP agent. Any queueing of transmissions is the obligation of the BPA.
</dd> </dd>
<dt>Transmission Success:</dt> <dt>Transmission Success:</dt>
<dd> <dd>
The TCPCL entity indicates to the BP agent when a bundle has been fully transfer red to a peer entity. The TCPCL entity indicates to the BPA when a bundle has been fully transferred t o a peer entity.
</dd> </dd>
<dt>Transmission Intermediate Progress:</dt> <dt>Transmission Intermediate Progress:</dt>
<dd> <dd>
The TCPCL entity indicates to the BP agent on intermediate progress of transfer to a peer entity. 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. This intermediate progress is at the granularity of each transferred segment.
</dd> </dd>
<dt>Transmission Failure:</dt> <dt>Transmission Failure:</dt>
<dd> <dd>
The TCPCL entity indicates to the BP agent on certain reasons for bundle transmi ssion failure, notably when the peer entity rejects the bundle or when a TCPCL s ession ends before transfer success. The TCPCL entity indicates to the BPA certain reasons for bundle transmission fa ilure, notably when the peer entity rejects the bundle or when a TCPCL session e nds before transfer success.
The TCPCL itself does not have a notion of transfer timeout. The TCPCL itself does not have a notion of transfer timeout.
</dd> </dd>
<dt>Reception Initialized:</dt> <dt>Reception Initialized:</dt>
<dd> <dd>
The TCPCL entity indicates to the receiving BP agent just before any transmissio The TCPCL entity indicates this status to the receiving BPA just before any tran
n data is sent. smission data is sent.
This corresponds to reception of the XFER_SEGMENT message with the START flag of This corresponds to reception of the XFER_SEGMENT message with the <tt>START</tt
1. > flag set to 1.
</dd> </dd>
<dt>Interrupt Reception:</dt> <dt>Interrupt Reception:</dt>
<dd> <dd>
The TCPCL entity allows a BP agent to interrupt an individual transfer before it has fully completed (successfully or not). 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. Interruption can occur any time after the reception is initialized.
</dd> </dd>
<dt>Reception Success:</dt> <dt>Reception Success:</dt>
<dd> <dd>
The TCPCL entity indicates to the BP agent when a bundle has been fully transfer red from a peer entity. The TCPCL entity indicates to the BPA when a bundle has been fully transferred f rom a peer entity.
</dd> </dd>
<dt>Reception Intermediate Progress:</dt> <dt>Reception Intermediate Progress:</dt>
<dd> <dd>
The TCPCL entity indicates to the BP agent on intermediate progress of transfer from the peer entity. The TCPCL entity indicates to the BPA the intermediate progress of a transfer fr om the peer entity.
This intermediate progress is at the granularity of each transferred segment. This intermediate progress is at the granularity of each transferred segment.
Intermediate reception indication allows a BP agent the chance to inspect bundle header contents before the entire bundle is available, and thus supports the "R eception Interruption" capability. 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 "In terrupt Reception" capability.
</dd> </dd>
<dt>Reception Failure:</dt> <dt>Reception Failure:</dt>
<dd> <dd>
The TCPCL entity indicates to the BP agent on certain reasons for reception fail ure, 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 entity indicates to the BPA certain reasons for reception failure, not ably when the local entity rejects an attempted transfer for some local policy r eason or when a TCPCL session ends before transfer success.
The TCPCL itself does not have a notion of transfer timeout. The TCPCL itself does not have a notion of transfer timeout.
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-protocol-session"> <section anchor="sec-protocol-session">
<name>TCPCL Session Overview</name> <name>TCPCL Session Overview</name>
<t> <t>
First, one entity establishes a TCPCL session to the other by initiating a TCP c onnection in accordance with <xref target="RFC0793"/>. First, one entity establishes a TCPCL session to the other by initiating a TCP c onnection in accordance with <xref target="RFC0793"/>.
After setup of the TCP connection is complete, an initial Contact Header is exch anged in both directions to establish a shared TCPCL version and negotiate the u se of TLS security (as described in <xref target="sec-session-establishment"/>). After setup of the TCP connection is complete, an initial Contact Header is exch anged in both directions to establish a shared TCPCL version and negotiate the u se of TLS security (as described in <xref target="sec-session-establishment"/>).
Once contact negotiation is complete, TCPCL messaging is available and the sessi on negotiation is used to set parameters of the TCPCL session. Once contact negotiation is complete, TCPCL messaging is available and the sessi on negotiation is used to set parameters of the TCPCL session.
One of these parameters is a Node ID that each TCPCL Entity is acting as. One of these parameters is a node ID; each TCPCL entity is acting on behalf of a
This is used to assist in routing and forwarding messages by the BP Agent and is BPA having a node ID.
part of the authentication capability provided by TLS. This is used to assist in routing and forwarding messages by the BPA and is part
of the authentication capability provided by TLS.
</t> </t>
<t> <t>
Once negotiated, the parameters of a TCPCL session cannot change and if there is a desire by either peer to transfer data under different parameters then a new session must be established. Once negotiated, the parameters of a TCPCL session cannot change; if there is a desire by either peer to transfer data under different parameters, then a new se ssion must be established.
This makes CL logic simpler but relies on the assumption that establishing a TCP connection is lightweight enough that TCP connection overhead is negligible com pared to TCPCL data sizes. This makes CL logic simpler but relies on the assumption that establishing a TCP connection is lightweight enough that TCP connection overhead is negligible com pared to TCPCL data sizes.
</t> </t>
<t> <t>
Once the TCPCL session is established and configured in this way, bundles can be transferred in either direction. Once the TCPCL session is established and configured in this way, bundles can be transferred in either direction.
Each transfer is performed by segmenting the transfer data into one or more XFER _SEGMENT messages. Each transfer is performed by segmenting the transfer data into one or more XFER _SEGMENT messages.
Multiple bundles can be transmitted consecutively in a single direction on a sin gle TCPCL connection. Multiple bundles can be transmitted consecutively in a single direction on a sin gle TCPCL connection.
Segments from different bundles are never interleaved. Segments from different bundles are never interleaved.
Bundle interleaving can be accomplished by fragmentation at the BP layer or by e stablishing multiple TCPCL sessions between the same peers. Bundle interleaving can be accomplished by fragmentation at the BP layer or by e stablishing multiple TCPCL sessions between the same peers.
There is no fundamental limit on the number of TCPCL sessions which a single ent ity can establish beyond the limit imposed by the number of available (ephemeral ) TCP ports of the active entity. There is no fundamental limit on the number of TCPCL sessions that a single enti ty can establish, beyond the limit imposed by the number of available (ephemeral ) TCP ports of the active entity.
</t> </t>
<t> <t>
A feature of this protocol is for the receiving entity to send acknowledgment (X One feature of this protocol is that the receiving entity can send acknowledgmen
FER_ACK) messages as bundle data segments arrive. t (XFER_ACK) messages as bundle data segments arrive.
The rationale behind these acknowledgments is to enable the transmitting entity The rationale behind these acknowledgments is to enable the transmitting entity
to determine how much of the bundle has been received, so that in case the sessi to determine how much of the bundle has been received, so that if the session is
on is interrupted, it can perform reactive fragmentation to avoid re-sending the interrupted, it can perform reactive fragmentation to avoid resending the
already transmitted part of the bundle. already-transmitted part of the bundle.
In addition, there is no explicit flow control on the TCPCL layer. In addition, there is no explicit flow control on the TCPCL.
</t> </t>
<t> <t>
A TCPCL receiver can interrupt the transmission of a bundle at any point in time by replying with a XFER_REFUSE message, which causes the sender to stop transmi ssion of the associated bundle (if it hasn't already finished transmission). A TCPCL receiver can interrupt the transmission of a bundle at any point in time by replying with a XFER_REFUSE message, which causes the sender to stop transmi ssion of the associated bundle (if it hasn't already finished transmission).
Note: This enables a cross-layer optimization in that it allows a receiver that detects that it already has received a certain bundle to interrupt transmission as early as possible and thus save transmission capacity for other bundles.
</t> </t>
<aside><t>
Note: This enables a cross-layer optimization in that it allows a receiver that
detects that it has already received a certain bundle to interrupt transmission
as early as possible and thus save transmission capacity for other bundles.
</t></aside>
<t> <t>
For sessions that are idle, a KEEPALIVE message is sent at a negotiated interval . For sessions that are idle, a KEEPALIVE message is sent at a negotiated interval .
This is used to convey entity live-ness information during otherwise message-les s time intervals. This is used to convey entity liveness information during otherwise messageless time intervals.
</t> </t>
<t> <t>
A SESS_TERM message is used to initiate the ending of a TCPCL session (see <xref target="sec-SESS_TERM"/>). A SESS_TERM message is used to initiate the ending of a TCPCL session (see <xref target="sec-SESS_TERM"/>).
During termination sequencing, in-progress transfers can be completed but no new transfers can be initiated. During termination sequencing, in-progress transfers can be completed but no new transfers can be initiated.
A SESS_TERM message can also be used to refuse a session setup by a peer (see <x ref target="sec-contact-negotiate"/>). A SESS_TERM message can also be used to refuse a session setup by a peer (see <x ref target="sec-contact-negotiate"/>).
Regardless of the reason, session termination is initiated by one of the entitie Regardless of the reason, session termination is initiated by one of the entitie
s and responded-to by the other as illustrated by <xref target="fig-sessterm-ini s and the other entity responds to it, as illustrated by Figures&nbsp;<xref tar
t"/> and <xref target="fig-sessterm-respond"/>. get="fig-sessterm-init" format="counter"/> and <xref target="fig-sessterm-respon
Even when there are no transfers queued or in-progress, the session termination d" format="counter"/> in the next subsection.
procedure allows each entity to distinguish between a clean end to a session and Even when there are no transfers queued or in progress, the session termination
the TCP connection being closed because of some underlying network issue. procedure allows each entity to distinguish between a clean end to a session and
the TCP connection being closed because of some underlying network issue.
</t> </t>
<t> <t>
Once a session is established, TCPCL is a symmetric protocol between the peers. Once a session is established, the TCPCL is a symmetric protocol between the pee rs.
Both sides can start sending data segments in a session, and one side's bundle t ransfer does not have to complete before the other side can start sending data s egments on its own. Both sides can start sending data segments in a session, and one side's bundle t ransfer does not have to complete before the other side can start sending data s egments on its own.
Hence, the protocol allows for a bi-directional mode of communication. Hence, the protocol allows for a bidirectional mode of communication.
Note that in the case of concurrent bidirectional transmission, acknowledgment s Note that in the case of concurrent bidirectional transmission, acknowledgment s
egments MAY be interleaved with data segments. egments <bcp14>MAY</bcp14> be interleaved with data segments.
</t> </t>
</section> </section>
<section anchor="sec-protocol-states"> <section anchor="sec-protocol-states">
<name>TCPCL States and Transitions</name> <name>TCPCL States and Transitions</name>
<t> <t>
The states of a normal TCPCL session (i.e., without session failures) are indica ted in <xref target="fig-session-states"/>. The states of a normal TCPCL session (i.e., without session failures) are indica ted in <xref target="fig-session-states"/>.
</t> </t>
<figure anchor="fig-session-states"> <figure anchor="fig-session-states">
<name>Top-level states of a TCPCL session</name> <name>Top-Level States of a TCPCL Session</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+-------+ +-------+
| START | | START |
+-------+ +-------+
| |
TCP Establishment TCP Establishment
| |
V V
+-----------+ +---------------------+ +-----------+ +---------------------+
| TCP |-----------&gt;| Contact / Session | | TCP |-----------&gt;| Contact / Session |
skipping to change at line 510 skipping to change at line 531
| |
+----------TCP Close Message----------+ +----------TCP Close Message----------+
| |
V V
+-------+ +-------+
| END | | END |
+-------+ +-------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
Notes on Established Session states: Notes on established session states:
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li>Session "Live" means transmitting or receiving over a transfer str eam.</li> <li>Session "Live" means transmitting or receiving over a transfer str eam.</li>
<li>Session "Idle" means no transmission/reception over a transfer str eam.</li> <li>Session "Idle" means no transmission/reception over a transfer str eam.</li>
<li>Session "Ending" means no new transfers will be allowed.</li> <li>Session "Ending" means no new transfers will be allowed.</li>
</ul> </ul>
<t> <t>
Contact negotiation involves exchanging a Contact Header (CH) in both directions Contact negotiation involves exchanging a Contact Header ("CH" in Figures&nbsp;<
and deriving a negotiated state from the two headers. xref target="fig-contact-init-active" format="counter"/>, <xref target="fig-cont
The contact negotiation sequencing is performed either as the active or passive act-init-passive" format="counter"/>, and <xref target="fig-contact-init-process
entity, and is illustrated in <xref target="fig-contact-init-active"/> and <xref " format="counter"/>) in both directions and deriving a negotiated state from th
target="fig-contact-init-passive"/> respectively which both share the data vali e two headers.
dation and negotiation of the Processing of Contact Header "[PCH]" activity of < The contact negotiation sequencing is performed as either the active or passive
xref target="fig-contact-init-process"/> and the "[TCPCLOSE]" activity which ind entity and is illustrated in Figures&nbsp;<xref target="fig-contact-init-active"
icates TCP connection close. format="counter"/> and <xref target="fig-contact-init-passive" format="counter"
Successful negotiation results in one of the Session Initiation "[SI]" activitie />, respectively, which both share the data validation and negotiation of the Pr
s being performed. ocessing of Contact Header ("[PCH]") activity (<xref target="fig-contact-init-pr
To avoid data loss, a Session Termination "[ST]" exchange allows cleanly finishi ocess"/>) and the "[TCPCLOSE]" activity, which indicates TCP connection close.
ng transfers before a session is ended. Successful negotiation results in one of the Session Initiation ("[SI]") activit
ies being performed, as shown further below.
To avoid data loss, a Session Termination ("[ST]") exchange allows cleanly finis
hing transfers before a session is ended.
</t> </t>
<figure anchor="fig-contact-init-active"> <figure anchor="fig-contact-init-active">
<name>Contact Initiation as Active Entity</name> <name>Contact Initiation as Active Entity</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+-------+ +-------+
| START | | START |
+-------+ +-------+
| |
TCP Connecting TCP Connecting
V V
skipping to change at line 583 skipping to change at line 604
V | Failure V | Failure
+-----------+ V | +-----------+ V |
| TCPCL | +---------------+ | TCPCL | +---------------+
| Messaging |&lt;--Success--| TLS Handshake | | Messaging |&lt;--Success--| TLS Handshake |
| Available | +---------------+ | Available | +---------------+
+-----------+ +-----------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
Session negotiation involves exchanging a session initialization (SESS_INIT) mes sage in both directions and deriving a negotiated state from the two messages. Session negotiation involves exchanging a session initialization (SESS_INIT) mes sage in both directions and deriving a negotiated state from the two messages.
The session negotiation sequencing is performed either as the active or passive entity, and is illustrated in <xref target="fig-sess-init-active"/> and <xref ta rget="fig-sess-init-passive"/> respectively which both share the data validation and negotiation of <xref target="fig-sess-init-process"/>. The session negotiation sequencing is performed as either the active or passive entity and is illustrated in Figures&nbsp;<xref target="fig-sess-init-active" fo rmat="counter"/> and <xref target="fig-sess-init-passive" format="counter"/>, re spectively (where "[PSI]" means "Processing of Session Initiation"), which both share the data validation and negotiation shown in <xref target="fig-sess-init-p rocess"/>.
The validation here includes certificate validation and authentication when TLS is used for the session. The validation here includes certificate validation and authentication when TLS is used for the session.
</t> </t>
<figure anchor="fig-sess-init-active"> <figure anchor="fig-sess-init-active">
<name>Session Initiation [SI] as Active Entity</name> <name>Session Initiation [SI] as Active Entity</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+-----------+ +-----------+
| TCPCL | +---------+ | TCPCL | +---------+
| Messaging |--Send SESS_INIT--&gt;| Waiting |--Timeout--&gt;[ST] | Messaging |--Send SESS_INIT--&gt;| Waiting |--Timeout--&gt;[ST]
| Available | +---------+ | Available | +---------+
+-----------+ | +-----------+ |
skipping to change at line 640 skipping to change at line 661
Success Success
V V
+--------------+ +--------------+
| Established | | Established |
| Session Idle | | Session Idle |
+--------------+ +--------------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
Transfers can occur after a session is established and it's not in the Ending st ate. Transfers can occur after a session is established and it's not in the Ending st ate.
Each transfer occurs within a single logical transfer stream between a sender an d a receiver, as illustrated in <xref target="fig-transfer-tx-states"/> and <xre f target="fig-transfer-rx-states"/> respectively. Each transfer occurs within a single logical transfer stream between a sender an d a receiver, as illustrated in Figures&nbsp;<xref target="fig-transfer-tx-state s" format="counter"/> and <xref target="fig-transfer-rx-states" format="counter" />, respectively.
</t> </t>
<figure anchor="fig-transfer-tx-states"> <figure anchor="fig-transfer-tx-states">
<name>Transfer sender states</name> <name>Transfer Sender States</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+--Send XFER_SEGMENT--+ +--Send XFER_SEGMENT--+
+--------+ | | +--------+ | |
| Stream | +-------------+ | | Stream | +-------------+ |
| Idle |---Send XFER_SEGMENT--&gt;| In Progress |&lt;------------+ | Idle |---Send XFER_SEGMENT--&gt;| In Progress |&lt;------------+
+--------+ +-------------+ +--------+ +-------------+
| |
+---------All segments sent-------+ +---------All segments sent-------+
| |
V V
+---------+ +--------+ +---------+ +--------+
| Waiting |---- Receive Final----&gt;| Stream | | Waiting |---- Receive Final----&gt;| Stream |
| for Ack | XFER_ACK | IDLE | | for Ack | XFER_ACK | Idle |
+---------+ +--------+ +---------+ +--------+
</artwork> </artwork>
</figure> </figure>
<t> <aside><t>
Notes on transfer sending: Note on transfer sending: Pipelining of transfers can occur when the sending ent
</t> ity begins a new transfer while in the "Waiting for Ack" state.
<ul empty="true" spacing="normal"> </t></aside>
<li>
Pipelining of transfers can occur when the sending entity begins a new transfer
while in the "Waiting for Ack" state.
</li>
</ul>
<figure anchor="fig-transfer-rx-states"> <figure anchor="fig-transfer-rx-states">
<name>Transfer receiver states</name> <name>Transfer Receiver States</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+-Receive XFER_SEGMENT-+ +-Receive XFER_SEGMENT-+
+--------+ | Send XFER_ACK | +--------+ | Send XFER_ACK |
| Stream | +-------------+ | | Stream | +-------------+ |
| Idle |--Receive XFER_SEGMENT--&gt;| In Progress |&lt;-------------+ | Idle |--Receive XFER_SEGMENT--&gt;| In Progress |&lt;-------------+
+--------+ +-------------+ +--------+ +-------------+
| |
+--------Sent Final XFER_ACK--------+ +--------Sent Final XFER_ACK--------+
| |
V V
+--------+ +--------+
| Stream | | Stream |
| Idle | | Idle |
+--------+ +--------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
Session termination involves one entity initiating the termination of the sessio n and the other entity acknowledging the termination. Session termination involves one entity initiating the termination of the sessio n and the other entity acknowledging the termination.
For either entity, it is the sending of the SESS_TERM message which transitions For either entity, it is the sending of the SESS_TERM message, which transitions
the session to the Ending substate. the session to the Ending substate.
While a session is in the Ending state only in-progress transfers can be complet While a session is in the Ending state, only in-progress transfers can be comple
ed and no new transfers can be started. ted and no new transfers can be started.
</t> </t>
<figure anchor="fig-sessterm-init"> <figure anchor="fig-sessterm-init">
<name>Session Termination [ST] from the Initiator</name> <name>Session Termination [ST] from the Initiator</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+-----------+ +---------+ +-----------+ +---------+
| Session |--Send SESS_TERM--&gt;| Session | | Session |--Send SESS_TERM--&gt;| Session |
| Live/Idle | | Ending | | Live/Idle | | Ending |
+-----------+ +---------+ +-----------+ +---------+
</artwork> </artwork>
</figure> </figure>
skipping to change at line 717 skipping to change at line 733
| | | |
Receive SESS_TERM | Receive SESS_TERM |
| | | |
+-------------+ +-------------+
</artwork> </artwork>
</figure> </figure>
</section> </section>
<section anchor="sec-pkix-env"> <section anchor="sec-pkix-env">
<name>PKIX Environments and CA Policy</name> <name>PKIX Environments and CA Policy</name>
<t> <t>
This specification gives requirements about how to use PKIX certificates issued This specification defines requirements regarding how to use PKIX certificates i
by a Certificate Authority (CA), but does not define any mechanisms for how thos ssued by a Certificate Authority (CA) but does not define any mechanisms for how
e certificates come to be. those certificates come to be.
The requirements about TCPCL certificate use are broad to support two quite diff The requirements regarding TCPCL certificate use are broad, to support two quite
erent PKIX environments: different PKIX environments:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>DTN-Aware CAs:</dt> <dt>DTN-Aware CAs:</dt>
<dd> <dd>
In the ideal case, the CA(s) issuing certificates for TCPCL entities are aware o In the ideal case, the CA or CAs issuing certificates for TCPCL entities are awa
f the end use of the certificate, have a mechanism for verifying ownership of a re of the end use of the certificate, have a mechanism for verifying ownership o
Node ID, and are issuing certificates directly for that Node ID. f 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 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 tr avoids the need to authenticate a network name or address and then implicitly tr
ust Node ID of the peer. ust the node ID of the peer.
The TCPCL authenticates the Node ID whenever possible and this is preferred over The TCPCL authenticates the node ID whenever possible; this is preferred over lo
lower-level PKIX identities. wer-level PKIX identities.
</dd> </dd>
<dt>DTN-Ignorant CAs:</dt> <dt>DTN-Ignorant CAs:</dt>
<dd> <dd>
It is expected that Internet-scale "public" CAs will continue to focus on DNS na mes as the preferred PKIX identifier. It is expected that Internet-scale "public" CAs will continue to focus on DNS na mes as the preferred PKIX identifier.
There are large infrastructures already in-place for managing network-level auth There are large infrastructures already in place for managing network-level auth
entication and protocols to manage identity verification in those environments < entication and protocols to manage identity verification in those environments <
xref target="RFC8555"/>. xref target="RFC8555"/>.
The TCPCL allows for this type of environment by authenticating a lower-level id The TCPCL allows for this type of environment by authenticating a lower-level id
entifier for a peer and requiring the entity to trust that the Node ID given by entifier for a peer and requiring the entity to trust that the node ID given by
the peer (during session initialization) is valid. the peer (during session initialization) is valid.
This situation is not ideal, as it allows vulnerabilities described in <xref tar This situation is not ideal, as it allows the vulnerabilities described in <xref
get="sec-threat-node-impersonation"/>, but still provides some amount of mutual target="sec-threat-node-impersonation"/>, but it still provides some amount of
authentication to take place for a TCPCL session. mutual authentication to take place for a TCPCL session.
</dd> </dd>
</dl> </dl>
<t> <t>
Even within a single TCPCL session, each entity may operate within different PKI environments and with different identifier limitations. Even within a single TCPCL session, each entity may operate within different PKI environments and with different identifier limitations.
The requirements related to identifiers in in a PKIX certificate are in <xref ta rget="sec-tls-identification"/>. The requirements related to identifiers in a PKIX certificate are provided in <x ref target="sec-tls-identification"/>.
</t> </t>
<t> <t>
It is important for interoperability that a TCPCL entity have its own security p olicy tailored to accommodate the peers with which it is expected to operate. It is important for interoperability that a TCPCL entity have its own security p olicy tailored to accommodate the peers with which it is expected to operate.
Some security policy recommendations are given in <xref target="sec-tls-auth-pol icy-rec"/> but these are meant as a starting point for tailoring. Some security policy recommendations are given in <xref target="sec-tls-auth-pol icy-rec"/>, but these are meant as a starting point for tailoring.
A strict TLS security policy is appropriate for a private network with a single shared CA. A strict TLS security policy is appropriate for a private network with a single shared CA.
Operation on the Internet (such as inter-site BP gateways) could trade more lax TCPCL security with the use of encrypted bundle encapsulation <xref target="I-D. ietf-dtn-bibect"/> to ensure strong bundle security. Operation on the Internet (such as inter-site BP gateways) could trade more lax TCPCL security with the use of encrypted bundle encapsulation <xref target="I-D. ietf-dtn-bibect"/> to ensure strong bundle security.
</t> </t>
<t> <t>
By using the Server Name Indication (SNI) DNS name (see <xref target="sec-tls-ha By using the Server Name Indication (SNI) DNS name (see <xref target="sec-tls-ha
ndshake"/>) a single passive entity can act as a convergence layer for multiple ndshake"/>), a single passive entity can act as a convergence layer for multiple
BP agents with distinct Node IDs. BPAs with distinct node IDs.
When this "virtual host" behavior is used, the DNS name is used as the indicatio When this "virtual host" behavior is used, the DNS name is used as the indicatio
n of which BP Node the active entity is attempting to communicate with. n of which BP node the active entity is attempting to communicate with.
A virtual host CL entity can be authenticated by a certificate containing all of A virtual host CL entity can be authenticated by a certificate containing all of
the DNS names and/or Node IDs being hosted or by several certificates each auth the DNS names and/or node IDs being hosted or by several certificates each auth
enticating a single DNS name and/or Node ID, using the SNI value from the peer t enticating a single DNS name and/or node ID, using the SNI value from the peer t
o select which certificate to use. o select which certificate to use.
The logic for mapping an SNI DNS name to an end-entity certificate is an impleme The logic for mapping an SNI DNS name to an end-entity certificate is an impleme
ntation matter, and can involve correlating DNS name with Node ID or other certi ntation matter and can involve correlating a DNS name with a node ID or other ce
ficate attributes. rtificate attributes.
</t> </t>
</section> </section>
<section anchor="sec-session-keeping"> <section anchor="sec-session-keeping">
<name>Session Keeping Policies</name> <name>Session-Keeping Policies</name>
<t> <t>
This specification gives requirements about how to initiate, sustain, and termin This specification defines requirements regarding how to initiate, sustain, and
ate a TCPCL session but does not impose any requirements on how sessions need to terminate a TCPCL session but does not impose any requirements on how sessions n
be managed by a BP agent. eed to be managed by a BPA.
It is a network administration matter to determine an appropriate session keepin It is a network administration matter to determine an appropriate session-keepin
g policy, but guidance given here can be used to steer policy toward performance g policy, but guidance given here can be used to steer policy toward performance
goals. goals.
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Persistent Session:</dt> <dt>Persistent Session:</dt>
<dd> <dd>
This policy preemptively establishes a single session to known entities in the n etwork and keeps the session active using KEEPALIVEs. This policy preemptively establishes a single session to known entities in the n etwork and keeps the session active using KEEPALIVEs.
Benefits of this policy include reducing the total amount of TCP data needing to Benefits of this policy include reducing the total amount of TCP data that needs
be exchanged for a set of transfers (assuming KEEPALIVE size is significantly s to be exchanged for a set of transfers (assuming that the KEEPALIVE size is sig
maller than transfer size), and allowing the session state to indicate peer conn nificantly smaller than the transfer size) and allowing the session state to ind
ectivity. icate peer connectivity.
Drawbacks include wasted network resources when a session is mostly idle or when Drawbacks include wasted network resources when a session is mostly idle or when
the network connectivity is inconsistent (which requires re-establishing failed network connectivity is inconsistent (which requires that failed sessions be r
sessions), and potential queueing issues when multiple transfers are requested eestablished), and potential queueing issues when multiple transfers are request
simultaneously. ed simultaneously.
This policy assumes that there is agreement between pairs of entities as to whic h of the peers will initiate sessions; if there is no such agreement, there is p otential for duplicate sessions to be established between peers. This policy assumes that there is agreement between pairs of entities as to whic h of the peers will initiate sessions; if there is no such agreement, there is p otential for duplicate sessions to be established between peers.
</dd> </dd>
<dt>Ephemeral Sessions:</dt> <dt>Ephemeral Sessions:</dt>
<dd> <dd>
This policy only establishes a session when an outgoing transfer is needed to be This policy only establishes a session when an outgoing transfer needs to be sen
sent. t.
Benefits of this policy include not wasting network resources on sessions which Benefits of this policy include not wasting network resources on sessions that a
are idle for long periods of time, and avoids queueing issues of a persistent se re idle for long periods of time and avoiding potential queueing issues as can b
ssion. e seen when using a single persistent session. Drawbacks include the TCP and TLS
Drawbacks include the TCP and TLS overhead of establish a new session for each t overhead of establishing a new session for each transfer.
ransfer. This policy assumes that each entity can function in a passive role to listen fo
This policy assumes that each entity can function in a passive role to listen fo r session requests from any peer that needs to send a transfer; when that is not
r session requests from any peer which needs to send a transfer; when that is no the case, the polling behavior discussed below needs to happen.
t the case the Polling behavior below needs to happen.
This policy can be augmented to keep the session established as long as any tran sfers are queued. This policy can be augmented to keep the session established as long as any tran sfers are queued.
</dd> </dd>
<dt>Active-Only Polling Sessions:</dt> <dt>Active-Only Polling Sessions:</dt>
<dd> <dd>
When naming and/or addressing of one entity is variable (i.e. dynamically assign ed IP address or domain name) or when firewall or routing rules prevent incoming TCP connections, that entity can only function in the active role. When naming and/or addressing of one entity is variable (i.e., a dynamically ass igned IP address or domain name) or when firewall or routing rules prevent incom ing TCP connections, that entity can only function in the active role.
In these cases, sessions also need to be established when an incoming transfer i s expected from a peer or based on a periodic schedule. In these cases, sessions also need to be established when an incoming transfer i s expected from a peer or based on a periodic schedule.
This polling behavior causes inefficiencies compared to as-needed ephemeral sess ions. This polling behavior causes inefficiencies compared to as-needed ephemeral sess ions.
</dd> </dd>
</dl> </dl>
<t> <t>
Many other policies can be established in a TCPCL network between the two extrem es of single persistent sessions and only ephemeral sessions. Many other policies can be established in a TCPCL network between the two extrem es of single persistent sessions and only ephemeral sessions.
Different policies can be applied to each peer entity and to each bundle as it n eeds to be transferred (e.g for quality of service). Different policies can be applied to each peer entity and to each bundle as it n eeds to be transferred (e.g., for quality of service).
Additionally, future session extension types can apply further nuance to session policies and policy negotiation. Additionally, future session extension types can apply further nuance to session policies and policy negotiation.
</t> </t>
</section> </section>
<section anchor="sec-transfer-segmentation"> <section anchor="sec-transfer-segmentation">
<name>Transfer Segmentation Policies</name> <name>Transfer Segmentation Policies</name>
<t> <t>
Each TCPCL session allows a negotiated transfer segmentation policy to be applie d in each transfer direction. Each TCPCL session allows a negotiated transfer segmentation policy to be applie d in each transfer direction.
A receiving entity can set the Segment MRU in its SESS_INIT message to determine A receiving entity can set the Segment Maximum Receive Unit (MRU) in its SESS_IN
the largest acceptable segment size, and a transmitting entity can segment a tr IT message to determine the largest acceptable segment size, and a transmitting
ansfer into any sizes smaller than the receiver's Segment MRU. entity can segment a transfer into any sizes smaller than the receiver's Segment
It is a network administration matter to determine an appropriate segmentation p MRU.
olicy for entities operating TCPCL, but guidance given here can be used to steer It is a network administration matter to determine an appropriate segmentation p
policy toward performance goals. olicy for entities using the TCPCL protocol, but guidance given here can be used
It is also advised to consider the Segment MRU in relation to chunking/packetiza to steer policy toward performance goals.
tion performed by TLS, TCP, and any intermediate network-layer nodes. Administrators are also advised to consider the Segment MRU in relation to chunk
ing/packetization performed by TLS, TCP, and any intermediate network-layer node
s.
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Minimum Overhead:</dt> <dt>Minimum Overhead:</dt>
<dd> <dd>
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 tran sfers can be sent with a single data segment (i.e., no actual segmentation). 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 tra nsfers 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-segme nt transfer policy, then receivers can avoid the necessity of segment reassembly . If the network is closed and all transmitters are known to follow a single-segme nt 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 for any associated received transfers. 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.
</dd> </dd>
<dt>Predictable Message Sizing:</dt> <dt>Predictable Message Sizing:</dt>
<dd> <dd>
In situations where the maximum message size is desired to be well-controlled, t In situations where the maximum message size is desired to be well controlled, t
he Segment MRU can be set to the largest acceptable size (the message size less he Segment MRU can be set to the largest acceptable size (the message size less
XFER_SEGMENT header size) and transmitters can always segment a transfer into ma the XFER_SEGMENT header size) and transmitters can always segment a transfer int
ximum-size chunks no larger than the Segment MRU. o maximum-size chunks no larger than the Segment MRU.
This guarantees that any single XFER_SEGMENT will not monopolize the TCP stream 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 associated w for too long, which would prevent outgoing XFER_ACK and XFER_REFUSE messages ass
ith received transfers. ociated with received transfers.
</dd> </dd>
<dt>Dynamic Segmentation:</dt> <dt>Dynamic Segmentation:</dt>
<dd> <dd>
Even after negotiation of a Segment MRU for each receiving entity, the actual tr ansfer segmentation only needs to guarantee than any individual segment is no la rger than that MRU. Even after negotiation of a Segment MRU for each receiving entity, the actual tr ansfer segmentation only needs to guarantee that any individual segment is no la rger than that MRU.
In a situation where TCP throughput is dynamic, the transfer segmentation size c an also be dynamic in order to control message transmission duration. In a situation where TCP throughput is dynamic, the transfer segmentation size c an also be dynamic in order to control message transmission duration.
</dd> </dd>
</dl> </dl>
<t> <t>
Many other policies can be established in a TCPCL network between the two extrem es of minimum overhead (large MRU, single-segment) and predictable message sizin g (small MRU, highly segmented). Many other policies can be established in a TCPCL network between the two extrem es of minimum overhead (large MRU, single segment) and predictable message sizin g (small MRU, highly segmented).
Different policies can be applied to each transfer stream to and from any partic ular entity. Different policies can be applied to each transfer stream to and from any partic ular entity.
Additionally, future session extension and transfer extension types can apply fu rther nuance to transfer policies and policy negotiation. Additionally, future session extension and transfer extension types can apply fu rther nuance to transfer policies and policy negotiation.
</t> </t>
</section> </section>
<section anchor="sec-protocol-example"> <section anchor="sec-protocol-example">
<name>Example Message Exchange</name> <name>Example Message Exchange</name>
<t> <t>
The following figure depicts the protocol exchange for a simple session, showing the session establishment and the transmission of a single bundle split into th ree data segments (of lengths "L1", "L2", and "L3") from Entity A to Entity B. <xref target="fig-contact-example"/> depicts the protocol exchange for a simple session, showing the session establishment and the transmission of a single bund le split into three data segments (of lengths "L1", "L2", and "L3") from Entity A to Entity B.
</t> </t>
<t> <t>
Note that the sending entity can transmit multiple XFER_SEGMENT messages without waiting for the corresponding XFER_ACK responses. Note that the sending entity can transmit multiple XFER_SEGMENT messages without waiting for the corresponding XFER_ACK responses.
This enables pipelining of messages on a transfer stream. This enables pipelining of messages on a transfer stream.
Although this example only demonstrates a single bundle transmission, it is also possible to pipeline multiple XFER_SEGMENT messages for different bundles witho ut necessarily waiting for XFER_ACK messages to be returned for each one. Although this example only demonstrates a single bundle transmission, it is also possible to pipeline multiple XFER_SEGMENT messages for different bundles witho ut necessarily waiting for XFER_ACK messages to be returned for each one.
However, interleaving data segments from different bundles is not allowed. However, interleaving data segments from different bundles is not allowed.
</t> </t>
<t> <t>
No errors or rejections are shown in this example. No errors or rejections are shown in this example.
</t> </t>
<figure anchor="fig-contact-example"> <figure anchor="fig-contact-example">
<name>An example of the flow of protocol messages on a single TCP Sess ion between two entities</name> <name>An Example of the Flow of Protocol Messages on a Single TCP Sess ion between Two Entities</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
Entity A Entity B Entity A Entity B
======== ======== ======== ========
+-------------------------+ +-------------------------+
| Open TCP Connection | -&gt; +-------------------------+ | Open TCP Connection | -&gt; +-------------------------+
+-------------------------+ &lt;- | Accept Connection | +-------------------------+ &lt;- | Accept Connection |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| Contact Header | -&gt; +-------------------------+ | Contact Header | -&gt; +-------------------------+
+-------------------------+ &lt;- | Contact Header | +-------------------------+ &lt;- | Contact Header |
skipping to change at line 890 skipping to change at line 905
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
| TCP Close | -&gt; &lt;- | TCP Close | | TCP Close | -&gt; &lt;- | TCP Close |
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
</artwork> </artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="sec-session-establishment"> <section anchor="sec-session-establishment">
<name>Session Establishment</name> <name>Session Establishment</name>
<t> <t>
For bundle transmissions to occur using the TCPCL, a TCPCL session MUST first be established between communicating entities. For bundle transmissions to occur using the TCPCL, a TCPCL session <bcp14>MUST</ bcp14> first be established between communicating entities.
It is up to the implementation to decide how and when session setup is triggered . It is up to the implementation to decide how and when session setup is triggered .
For example, some sessions can be opened proactively and maintained for as long as is possible given the network conditions, while other sessions are be opened only when there is a bundle that is queued for transmission and the routing algo rithm selects a certain next-hop node. For example, some sessions can be opened proactively and maintained for as long as is possible given the network conditions, while other sessions will be opened only when there is a bundle that is queued for transmission and the routing alg orithm selects a certain next-hop node.
</t> </t>
<section anchor="sec-tcp-connection"> <section anchor="sec-tcp-connection">
<name>TCP Connection</name> <name>TCP Connection</name>
<t> <t>
To establish a TCPCL session, an entity MUST first establish a TCP connection wi To establish a TCPCL session, an entity <bcp14>MUST</bcp14> first establish a TC
th the intended peer entity, typically by using the services provided by the ope P connection with the intended peer entity, typically by using the services prov
rating system. ided by the operating system.
Destination port number 4556 has been assigned by IANA as the Registered Port nu Destination port number 4556 has been assigned by IANA as the registered port nu
mber for the TCP convergence layer. mber for the TCPCL; see <xref target="sec-iana-port"/>.
Other destination port numbers MAY be used per local configuration. Other destination port numbers <bcp14>MAY</bcp14> be used per local configuratio
Determining a peer's destination port number (if different from the registered T n.
CPCL port number) is up to the implementation. Determining a peer's destination port number (if different from the registered T
Any source port number MAY be used for TCPCL sessions. CPCL port number) is left up to the implementation.
Typically an operating system assigned number in the TCP Ephemeral range (49152- Any source port number <bcp14>MAY</bcp14> be used for TCPCL sessions.
65535) is used. Typically, an operating system assigned number in the TCP Ephemeral range (49152
-65535) is used.
</t> </t>
<t> <t>
If the entity is unable to establish a TCP connection for any reason, then it is an implementation matter to determine how to handle the connection failure. If the entity is unable to establish a TCP connection for any reason, then it is an implementation matter to determine how to handle the connection failure.
An entity MAY decide to re-attempt to establish the connection. An entity <bcp14>MAY</bcp14> decide to reattempt to establish the connection.
If it does so, it MUST NOT overwhelm its target with repeated connection attempt If it does so, it <bcp14>MUST NOT</bcp14> overwhelm its target with repeated con
s. nection attempts.
Therefore, the entity MUST NOT retry the connection setup earlier than some dela Therefore, the entity <bcp14>MUST NOT</bcp14> retry the connection setup earlier
y time from the last attempt, and it SHOULD use a (binary) exponential back-off than some delay time from the last attempt, and it <bcp14>SHOULD</bcp14> use a
mechanism to increase this delay in case of repeated failures. (binary) exponential backoff mechanism to increase this delay in the case of rep
The upper limit on a re-attempt back-off is implementation defined but SHOULD be eated failures.
no longer than one minute (60 seconds) before signaling to the BP agent that a The upper limit on a reattempt backoff is implementation defined but <bcp14>SHOU
connection cannot be made. LD</bcp14> be no longer than one minute (60 seconds) before signaling to the BPA
that a connection cannot be made.
</t> </t>
<t> <t>
Once a TCP connection is established, the active entity SHALL immediately transm Once a TCP connection is established, the active entity <bcp14>SHALL</bcp14> imm
it its Contact Header. ediately transmit its Contact Header. The passive entity <bcp14>SHALL</bcp14> wa
Once a TCP connection is established, the passive entity SHALL wait for the peer it for the active entity's Contact Header.
's Contact Header. Upon reception of a Contact Header, the passive entity <bcp14>SHALL</bcp14> tran
If the passive entity does not receive a Contact Header after some implementatio smit its Contact Header.
n-defined time duration after TCP connection is established, the entity SHALL cl If either entity does not receive a Contact Header after some implementation-def
ose the TCP connection. ined time duration after the TCP connection is established, the waiting entity <
Entities SHOULD choose a Contact Header reception timeout interval no longer tha bcp14>SHALL</bcp14> close the TCP connection. Entities <bcp14>SHOULD</bcp14> cho
n one minute (60 seconds). ose a Contact Header reception timeout interval no longer than one minute (60 se
Upon reception of a Contact Header, the passive entity SHALL transmit its Contac conds).
t Header.
The ordering of the Contact Header exchange allows the passive entity to avoid a llocating resources to a potential TCPCL session until after a valid Contact Hea der has been received from the active entity. The ordering of the Contact Header exchange allows the passive entity to avoid a llocating resources to a potential TCPCL session until after a valid Contact Hea der has been received from the active entity.
This ordering also allows the passive peer to adapt to alternate TCPCL protocol versions. This ordering also allows the passive peer to adapt to alternate TCPCL protocol versions.
</t> </t>
<t> <t>
The format of the Contact Header is described in <xref target="sec-contact-heade r"/>. The format of the Contact Header is described in <xref target="sec-contact-heade r"/>.
Because the TCPCL protocol version in use is part of the initial Contact Header, entities using TCPCL version 4 can coexist on a network with entities using ear lier TCPCL versions (with some negotiation needed for interoperation as describe d in <xref target="sec-contact-negotiate"/>). Because the TCPCL protocol version in use is part of the initial Contact Header, entities using TCPCL version 4 can coexist on a network with entities using ear lier TCPCL versions (with some negotiation needed for interoperation, as describ ed in <xref target="sec-contact-negotiate"/>).
</t> </t>
<t> <t>
Within this specification when an entity is said to "close" a TCP connection the Within this specification, when an entity is said to "close" a TCP connection th
entity SHALL use the TCP FIN mechanism and not the RST mechanism. e entity <bcp14>SHALL</bcp14> use the TCP FIN mechanism and not the RST mechanis
Either mechanism, however, when received will cause a TCP connection to become c m.
losed. However, either mechanism, when received, will cause a TCP connection to become
closed.
</t> </t>
</section> </section>
<section anchor="sec-contact-header"> <section anchor="sec-contact-header">
<name>Contact Header</name> <name>Contact Header</name>
<t> <t>
This section describes the format of the Contact Header and the meaning of its f ields. This section describes the format of the Contact Header and the meaning of its f ields.
</t> </t>
<t> <t>
If the entity is configured to enable exchanging messages according to TLS 1.3 < If the entity is configured to enable the exchange of messages according to TLS
xref target="RFC8446"/> or any successors which are compatible with that TLS Cli 1.3 <xref target="RFC8446"/> or any successors that are compatible with that TLS
entHello, the the CAN_TLS flag within its Contact Header SHALL be set to 1. ClientHello, the <tt>CAN_TLS</tt> flag within its Contact Header <bcp14>SHALL</
The RECOMMENDED policy is to enable TLS for all sessions, even if security polic bcp14> be set to 1.
y does not allow or require authentication. The <bcp14>RECOMMENDED</bcp14> policy is to enable TLS for all sessions, even if
This follows the opportunistic security model of <xref target="RFC7435"/>, thoug security policy does not allow or require authentication.
h an active attacker could interfere with the exchange in such cases (see <xref This follows the "opportunistic security" model specified in <xref target="RFC74
target="sec-threat-tls-strip"/>). 35"/>, though an active attacker could interfere with the exchange in such cases
(see <xref target="sec-threat-tls-strip"/>).
</t> </t>
<t> <t>
Upon receipt of the Contact Header, both entities perform the validation and neg otiation procedures defined in <xref target="sec-contact-negotiate"/>. Upon receipt of the Contact Header, both entities perform the validation and neg otiation procedures defined in <xref target="sec-contact-negotiate"/>.
After receiving the Contact Header from the other entity, either entity MAY refu se the session by sending a SESS_TERM message with an appropriate reason code. After receiving the Contact Header from the other entity, either entity <bcp14>M AY</bcp14> refuse the session by sending a SESS_TERM message with an appropriate reason code.
</t> </t>
<t> <t>
The format for the Contact Header is as follows: The format for the Contact Header is as follows:
</t> </t>
<figure anchor="fig-contact-header"> <figure anchor="fig-contact-header">
<name>Contact Header Format</name> <name>Contact Header Format</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
skipping to change at line 958 skipping to change at line 971
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 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!' | | magic='dtn!' |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Version | Flags | | Version | Flags |
+---------------+---------------+ +---------------+---------------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
See <xref target="sec-contact-negotiate"/> for details on the use of each of the se Contact Header fields. See <xref target="sec-contact-negotiate"/> for details on the use of each of the se Contact Header fields.
</t> </t>
<t> <t>
The fields of the Contact Header are: The fields of the Contact Header are as follows:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>magic:</dt> <dt>magic:</dt>
<dd> <dd>
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). 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).
</dd> </dd>
<dt>Version:</dt> <dt>Version:</dt>
<dd> <dd>
A one-octet field value containing the value 4 (current version of the TCPCL). A one-octet field value containing the value 4 (current version of the TCPCL pro tocol).
</dd> </dd>
<dt>Flags:</dt> <dt>Flags:</dt>
<dd> <dd>
A one-octet field of single-bit flags, interpreted according to the descriptions in <xref target="tab-contact-header-flags"/>. A one-octet field of single-bit flags, interpreted according to the descriptions in <xref target="tab-contact-header-flags"/>.
All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits <bcp14>SHALL</bcp14> be set to 0 by the sender.
All reserved header flag bits SHALL be ignored by the receiver. All reserved header flag bits <bcp14>SHALL</bcp14> be ignored by the receiver.
</dd> </dd>
</dl> </dl>
<table align="center" anchor="tab-contact-header-flags"> <table align="center" anchor="tab-contact-header-flags">
<name>Contact Header Flags</name> <name>Contact Header Flags</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Code</th> <th>Code</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>CAN_TLS</td> <td><tt>CAN_TLS</tt></td>
<td>0x01</td> <td>0x01</td>
<td>If bit is set, indicates that the sending peer has enabled TLS security.</td> <td>If this bit is set, it indicates that the sending peer has ena bled TLS security.</td>
</tr> </tr>
<tr> <tr>
<td>Reserved</td> <td>Reserved</td>
<td>others</td> <td>others</td>
<td/> <td/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-contact-negotiate"> <section anchor="sec-contact-negotiate">
<name>Contact Validation and Negotiation</name> <name>Contact Validation and Negotiation</name>
<t> <t>
Upon reception of the Contact Header, each entity follows the following procedur es to ensure the validity of the TCPCL session and to negotiate values for the s ession parameters. Upon reception of the Contact Header, each entity follows the following procedur es to ensure the validity of the TCPCL session and to negotiate values for the s ession parameters.
</t> </t>
<t> <t>
If the magic string is not present or is not valid, the connection MUST be termi nated. If the "magic string" is not present or is not valid, the connection <bcp14>MUST </bcp14> be terminated.
The intent of the magic string is to provide some protection against an inadvert ent TCP connection by a different protocol than the one described in this docume nt. The intent of the magic string is to provide some protection against an inadvert ent TCP connection by a different protocol than the one described in this docume nt.
To prevent a flood of repeated connections from a misconfigured application, a p assive entity MAY deny new TCP connections from a specific peer address for a pe riod of time after one or more connections fail to provide a decodable Contact H eader. To prevent a flood of repeated connections from a misconfigured application, a p assive entity <bcp14>MAY</bcp14> deny new TCP connections from a specific peer a ddress for a period of time after one or more connections fail to provide a deco dable Contact Header.
</t> </t>
<t> <t>
The first negotiation is on the TCPCL protocol version to use. The first negotiation attempts to determine which TCPCL protocol version to use.
The active entity always sends its Contact Header first and waits for a response from the passive entity. The active entity always sends its Contact Header first and waits for a response from the passive entity.
During contact initiation, the active TCPCL entity SHALL send the highest TCPCL During contact initiation, the active TCPCL entity <bcp14>SHALL</bcp14> send the
protocol version on a first session attempt for a TCPCL peer. highest TCPCL protocol version on a first session attempt for a TCPCL peer.
If the active entity receives a Contact Header with a lower protocol version tha If the active entity receives a Contact Header with a lower protocol version tha
n the one sent earlier on the TCP connection, the TCP connection SHALL be closed n the one sent earlier on the TCP connection, the TCP connection <bcp14>SHALL</b
. cp14> be closed.
If the active entity receives a SESS_TERM message with reason of "Version Mismat If the active entity receives a SESS_TERM message with a reason code of "Version
ch", that entity MAY attempt further TCPCL sessions with the peer using earlier mismatch", that entity <bcp14>MAY</bcp14> attempt further TCPCL sessions with t
protocol version numbers in decreasing order. he peer using earlier protocol version numbers in decreasing order.
Managing multi-TCPCL-session state such as this is an implementation matter. Managing multi-TCPCL-session state such as this is an implementation matter.
</t> </t>
<t> <t>
If the passive entity receives a Contact Header containing a version that is not If the passive entity receives a Contact Header containing a version that is not
a version of the TCPCL that the entity implements, then the entity SHALL send i a version of the TCPCL protocol that the entity implements, then the entity <bc
ts Contact Header and immediately terminate the session with a reason code of "V p14>SHALL</bcp14> send its Contact Header and immediately terminate the session
ersion mismatch". with a reason code of "Version mismatch".
If the passive entity receives a Contact Header with a version that is lower tha If the passive entity receives a Contact Header with a version that is lower tha
n the latest version of the protocol that the entity implements, the entity MAY n the latest version of the protocol that the entity implements, the entity <bcp
either terminate the session (with a reason code of "Version mismatch") or adapt 14>MAY</bcp14> either terminate the session (with a reason code of "Version mism
its operation to conform to the older version of the protocol. atch") or adapt its operation to conform to the older version of the protocol.
The decision of version fall-back is an implementation matter. The decision of version fallback is an implementation matter.
</t> </t>
<t> <t>
The negotiated contact parameters defined by this specification are described in the following paragraphs. The negotiated contact parameters defined by this specification are described in the following paragraphs.
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>TCPCL Version:</dt> <dt>TCPCL Version:</dt>
<dd> <dd>
Both Contact Headers of a successful contact negotiation have identical TCPCL Ve rsion numbers as described above. Both Contact Headers of a successful contact negotiation have identical TCPCL ve rsion numbers as described above.
Only upon response of a Contact Header from the passive entity is the TCPCL prot ocol version established and session negotiation begun. Only upon response of a Contact Header from the passive entity is the TCPCL prot ocol version established and session negotiation begun.
</dd> </dd>
<dt>Enable TLS:</dt> <dt>Enable TLS:</dt>
<dd> <dd>
<t> <t>
Negotiation of the Enable TLS parameter is performed by taking the logical AND o Negotiation of the Enable TLS parameter is performed by taking the logical AND o
f the two Contact Headers' CAN_TLS flags. f the two Contact Headers' <tt>CAN_TLS</tt> flags.
A local security policy is then applied to determine of the negotiated value of A local security policy is then applied to determine whether the negotiated valu
Enable TLS is acceptable. e of Enable TLS is acceptable.
It can be a reasonable security policy to require or disallow the use of TLS dep A reasonable security policy would require or disallow the use of TLS, depending
ending upon the desired network flows. upon the desired network flows.
The RECOMMENDED policy is to require TLS for all sessions, even if security poli The <bcp14>RECOMMENDED</bcp14> policy is to require TLS for all sessions, even i
cy does not allow or require authentication. f security policy does not allow or require authentication.
Because this state is negotiated over an unsecured medium, there is a risk of a Because this state is negotiated over an unsecured medium, there is a risk of TL
TLS Stripping as described in <xref target="sec-threat-tls-strip"/>. S Stripping as described in <xref target="sec-threat-tls-strip"/>.
</t> </t>
<t> <t>
If the Enable TLS state is unacceptable, the entity SHALL terminate the session If the Enable TLS state is unacceptable, the entity <bcp14>SHALL</bcp14> termina
with a reason code of "Contact Failure". te the session with a reason code of "Contact Failure".
Note that this contact failure reason is different than a failure of TLS handsha Note that this "Contact Failure" reason is different than a failure of a TLS han
ke or TLS authentication after an agreed-upon and acceptable Enable TLS state. dshake or TLS authentication after an agreed-upon and acceptable Enable TLS stat
If the negotiated Enable TLS value is true and acceptable then TLS negotiation f e.
eature (described in <xref target="sec-session-security"/>) begins immediately f If the negotiated Enable TLS value is "true" and acceptable, then the TLS negoti
ollowing the Contact Header exchange. ation feature described in <xref target="sec-session-security"/> begins immediat
ely following the Contact Header exchange.
</t> </t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-session-security"> <section anchor="sec-session-security">
<name>Session Security</name> <name>Session Security</name>
<t> <t>
This version of the TCPCL supports establishing a Transport Layer Security (TLS) This version of the TCPCL protocol supports establishing a TLS session within an
session within an existing TCP connection. existing TCP connection.
When TLS is used within the TCPCL it affects the entire session. When TLS is used within the TCPCL, it affects the entire session.
Once TLS is established, there is no mechanism available to downgrade the TCPCL session to non-TLS operation. Once TLS is established, there is no mechanism available to downgrade the TCPCL session to non-TLS operation.
</t> </t>
<t> <t>
Once established, the lifetime of a TLS connection SHALL be bound to the lifetim Once established, the lifetime of a TLS connection <bcp14>SHALL</bcp14> be bound
e of the underlying TCP connection. to the lifetime of the underlying TCP connection.
Immediately prior to actively ending a TLS connection after TCPCL session termin Immediately prior to actively ending a TLS connection after TCPCL session termin
ation, the peer which sent the original (non-reply) SESS_TERM message SHOULD fol ation, the peer that sent the original (non-reply) SESS_TERM message <bcp14>SHOU
low the Closure Alert procedure of <xref target="RFC8446"/> to cleanly terminate LD</bcp14> follow the closure alert procedure provided in <xref target="RFC8446"
the TLS connection. /> to cleanly terminate the TLS connection.
Because each TCPCL message is either fixed-length or self-indicates its length, Because each TCPCL message is either fixed length or self-indicates its length,
the lack of a TLS Closure Alert will not cause data truncation or corruption. the lack of a TLS closure alert will not cause data truncation or corruption.
</t> </t>
<t> <t>
Subsequent TCPCL session attempts to the same passive entity MAY attempt to use the TLS session resumption feature. Subsequent TCPCL session attempts to the same passive entity <bcp14>MAY</bcp14> attempt to use the TLS session resumption feature.
There is no guarantee that the passive entity will accept the request to resume a TLS session, and the active entity cannot assume any resumption outcome. There is no guarantee that the passive entity will accept the request to resume a TLS session, and the active entity cannot assume any resumption outcome.
</t> </t>
<section anchor="sec-tls-identification"> <section anchor="sec-tls-identification">
<name>Entity Identification</name> <name>Entity Identification</name>
<t> <t>
The TCPCL uses TLS for certificate exchange in both directions to identify each entity and to allow each entity to authenticate its peer. The TCPCL uses TLS for certificate exchange in both directions to identify each entity and to allow each entity to authenticate its peer.
Each certificate can potentially identify multiple entities and there is no prob lem using such a certificate as long as the identifiers are sufficient to meet a uthentication policy (as described in later sections) for the entity which prese nts it. Each certificate can potentially identify multiple entities, and there is no pro blem using such a certificate as long as the identifiers are sufficient to meet authentication policy (as described in later sections) for the entity that prese nts it.
</t> </t>
<t> <t>
Because the PKIX environment of each TCPCL entity are likely not controlled by t he certificate end users (see <xref target="sec-pkix-env"/>), the TCPCL defines a prioritized list of what a certificate can identify about a TCPCL entity: Because the PKIX environment of each TCPCL entity is likely not controlled by th e certificate end users (see <xref target="sec-pkix-env"/>), the TCPCL defines a prioritized list of what a certificate can identify regarding a TCPCL entity:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Node ID:</dt> <dt>Node ID:</dt>
<dd> <dd>
The ideal certificate identity is the Node ID of the entity using the NODE-ID de The ideal certificate identity is the node ID of the entity using the NODE-ID, a
finition below. s defined below.
When the Node ID is identified, there is no need for any lower-level identificat When the node ID is identified, there is no need for any lower-level identificat
ion to be present (though it can still be present, and if so it is also validate ion to be present (though it can still be present, and if so it is also validate
d). d).
</dd> </dd>
<dt>DNS Name:</dt> <dt>DNS Name:</dt>
<dd> <dd>
If CA policy forbids a certificate to contain an arbitrary NODE-ID but allows a 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 t DNS-ID to be identified, then one or more stable DNS names can be identified in
he certificate. the certificate.
The use of wildcard DNS-ID is discouraged due to the complex rules for matching The use of wildcard DNS-IDs is discouraged due to the complex rules for matching
and dependence on implementation support for wildcard matching (see <xref sectio and dependence on implementation support for wildcard matching (see <xref secti
n="6.4.3" target="RFC6125"/>). on="6.4.3" target="RFC6125"/>).
</dd> </dd>
<dt>Network Address:</dt> <dt>Network Address:</dt>
<dd> <dd>
If no stable DNS name is available but a stable network address is available and CA policy allows a certificate to contain a IPADDR-ID (as defined below) then o ne or more network addresses can be identified in the certificate. 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.
</dd> </dd>
</dl> </dl>
<t> <t>
This specification defines a NODE-ID of a certificate as being the subjectAltNam This specification defines a NODE-ID of a certificate as being the subjectAltNam
e entry of type otherName with a name form of <tt>BundleEID</tt> (see <xref targ e entry of type otherName with a name form of <tt>BundleEID</tt> (see <xref targ
et="sec-pkix-oids"/>) and a value limited to a Node ID. et="sec-pkix-oids"/>) and a value limited to a node ID.
An entity SHALL ignore any otherName with a name form of <tt>BundleEID</tt> and An entity <bcp14>SHALL</bcp14> ignore any entry of type otherName with a name fo
a value which is some URI other than a Node ID. rm of <tt>BundleEID</tt> and a value that is some URI other than a node ID.
The NODE-ID is similar to the URI-ID of <xref target="RFC6125"/> but restricted The NODE-ID is similar to the URI-ID as defined in <xref target="RFC6125"/> but
to a Node ID rather than a URI with a qualified-name authority part. is restricted to a node ID rather than a URI with a qualified-name authority par
Unless specified otherwise by the definition of the URI scheme being authenticat t.
ed, URI matching of a NODE-ID SHALL use the URI comparison logic of <xref target Unless specified otherwise by the definition of the URI scheme being authenticat
="RFC3986"/> and scheme-based normalization of those schemes specified in <xref ed, URI matching of a NODE-ID <bcp14>SHALL</bcp14> use the URI comparison logic
target="I-D.ietf-dtn-bpbis"/>. provided in <xref target="RFC3986"/> and scheme-based normalization of those sch
A URI scheme can refine this "exact match" logic with rules about how Node IDs w emes specified in <xref target="RFC9171"/>.
ithin that scheme are to be compared with the certificate-authenticated NODE-ID. A URI scheme can refine this "exact match" logic with rules regarding how node I
Ds within that scheme are to be compared with the certificate-authenticated NODE
-ID.
</t> </t>
<t> <t>
This specification reuses the DNS-ID definition of <xref section="1.8" target="R FC6125"/>, which is the subjectAltName entry of type dNSName whose value is enco ded according to <xref target="RFC5280"/>. This specification reuses the DNS-ID definition in <xref section="1.8" target="R FC6125"/>, which is the subjectAltName entry of type dNSName whose value is enco ded according to <xref target="RFC5280"/>.
</t> </t>
<t> <t>
This specification defines a IPADDR-ID of a certificate as being the subjectAltN ame entry of type iPAddress whose value is encoded according to <xref target="RF C5280"/>. This specification defines an IPADDR-ID of a certificate as being the subjectAlt Name entry of type iPAddress whose value is encoded according to <xref target="R FC5280"/>.
</t> </t>
</section> </section>
<section anchor="sec-tcpcl-cert-profile"> <section anchor="sec-tcpcl-cert-profile">
<name>Certificate Profile for TCPCL</name> <name>Certificate Profile for the TCPCL</name>
<t> <t>
All end-entity certificates used by a TCPCL entity SHALL conform to <xref target All end-entity certificates used by a TCPCL entity <bcp14>SHALL</bcp14> conform
="RFC5280"/>, or any updates or successors to that profile. to <xref target="RFC5280"/>, or any updates or successors to that profile.
When an end-entity certificate is supplied, the full certification chain SHOULD When an end-entity certificate is supplied, the full certification chain <bcp14>
be included unless security policy indicates that is unnecessary. SHOULD</bcp14> be included unless security policy indicates that is unnecessary.
An entity SHOULD omit the root CA certificate (the last item of the chain) when An entity <bcp14>SHOULD</bcp14> omit the root CA certificate (the last item of t
sending a certification chain, as the recipient already has the root CA to ancho he chain) when sending a certification chain, as the recipient already has the r
r its validation. oot CA to anchor its validation.
</t> </t>
<t> <t>
The TCPCL requires Version 3 certificates due to the extensions used by this pro The TCPCL requires version 3 certificates due to the extensions used by this pro
file. file.
TCPCL entities SHALL reject as invalid Version 1 and Version 2 end-entity certif TCPCL entities <bcp14>SHALL</bcp14> reject as invalid version 1 and version 2 en
icates. d-entity certificates.
</t> </t>
<t> <t>
TCPCL entities SHALL accept certificates that contain an empty Subject field or TCPCL entities <bcp14>SHALL</bcp14> accept certificates that contain an empty Su
contain a Subject without a Common Name. bject field or contain a Subject without a Common Name.
Identity information in end-entity certificates is contained entirely in the sub Identity information in end-entity certificates is contained entirely in the sub
jectAltName extension as defined in <xref target="sec-tls-identification"/> and jectAltName extension as defined in <xref target="sec-tls-identification"/> and
below. discussed in the paragraphs below.
</t> </t>
<t> <t>
All end-entity and CA certificates used for TCPCL SHOULD contain both a Subject All end-entity and CA certificates used for the TCPCL <bcp14>SHOULD</bcp14> cont
Key Identifier and an Authority Key Identifier extension in accordance with <xre ain both a subject key identifier and an authority key identifier extension in a
f target="RFC5280"/>. ccordance with <xref target="RFC5280"/>.
TCPCL entities SHOULD NOT rely on either a Subject Key Identifier and an Authori TCPCL entities <bcp14>SHOULD NOT</bcp14> rely on either a subject key identifier
ty Key Identifier being present in any received certificate. or an authority key identifier being present in any received certificate. Inclu
Including key identifiers simplifies the work of an entity needing to assemble a ding key identifiers simplifies the work of an entity that needs to assemble a c
certification chain. ertification chain.
</t> </t>
<t> <t>
Unless prohibited by CA policy, a TCPCL end-entity certificate SHALL contain a N Unless prohibited by CA policy, a TCPCL end-entity certificate <bcp14>SHALL</bcp
ODE-ID which authenticates the Node ID of the peer. 14> contain a NODE-ID that authenticates the node ID of the peer.
When assigned one or more stable DNS names, a TCPCL end-entity certificate SHOUL When assigned one or more stable DNS names, a TCPCL end-entity certificate <bcp1
D contain DNS-ID which authenticates those (fully qualified) names. 4>SHOULD</bcp14> contain a DNS-ID that authenticates those (fully qualified) nam
When assigned one or more stable network addresses, a TCPCL end-entity certifica es.
te MAY contain IPADDR-ID which authenticates those addresses. When assigned one or more stable network addresses, a TCPCL end-entity certifica
te <bcp14>MAY</bcp14> contain an IPADDR-ID that authenticates those addresses.
</t> </t>
<t> <t>
When allowed by CA policy, a BPSec end-entity certificate SHOULD contain a PKIX When allowed by CA policy, a Bundle Protocol Security (BPSec; see <xref target="
Extended Key Usage extension in accordance with <xref section="4.2.1.12" target= RFC9172"/>) end-entity certificate <bcp14>SHOULD</bcp14> contain a PKIX Extended
"RFC5280"/>. Key Usage (EKU) extension in accordance with <xref section="4.2.1.12" target="R
When the PKIX Extended Key Usage extension is present, it SHOULD contain a key p FC5280"/>.
urpose <tt>id-kp-bundleSecurity</tt> (see <xref target="sec-pkix-oids"/>). When the PKIX EKU extension is present, it <bcp14>SHOULD</bcp14> contain the key
Although not specifically required by TCPCL, some networks or TLS implementation purpose <tt>id-kp-bundleSecurity</tt> (see <xref target="sec-pkix-oids"/>).
s assume the use of <tt>id-kp-clientAuth</tt> and <tt>id-kp-serverAuth</tt> are Although not specifically required by the TCPCL, some networks or TLS implementa
needed for, respectively, the client-side and server-side of TLS authentication. tions assume that <tt>id-kp-clientAuth</tt> and <tt>id-kp-serverAuth</tt> need t
For interoperability, a TCPCL end-entity certificate MAY contain an Extended Key o be used for the client side and the server side of TLS authentication, respect
Usage with both <tt>id-kp-clientAuth</tt> and <tt>id-kp-serverAuth</tt> values. ively.
For interoperability, a TCPCL end-entity certificate <bcp14>MAY</bcp14> contain
an EKU with both <tt>id-kp-clientAuth</tt> and <tt>id-kp-serverAuth</tt> values.
</t> </t>
<t> <t>
When allowed by CA policy, a TCPCL end-entity certificate SHOULD contain a PKIX When allowed by CA policy, a TCPCL end-entity certificate <bcp14>SHOULD</bcp14>
Key Usage extension in accordance with <xref section="4.2.1.3" target="RFC5280"/ contain a PKIX key usage extension in accordance with <xref section="4.2.1.3" ta
>. rget="RFC5280"/>.
The PKIX Key Usage bit which is consistent with TCPCL security using TLS 1.3 is The PKIX key usage bit that is consistent with TCPCL security using TLS 1.3 is d
digitalSignature. igitalSignature.
The specific algorithms used during the TLS handshake will determine which of th ose key uses are exercised. The specific algorithms used during the TLS handshake will determine which of th ose key uses are exercised.
Earlier versions of TLS can mandate use of the bits keyEncipherment or keyAgreem ent. Earlier versions of TLS can mandate the use of the keyEncipherment bit or the ke yAgreement bit.
</t> </t>
<t> <t>
When allowed by CA policy, a TCPCL end-entity certificate SHOULD contain an Onli ne Certificate Status Protocol (OCSP) URI within an Authority Information Access extension in accordance with <xref section="4.2.2.1" target="RFC5280"/>. When allowed by CA policy, a TCPCL end-entity certificate <bcp14>SHOULD</bcp14> contain an Online Certificate Status Protocol (OCSP) URI within an authority inf ormation access extension in accordance with <xref section="4.2.2.1" target="RFC 5280"/>.
</t> </t>
<section anchor="sec-pkix-oids"> <section anchor="sec-pkix-oids">
<name>PKIX OID Allocations</name> <name>PKIX OID Allocations</name>
<t> <t>
This document defines a PKIX Other Name Form identifier of <tt>id-on-bundleEID</ This document defines a PKIX Other Name Form identifier, <tt>id-on-bundleEID</tt
tt> in <xref target="sec-asn1-mod"/> which can be used as the <tt>type-id</tt> i >, in <xref target="sec-asn1-mod"/>; this identifier can be used as the <tt>type
n a subjectAltName entry of type otherName. -id</tt> in a subjectAltName entry of type otherName.
The <tt>BundleEID</tt> value associated with otherName type-id <tt>id-on-bundleE The <tt>BundleEID</tt> value associated with the otherName type-id <tt>id-on-bun
ID</tt> SHALL be a URI, encoded as an IA5String, with a scheme which is present dleEID</tt> <bcp14>SHALL</bcp14> be a URI, encoded as an IA5String, with a schem
in the IANA "Bundle Protocol URI Scheme Type" registry <xref target="IANA-BUNDLE e that is present in the IANA "Bundle Protocol URI Scheme Types" registry <xref
"/>. target="IANA-BUNDLE"/>.
Although this otherName form allows any Endpoint ID to be present, the NODE-ID d Although this Other Name Form allows any endpoint ID to be present, the NODE-ID
efined in <xref target="sec-tls-identification"/> limits its use to contain only defined in <xref target="sec-tls-identification"/> limits its use to contain onl
a Node ID. y a node ID.
</t> </t>
<t> <t>
This document defines a PKIX Extended Key Usage key purpose <tt>id-kp-bundleSecu rity</tt> in <xref target="sec-asn1-mod"/> which can be used to restrict a certi ficate's use. This document defines a PKIX EKU key purpose, <tt>id-kp-bundleSecurity</tt>, in <xref target="sec-asn1-mod"/>; this purpose can be used to restrict a certifica te's use.
The <tt>id-kp-bundleSecurity</tt> purpose can be combined with other purposes in the same certificate. The <tt>id-kp-bundleSecurity</tt> purpose can be combined with other purposes in the same certificate.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec-tls-handshake"> <section anchor="sec-tls-handshake">
<name>TLS Handshake</name> <name>TLS Handshake</name>
<t> <t>
The use of TLS is negotiated using the Contact Header as described in <xref targ The use of TLS is negotiated via the Contact Header, as described in <xref targe
et="sec-contact-negotiate"/>. t="sec-contact-negotiate"/>.
After negotiating an Enable TLS parameter of true, and before any other TCPCL me After negotiating an Enable TLS parameter of "true", and before any other TCPCL
ssages are sent within the session, the session entities SHALL begin a TLS hands messages are sent within the session, the session entities <bcp14>SHALL</bcp14>
hake in accordance with <xref target="RFC8446"/>. begin a TLS handshake in accordance with <xref target="RFC8446"/>.
By convention, this protocol uses the entity which initiated the underlying TCP By convention, this protocol uses the entity that initiated the underlying TCP c
connection (the active peer) as the "client" role of the TLS handshake request. onnection (the active peer) as the "client" role of the TLS handshake request.
</t> </t>
<t> <t>
The TLS handshake, if it occurs, is considered to be part of the contact negotia tion before the TCPCL session itself is established. The TLS handshake, if it occurs, is considered to be part of the contact negotia tion before the TCPCL session itself is established.
Specifics about sensitive data exposure are discussed in <xref target="sec-secur ity"/>. Specifics regarding exposure of sensitive data are discussed in <xref target="se c-security"/>.
</t> </t>
<t> <t>
The parameters within each TLS negotiation are implementation dependent but any TCPCL entity SHALL follow all recommended practices of BCP 195 <xref target="RFC 7525"/>, or any updates or successors that become part of BCP 195. The parameters within each TLS negotiation are implementation dependent but any TCPCL entity <bcp14>SHALL</bcp14> follow all recommended practices specified in <xref target="RFC7525">BCP 195</xref>, or any updates or successors that become part of BCP 195.
Within each TLS handshake, the following requirements apply (using the rough ord er in which they occur): Within each TLS handshake, the following requirements apply (using the rough ord er in which they occur):
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Client Hello:</dt> <dt>ClientHello:</dt>
<dd> <dd>
When a resolved DNS name was used to establish the TCP connection, the TLS Clien <t>
tHello SHOULD include a "server_name" extension in accordance with <xref target= When a resolved DNS name was used to establish the TCP connection, the TLS Clien
"RFC6066"/>. tHello <bcp14>SHOULD</bcp14> include a "server_name" extension in accordance wit
When present, the "server_name" extension SHALL contain a "HostName" value taken h <xref target="RFC6066"/>.
from the DNS name (of the passive entity) which was resolved. When present, the server_name extension <bcp14>SHALL</bcp14> contain a "HostName
Note: The "HostName" in the "server_name" extension is the network name for the " value taken from the DNS name (of the passive entity) that was resolved.
passive entity, not the Node ID of that entity. </t>
<aside><t>
Note: The "HostName" in the server_name extension is the network name for the pa
ssive entity, not the node ID of that entity.
</t></aside>
</dd> </dd>
<dt>Server Certificate:</dt> <dt>Server Certificate:</dt>
<dd> <dd>
The passive entity SHALL supply a certificate within the TLS handshake to allow The passive entity <bcp14>SHALL</bcp14> supply a certificate within the TLS hand
authentication of its side of the session. shake to allow authentication of its side of the session.
The supplied end-entity certificate SHALL conform to the profile of <xref target The supplied end-entity certificate <bcp14>SHALL</bcp14> conform to the profile
="sec-tcpcl-cert-profile"/>. described in <xref target="sec-tcpcl-cert-profile"/>.
The passive entity MAY use the SNI DNS name to choose an appropriate server-side The passive entity <bcp14>MAY</bcp14> use the SNI DNS name to choose an appropri
certificate which authenticates that DNS name. ate server-side certificate that authenticates that DNS name.
</dd> </dd>
<dt>Certificate Request:</dt> <dt>Certificate Request:</dt>
<dd> <dd>
During TLS handshake, the passive entity SHALL request a client-side certificate . During the TLS handshake, the passive entity <bcp14>SHALL</bcp14> request a clie nt-side certificate.
</dd> </dd>
<dt>Client Certificate:</dt> <dt>Client Certificate:</dt>
<dd> <dd>
The active entity SHALL supply a certificate chain within the TLS handshake to a The active entity <bcp14>SHALL</bcp14> supply a certificate chain within the TLS
llow authentication of its side of the session. handshake to allow authentication of its side of the session.
The supplied end-entity certificate SHALL conform to the profile of <xref target The supplied end-entity certificate <bcp14>SHALL</bcp14> conform to the profile
="sec-tcpcl-cert-profile"/>. described in <xref target="sec-tcpcl-cert-profile"/>.
</dd> </dd>
</dl> </dl>
<t> <t>
If a TLS handshake cannot negotiate a TLS connection, both entities of the TCPCL If a TLS handshake cannot negotiate a TLS connection, both entities of the TCPCL
session SHALL close the TCP connection. session <bcp14>SHALL</bcp14> close the TCP connection.
At this point the TCPCL session has not yet been established so there is no TCPC At this point, the TCPCL session has not yet been established, so there is no TC
L session to terminate. PCL session to terminate.
</t> </t>
<t> <t>
After a TLS connection is successfully established, the active entity SHALL send a SESS_INIT message to begin session negotiation. After a TLS connection is successfully established, the active entity <bcp14>SHA LL</bcp14> send a SESS_INIT message to begin session negotiation.
This session negotiation and all subsequent messaging are secured. This session negotiation and all subsequent messaging are secured.
</t> </t>
</section> </section>
<section anchor="sec-tls-authentication"> <section anchor="sec-tls-authentication">
<name>TLS Authentication</name> <name>TLS Authentication</name>
<t> <t>
Using PKIX certificates exchanged during the TLS handshake, each of the entities can authenticate a peer Node ID directly or authenticate the peer DNS name or n etwork address. Using PKIX certificates exchanged during the TLS handshake, each of the entities can authenticate a peer node ID directly or authenticate the peer DNS name or n etwork address.
The logic for handling certificates and certificate data is separated into the f ollowing phases: The logic for handling certificates and certificate data is separated into the f ollowing phases:
</t> </t>
<ol> <ol>
<li>Validating the certification path from the end-entity certificat e up to a trusted root CA.</li> <li>Validating the certification path from the end-entity certificat e up to a trusted root CA.</li>
<li>Validating the Extended Key Usage (EKU) and other properties of the end-entity certificate.</li> <li>Validating the EKU and other properties of the end-entity certif icate.</li>
<li>Authenticating identities from a valid end-entity certificate.</ li> <li>Authenticating identities from a valid end-entity certificate.</ li>
<li>Applying security policy to the result of each identity type aut hentication.</li> <li>Applying security policy to the result of each identity type aut hentication.</li>
</ol> </ol>
<t> <t>
The result of validating a peer identity (see <xref target="sec-tls-identificati on"/>) against one or more type of certificate claim is one of the following: The result of validating a peer identity (see <xref target="sec-tls-identificati on"/>) against one or more types of certificate claims is one of the following:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Absent:</dt> <dt>Absent:</dt>
<dd> <dd>
Indicating that no such claims are present in the certificate and the identity c annot be authenticated. Indicating that no such claims are present in the certificate and the identity c annot be authenticated.
</dd> </dd>
<dt>Success:</dt> <dt>Success:</dt>
<dd> <dd>
Indicating that one or more such claims are present and at least one matches the peer identity value. Indicating that one or more such claims are present and at least one matches the peer identity value.
</dd> </dd>
<dt>Failure:</dt> <dt>Failure:</dt>
<dd> <dd>
Indicating that one or more such claims are present and none match the peer iden tity. Indicating that one or more such claims are present and none match the peer iden tity.
</dd> </dd>
</dl> </dl>
<section anchor="sec-tls-auth-valid-cert"> <section anchor="sec-tls-auth-valid-cert">
<name>Certificate Path and Purpose Validation</name> <name>Certificate Path and Purpose Validation</name>
<t> <t>
For any peer end-entity certificate received during TLS handshake, the entity SH For any peer end-entity certificate received during the TLS handshake, the entit
ALL perform the certification path validation of <xref target="RFC5280"/> up to y <bcp14>SHALL</bcp14> perform the certification path validation described in <x
one of the entity's trusted CA certificates. ref target="RFC5280"/> up to one of the entity's trusted CA certificates.
If enabled by local policy, the entity SHALL perform an OCSP check of each certi If enabled by local policy, the entity <bcp14>SHALL</bcp14> perform an OCSP chec
ficate providing OCSP authority information in accordance with <xref target="RFC k of each certificate providing OCSP authority information in accordance with <x
6960"/>. ref target="RFC6960"/>.
If certificate validation fails or if security policy disallows a certificate fo If certificate validation fails or if security policy disallows a certificate fo
r any reason, the entity SHALL fail the TLS handshake with a "bad_certificate" a r any reason, the entity <bcp14>SHALL</bcp14> fail the TLS handshake with a "bad
lert. _certificate" alert.
Leaving out part of the certification chain can cause the entity to fail to vali Leaving out part of the certification chain can cause the entity to fail to vali
date a certificate if the left-out certificates are unknown to the entity (see < date a certificate if the certificates that were left out are unknown to the ent
xref target="sec-threat-untrust-cert"/>). ity (see <xref target="sec-threat-untrust-cert"/>).
</t> </t>
<t> <t>
For the end-entity peer certificate received during TLS handshake, the entity SH For the end-entity peer certificate received during the TLS handshake, the entit
ALL apply security policy to the Key Usage extension (if present) and Extended K y <bcp14>SHALL</bcp14> apply security policy to the key usage extension (if pres
ey Usage extension (if present) in accordance with <xref section="4.2.1.12" targ ent) and EKU extension (if present) in accordance with Sections&nbsp;<xref targe
et="RFC5280"/> and the profile in <xref target="sec-tcpcl-cert-profile"/>. t="RFC5280" section="4.2.1.12" sectionFormat="bare"/> and <xref target="RFC5280"
</t> section="4.2.1.3"
sectionFormat="bare"/> of <xref target="RFC5280"/>, respectively, and with the p
rofile discussed in <xref target="sec-tcpcl-cert-profile"/> of this document.</t
>
</section> </section>
<section anchor="sec-tls-auth-valid-netid"> <section anchor="sec-tls-auth-valid-netid">
<name>Network-Level Authentication</name> <name>Network-Level Authentication</name>
<t> <t>
Either during or immediately after the TLS handshake, if required by security po licy each entity SHALL validate the following certificate identifiers together i n accordance with <xref section="6" target="RFC6125"/>: Either during or immediately after the TLS handshake, each entity, if required b y security policy, <bcp14>SHALL</bcp14> validate the following certificate ident ifiers together in accordance with <xref section="6" target="RFC6125"/>:
</t> </t>
<ul> <ul>
<li> <li>
If the active entity resolved a DNS name (of the passive entity) in order to ini tiate the TCP connection that DNS name SHALL be used as a DNS-ID reference ident ifier. If the active entity resolved a DNS name (of the passive entity) in order to ini tiate the TCP connection, that DNS name <bcp14>SHALL</bcp14> be used as a DNS-ID reference identifier.
</li> </li>
<li> <li>
The IP address of the other side of the TCP connection SHALL be used as an IPADD R-ID reference identifier. The IP address of the other side of the TCP connection <bcp14>SHALL</bcp14> be u sed as an IPADDR-ID reference identifier.
</li> </li>
</ul> </ul>
<t> <t>
If the network-level identifiers authentication result is Failure or if the resu lt is Absent and security policy requires an authenticated network-level identif ier, the entity SHALL terminate the session (with a reason code of "Contact Fail ure"). If the network-level identifier's authentication result is Failure or if the res ult is Absent and security policy requires an authenticated network-level identi fier, the entity <bcp14>SHALL</bcp14> terminate the session (with a reason code of "Contact Failure").
</t> </t>
</section> </section>
<section anchor="sec-tls-auth-valid-nodeid"> <section anchor="sec-tls-auth-valid-nodeid">
<name>Node ID Authentication</name> <name>Node ID Authentication</name>
<t> <t>
Immediately before Session Parameter Negotiation, if required by security policy Immediately before session parameter negotiation, each entity, if required by se
each entity SHALL validate the certificate NODE-ID in accordance with <xref sec curity policy, <bcp14>SHALL</bcp14> validate the certificate NODE-ID in accordan
tion="6" target="RFC6125"/> using the Node ID of the peer's SESS_INIT message as ce with <xref section="6" target="RFC6125"/> using the node ID of the peer's SES
the NODE-ID reference identifier. S_INIT message as the NODE-ID reference identifier.
If the NODE-ID validation result is Failure or if the result is Absent and secur If the NODE-ID validation result is Failure or if the result is Absent and secur
ity policy requires an authenticated Node ID, the entity SHALL terminate the ses ity policy requires an authenticated node ID, the entity <bcp14>SHALL</bcp14> te
sion (with a reason code of "Contact Failure"). rminate the session (with a reason code of "Contact Failure").
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec-tls-auth-policy-rec"> <section anchor="sec-tls-auth-policy-rec">
<name>Policy Recommendations</name> <name>Policy Recommendations</name>
<t> <t>
A RECOMMENDED security policy is to enable the use of OCSP checking during TLS h A <bcp14>RECOMMENDED</bcp14> security policy encompasses the following:</t>
andshake.
A RECOMMENDED security policy is that if an Extended Key Usage is present that i <ul spacing="normal">
t needs to contain <tt>id-kp-bundleSecurity</tt> (of <xref target="sec-pkix-oids <li>enabling the use of OCSP checking during the TLS handshake.</li>
"/>) to be usable with TCPCL security. <li>instructing that, if an EKU extension is present, the extension needs to con
A RECOMMENDED security policy is to require a validated Node ID (of <xref target tain <tt>id-kp-bundleSecurity</tt> (<xref target="sec-pkix-oids"/>) to be usable
="sec-tls-auth-valid-nodeid"/>) and to ignore any network-level identifier (of < with TCPCL security.</li>
xref target="sec-tls-auth-valid-netid"/>). <li>requiring a validated node ID (<xref target="sec-tls-auth-valid-nodeid"/>) a
</t> nd ignoring any network-level identifier (<xref target="sec-tls-auth-valid-neti
d"/>).</li>
</ul>
<t> <t>
This policy relies on and informs the certificate requirements in <xref target=" This policy relies on and informs the certificate requirements provided in <xref
sec-tls-handshake"/>. target="sec-tls-handshake"/>.
This policy assumes that a DTN-aware CA (see <xref target="sec-pkix-env"/>) will This policy assumes that a DTN-aware CA (see <xref target="sec-pkix-env"/>) will
only issue a certificate for a Node ID when it has verified that the private ke only issue a certificate for a node ID when it has verified that the private ke
y holder actually controls the DTN node; this is needed to avoid the threat iden y holder actually controls the bundle node; this is needed to avoid the threat i
tified in <xref target="sec-threat-node-impersonation"/>. dentified in <xref target="sec-threat-node-impersonation"/>.
This policy requires that a certificate contain a NODE-ID and allows the certifi cate to also contain network-level identifiers. This policy requires that a certificate contain a NODE-ID and allows the certifi cate to also contain network-level identifiers.
A tailored policy on a more controlled network could relax the requirement on No de ID validation and allow just network-level identifiers to authenticate a peer . A tailored policy on a more controlled network could relax the requirement on no de ID validation and allow just network-level identifiers to authenticate a peer .
</t> </t>
</section> </section>
<section> <section>
<name>Example TLS Initiation</name> <name>Example TLS Initiation</name>
<t> <t>
A summary of a typical TLS use is shown in the sequence in <xref target="fig-tls A summary of a typical TLS initiation is shown in the sequence in <xref target="
-example"/> below. fig-tls-example"/> below.
In this example the active peer terminates the session but termination can be in In this example, the active peer terminates the session, but termination can be
itiated from either peer. initiated from either peer.
</t> </t>
<figure anchor="fig-tls-example"> <figure anchor="fig-tls-example">
<name>A simple visual example of TCPCL TLS Establishment between two entities</name> <name>A Simple Visual Example of TCPCL TLS Establishment between Two Entities</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
Entity A Entity B Entity A Entity B
active peer passive peer active peer passive peer
+-------------------------+ +-------------------------+
| Open TCP Connection | -&gt; +-------------------------+ | Open TCP Connection | -&gt; +-------------------------+
+-------------------------+ &lt;- | Accept Connection | +-------------------------+ &lt;- | Accept Connection |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| Contact Header | -&gt; +-------------------------+ | Contact Header | -&gt; +-------------------------+
skipping to change at line 1347 skipping to change at line 1369
</section> </section>
</section> </section>
<section anchor="sec-msg-header"> <section anchor="sec-msg-header">
<name>Message Header</name> <name>Message Header</name>
<t> <t>
After the initial exchange of a Contact Header and (if TLS is negotiated to be u sed) the TLS handshake, all messages transmitted over the session are identified by a one-octet header with the following structure: After the initial exchange of a Contact Header and (if TLS is negotiated to be u sed) the TLS handshake, all messages transmitted over the session are identified by a one-octet header with the following structure:
</t> </t>
<figure anchor="fig-msg-header"> <figure anchor="fig-msg-header">
<name>Format of the Message Header</name> <name>Format of the Message Header</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---------------+ +---------------+
| Message Type | | Message Type |
+---------------+ +---------------+
</artwork> </artwork>
</figure> </figure>
<t> <t>The Message Header contains the following field:</t>
The message header fields are as follows: <dl newline="false" spacing="normal">
</t> <dt>Message Type:</dt><dd>Indicates the type of the message as per <xref targe
<dl newline="false" spacing="normal"> t="tab-msg-types"/> below.
<dt>Message Type:</dt> Encoded values are listed in <xref target="sec-iana-message-types"/>.</dd>
<dd> </dl>
Indicates the type of the message as per <xref target="tab-msg-types"/> below.
Encoded values are listed in <xref target="sec-iana-message-types"/>.
</dd>
</dl>
<table align="center" anchor="tab-msg-types"> <table align="center" anchor="tab-msg-types">
<name>TCPCL Message Types</name> <name>TCPCL Message Types</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Code</th> <th>Code</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
skipping to change at line 1406 skipping to change at line 1423
<td>XFER_ACK</td> <td>XFER_ACK</td>
<td>0x02</td> <td>0x02</td>
<td> <td>
Acknowledges reception of a data segment, as described in <xref target="sec-XFER _ACK"/>. Acknowledges reception of a data segment, as described in <xref target="sec-XFER _ACK"/>.
</td> </td>
</tr> </tr>
<tr> <tr>
<td>XFER_REFUSE</td> <td>XFER_REFUSE</td>
<td>0x03</td> <td>0x03</td>
<td> <td>
Indicates that the transmission of the current bundle SHALL be stopped, as descr ibed in <xref target="sec-XFER_REFUSE"/>. Indicates that the transmission of the current bundle <bcp14>SHALL</bcp14> be st opped, as described in <xref target="sec-XFER_REFUSE"/>.
</td> </td>
</tr> </tr>
<tr> <tr>
<td>KEEPALIVE</td> <td>KEEPALIVE</td>
<td>0x04</td> <td>0x04</td>
<td> <td>
Used to keep TCPCL session active, as described in <xref target="sec-KEEPALIVE"/ >. Used to keep the TCPCL session active, as described in <xref target="sec-KEEPALI VE"/>.
</td> </td>
</tr> </tr>
<tr> <tr>
<td>MSG_REJECT</td> <td>MSG_REJECT</td>
<td>0x06</td> <td>0x06</td>
<td> <td>
Contains a TCPCL message rejection, as described in <xref target="sec-MSG_REJECT "/>. Contains a TCPCL message rejection, as described in <xref target="sec-MSG_REJECT "/>.
</td> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-SESS_INIT"> <section anchor="sec-SESS_INIT">
<name>Session Initialization Message (SESS_INIT)</name> <name>Session Initialization Message (SESS_INIT)</name>
<t> <t>
Before a session is established and ready to transfer bundles, the session param eters are negotiated between the connected entities. Before a session is established and ready to transfer bundles, the session param eters are negotiated between the connected entities.
The SESS_INIT message is used to convey the per-entity parameters which are used together to negotiate the per-session parameters as described in <xref target=" sec-session-negotiate"/>. The SESS_INIT message is used to convey the per-entity parameters, which are use d together to negotiate the per-session parameters as described in <xref target= "sec-session-negotiate"/>.
</t> </t>
<t> <t>
The format of a SESS_INIT message is as follows in <xref target="fig-msg-SESS_IN IT-fields"/>. The format of a SESS_INIT message is shown in <xref target="fig-msg-SESS_INIT-fi elds"/>.
</t> </t>
<figure anchor="fig-msg-SESS_INIT-fields"> <figure anchor="fig-msg-SESS_INIT-fields">
<name>SESS_INIT Format</name> <name>SESS_INIT Format</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Keepalive Interval (U16) | | Keepalive Interval (U16) |
+-----------------------------+ +-----------------------------+
| Segment MRU (U64) | | Segment MRU (U64) |
skipping to change at line 1460 skipping to change at line 1477
+-----------------------------+ +-----------------------------+
| Session Extension | | Session Extension |
| Items Length (U32) | | Items Length (U32) |
+-----------------------------+ +-----------------------------+
| Session Extension | | Session Extension |
| Items (var.) | | Items (var.) |
+-----------------------------+ +-----------------------------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
The fields of the SESS_INIT message are: The fields of the SESS_INIT message are as follows:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Keepalive Interval:</dt> <dt>Keepalive Interval:</dt>
<dd> <dd>
A 16-bit unsigned integer indicating the minimum interval, in seconds, to negoti ate as the Session Keepalive using the method of <xref target="sec-session-negot iate"/>. A 16-bit unsigned integer indicating the minimum interval, in seconds, to negoti ate as the Session Keepalive using the method described in <xref target="sec-ses sion-negotiate"/>.
</dd> </dd>
<dt>Segment MRU:</dt> <dt>Segment MRU:</dt>
<dd> <dd>
A 64-bit unsigned integer indicating the largest allowable single-segment data p ayload size to be received in this session. A 64-bit unsigned integer indicating the largest allowable single-segment data p ayload size to be received in this session.
Any XFER_SEGMENT sent to this peer SHALL have a data payload no longer than the Any XFER_SEGMENT sent to this peer <bcp14>SHALL</bcp14> have a data payload no l
peer's Segment MRU. onger than the peer's Segment MRU.
The two entities of a single session MAY have different Segment MRUs, and no rel The two entities of a single session <bcp14>MAY</bcp14> have different Segment M
ation between the two is required. RUs, and no relationship between the two is required.
</dd> </dd>
<dt>Transfer MRU:</dt> <dt>Transfer MRU:</dt>
<dd> <dd>
A 64-bit unsigned integer indicating the largest allowable total-bundle data siz e to be received in this session. A 64-bit unsigned integer indicating the largest allowable total-bundle data siz e to be received in this session.
Any bundle transfer sent to this peer SHALL have a Total Bundle Length payload n o longer than the peer's Transfer MRU. Any bundle transfer sent to this peer <bcp14>SHALL</bcp14> have a Total Bundle L ength payload no longer than the peer's Transfer MRU.
This value can be used to perform proactive bundle fragmentation. This value can be used to perform proactive bundle fragmentation.
The two entities of a single session MAY have different Transfer MRUs, and no re lation between the two is required. The two entities of a single session <bcp14>MAY</bcp14> have different Transfer MRUs, and no relationship between the two is required.
</dd> </dd>
<dt>Node ID Length and Node ID Data:</dt> <dt>Node ID Length and Node ID Data:</dt>
<dd> <dd>
Together these fields represent a variable-length text string. 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. 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 Node ID rather than A zero-length node ID <bcp14>SHALL</bcp14> be used to indicate the lack of a nod
a truly empty Node ID. e ID rather than a truly empty node ID.
This case allows an entity to avoid exposing Node ID information on an untrusted This case allows an entity to avoid exposing node ID information on an untrusted
network. network.
A non-zero-length Node ID Data SHALL contain the UTF-8 encoded Node ID of the En A non-zero-length Node ID Data <bcp14>SHALL</bcp14> contain the UTF-8 encoded no
tity which sent the SESS_INIT message. de ID of the entity that sent the SESS_INIT message.
Every Node ID SHALL be a URI consistent with the requirements of <xref target="R Every node ID <bcp14>SHALL</bcp14> be a URI consistent with the requirements in
FC3986"/> and the URI schemes of the IANA "Bundle Protocol URI Scheme Type" regi <xref target="RFC3986"/> and the URI schemes of the IANA "Bundle Protocol URI Sc
stry <xref target="IANA-BUNDLE"/>. heme Types" registry <xref target="IANA-BUNDLE"/>.
The Node ID itself can be authenticated as described in <xref target="sec-tls-au The node ID itself can be authenticated as described in <xref target="sec-tls-au
thentication"/>. thentication"/>.
</dd> </dd>
<dt>Session Extension Length and Session Extension Items:</dt> <dt>Session Extension Items Length and Session Extension Items list:&n
<dd> bsp;&nbsp;</dt>
Together these fields represent protocol extension data not defined by this spec <dd>&zwsp; Together, these fields represent protocol extension data no
ification. t defined by this specification.
The Session Extension Length is the total number of octets to follow which are u The Session Extension Items Length is the total number of octets to follow that
sed to encode the Session Extension Item list. are used to encode the Session Extension Items list. The encoding of each Sessio
The encoding of each Session Extension Item is within a consistent data containe n Extension Item is within a consistent data container as described in <xref tar
r as described in <xref target="sec-session-extension"/>. get="sec-session-extension"/>.
The full set of Session Extension Items apply for the duration of the TCPCL sess ion to follow. The full set of Session Extension Items apply for the duration of the TCPCL sess ion to follow.
The order and multiplicity of these Session Extension Items is significant, as d The order and multiplicity of these Session Extension Items are significant, as
efined in the associated type specification(s). defined in the associated type specification(s).
If the content of the Session Extension Items data disagrees with the Session Ex If the content of the Session Extension Items list disagrees with the Session Ex
tension Length (e.g., the last Item claims to use more octets than are present i tension Items Length (e.g., the last item claims to use more or fewer octets tha
n the Session Extension Length), the reception of the SESS_INIT is considered to n are indicated in the Session Extension Items Length), the reception of the SES
have failed. S_INIT is considered to have failed.
</dd> </dd>
</dl> </dl>
<t> <t>
If an entity receives a peer Node ID which is not authenticated (by the procedur If an entity receives a peer node ID that is not authenticated (by the procedure
e of <xref target="sec-tls-auth-valid-nodeid"/>) that Node ID SHOULD NOT be used described in <xref target="sec-tls-auth-valid-nodeid"/>), that node ID <bcp14>S
by a BP agent for any discovery or routing functions. HOULD NOT</bcp14> be used by a BPA for any discovery or routing functions.
Trusting an unauthenticated Node ID can lead to the threat described in <xref ta Trusting an unauthenticated node ID can lead to the threat described in <xref ta
rget="sec-threat-node-impersonation"/>. rget="sec-threat-node-impersonation"/>.
</t> </t>
<t> <t>
When the active entity initiates a TCPCL session, it is likely based on routing When the active entity initiates a TCPCL session, it is likely based on routing
information which binds a Node ID to CL parameters used to initiate the session. information that binds a node ID to CL parameters used to initiate the session.
If the active entity receives a SESS_INIT with different Node ID than was intend If the active entity receives a SESS_INIT with a different node ID than was inte
ed for the TCPCL session, the session MAY be allowed to be established. nded for the TCPCL session, the session <bcp14>MAY</bcp14> be allowed to be esta
If allowed, such a session SHALL be associated with the Node ID provided in the blished.
SESS_INIT message rather than any intended value. If allowed, such a session <bcp14>SHALL</bcp14> be associated with the node ID p
rovided in the SESS_INIT message rather than any intended value.
</t> </t>
</section> </section>
<section anchor="sec-session-negotiate"> <section anchor="sec-session-negotiate">
<name>Session Parameter Negotiation</name> <name>Session Parameter Negotiation</name>
<t> <t>
An entity calculates the parameters for a TCPCL session by negotiating the value s from its own preferences (conveyed by the SESS_INIT it sent to the peer) with the preferences of the peer entity (expressed in the SESS_INIT that it received from the peer). An entity calculates the parameters for a TCPCL session by negotiating the value s from its own preferences (conveyed by the SESS_INIT it sent to the peer) with the preferences of the peer entity (expressed in the SESS_INIT that it received from the peer).
The negotiated parameters defined by this specification are described in the fol lowing paragraphs. The negotiated parameters defined by this specification are described in the fol lowing paragraphs.
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Transfer MTU and Segment MTU:</dt> <dt>Transfer MTU and Segment MTU:</dt>
<dd> <dd>
The maximum transmit unit (MTU) for whole transfers and individual segments are The Maximum Transmission Unit (MTU) for whole transfers and individual segments
identical to the Transfer MRU and Segment MRU, respectively, of the received SES is identical to the Transfer MRU and Segment MRU, respectively, of the received
S_INIT message. SESS_INIT message. A transmitting peer can send individual segments with any siz
A transmitting peer can send individual segments with any size smaller than the e smaller than the Segment MTU, depending on local policy, dynamic network condi
Segment MTU, depending on local policy, dynamic network conditions, etc. tions, etc.
Determining the size of each transmitted segment is an implementation matter. Determining the size of each transmitted segment is an implementation matter.
If either the Transfer MRU or Segment MRU is unacceptable, the entity SHALL term inate the session with a reason code of "Contact Failure". If either the Transfer MRU or Segment MRU is unacceptable, the entity <bcp14>SHA LL</bcp14> terminate the session with a reason code of "Contact Failure".
</dd> </dd>
<dt>Session Keepalive:</dt> <dt>Session Keepalive:</dt>
<dd> <dd>
<t>
Negotiation of the Session Keepalive parameter is performed by taking the minimu m of the two Keepalive Interval values from the two SESS_INIT messages. Negotiation of the Session Keepalive parameter is performed by taking the minimu m of the two Keepalive Interval values from the two SESS_INIT messages.
The Session Keepalive interval is a parameter for the behavior described in <xre The Session Keepalive Interval is a parameter for the behavior described in <xre
f target="sec-KEEPALIVE"/>. f target="sec-KEEPALIVE"/>.
If the Session Keepalive interval is unacceptable, the entity SHALL terminate th If the Session Keepalive Interval is unacceptable, the entity <bcp14>SHALL</bcp1
e session with a reason code of "Contact Failure". 4> terminate the session with a reason code of "Contact Failure".
Note: a negotiated Session Keepalive of zero indicates that KEEPALIVEs are disab </t>
led. <aside><t>
</dd> Note: A negotiated Session Keepalive of zero indicates that KEEPALIVEs are disab
led.
</t></aside>
</dd>
</dl> </dl>
<t> <t>
Once this process of parameter negotiation is completed, this protocol defines n o additional mechanism to change the parameters of an established session; to ef fect such a change, the TCPCL session MUST be terminated and a new session estab lished. Once this process of parameter negotiation is completed, this protocol defines n o additional mechanism to change the parameters of an established session; to ef fect such a change, the TCPCL session <bcp14>MUST</bcp14> be terminated and a ne w session established.
</t> </t>
</section> </section>
<section anchor="sec-session-extension"> <section anchor="sec-session-extension">
<name>Session Extension Items</name> <name>Session Extension Items</name>
<t> <t>
Each of the Session Extension Items SHALL be encoded in an identical Type-Length -Value (TLV) container form as indicated in <xref target="fig-session-extension" />. Each of the Session Extension Items <bcp14>SHALL</bcp14> be encoded in an identi cal Type-Length-Value (TLV) container form as indicated in <xref target="fig-ses sion-extension"/>.
</t> </t>
<t> <t>
The fields of the Session Extension Item are: The fields of the Session Extension Item are as follows:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Item Flags:</dt> <dt>Item Flags:</dt>
<dd> <dd>
A one-octet field containing generic bit flags about the Item, which are listed A one-octet field containing generic bit flags related to the Item, which are li
in <xref target="tab-session-extension-flags"/>. sted in <xref target="tab-session-extension-flags"/>.
All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits <bcp14>SHALL</bcp14> be set to 0 by the sender.
All reserved header flag bits SHALL be ignored by the receiver. All reserved header flag bits <bcp14>SHALL</bcp14> be ignored by the receiver.
If a TCPCL entity receives a Session Extension Item with an unknown Item Type an If a TCPCL entity receives a Session Extension Item with an unknown Item Type an
d the CRITICAL flag of 1, the entity SHALL terminate the TCPCL session with SESS d the <tt>CRITICAL</tt> flag set to 1, the entity <bcp14>SHALL</bcp14> terminate
_TERM reason code of "Contact Failure". 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 If the <tt>CRITICAL</tt> flag is 0, an entity <bcp14>SHALL</bcp14> skip over and
unknown Item Type. ignore any item with an unknown Item Type.
</dd> </dd>
<dt>Item Type:</dt> <dt>Item Type:</dt>
<dd> <dd>
A 16-bit unsigned integer field containing the type of the extension item. 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 <xref target="sec-iana-session-extension-t ype"/>). This specification does not define any extension types directly but does create an IANA registry for such codes (see <xref target="sec-iana-session-extension-ty pe"/>).
</dd> </dd>
<dt>Item Length:</dt> <dt>Item Length:</dt>
<dd> <dd>
A 16-bit unsigned integer field containing the number of Item Value octets to fo llow. A 16-bit unsigned integer field containing the number of Item Value octets to fo llow.
</dd> </dd>
<dt>Item Value:</dt> <dt>Item Value:</dt>
<dd> <dd>
A variable-length data field which is interpreted according to the associated It em Type. A variable-length data field that is interpreted according to the associated Ite m Type.
This specification places no restrictions on an extension's use of available Ite m Value data. This specification places no restrictions on an extension's use of available Ite m Value data.
Extension specifications SHOULD avoid the use of large data lengths, as no bundl e transfers can begin until the full extension data is sent. Extension specifications <bcp14>SHOULD</bcp14> avoid the use of large data lengt hs, as no bundle transfers can begin until the full extension data is sent.
</dd> </dd>
</dl> </dl>
<figure anchor="fig-session-extension"> <figure anchor="fig-session-extension">
<name>Session Extension Item Format</name> <name>Session Extension Item Format</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 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...| | Item Flags | Item Type | Item Length...|
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
skipping to change at line 1592 skipping to change at line 1610
<name>Session Extension Item Flags</name> <name>Session Extension Item Flags</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Code</th> <th>Code</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>CRITICAL</td> <td><tt>CRITICAL</tt></td>
<td>0x01</td> <td>0x01</td>
<td>If bit is set, indicates that the receiving peer must handle t he extension item.</td> <td>If this bit is set, it indicates that the receiving peer must handle the extension item.</td>
</tr> </tr>
<tr> <tr>
<td>Reserved</td> <td>Reserved</td>
<td>others</td> <td>others</td>
<td/> <td/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
skipping to change at line 1618 skipping to change at line 1636
This section describes the protocol operation for the duration of an established session, including the mechanism for transmitting bundles over the session. This section describes the protocol operation for the duration of an established session, including the mechanism for transmitting bundles over the session.
</t> </t>
<section anchor="sec-conn-upkeep"> <section anchor="sec-conn-upkeep">
<name>Upkeep and Status Messages</name> <name>Upkeep and Status Messages</name>
<section anchor="sec-KEEPALIVE"> <section anchor="sec-KEEPALIVE">
<name>Session Upkeep (KEEPALIVE)</name> <name>Session Upkeep (KEEPALIVE)</name>
<t> <t>
The protocol includes a provision for transmission of KEEPALIVE messages over th e TCPCL session to help determine if the underlying TCP connection has been disr upted. The protocol includes a provision for transmission of KEEPALIVE messages over th e TCPCL session to help determine if the underlying TCP connection has been disr upted.
</t> </t>
<t> <t>
As described in <xref target="sec-contact-negotiate"/>, a negotiated parameter o As described in <xref target="sec-session-negotiate"/>, a negotiated parameter o
f each session is the Session Keepalive interval. f each session is the Session Keepalive Interval. If the negotiated Session Keep
If the negotiated Session Keepalive is zero (i.e., one or both SESS_INIT message alive is zero (i.e., one or both SESS_INIT messages contain a zero Keepalive Int
s contains a zero Keepalive Interval), then the keepalive feature is disabled. erval), then the keepalive feature is disabled.
There is no logical minimum value for the keepalive interval (within the minimum There is no logical minimum value for the Keepalive Interval (within the minimum
imposed by the positive-value encoding), but when used for many sessions on an imposed by the positive-value encoding), but when used for many sessions on an
open, shared network a short interval could lead to excessive traffic. open, shared network, a short interval could lead to excessive traffic.
For shared network use, entities SHOULD choose a keepalive interval no shorter t For shared network use, entities <bcp14>SHOULD</bcp14> choose a Keepalive Interv
han 30 seconds. al no shorter than 30 seconds.
There is no logical maximum value for the keepalive interval (within the maximum There is no logical maximum value for the Keepalive Interval (within the maximum
imposed by the fixed-size encoding), but an idle TCP connection is liable for c imposed by the fixed-size encoding), but an idle TCP connection is liable for c
losure by the host operating system if the keepalive time is longer than tens-of losure by the host operating system if the keepalive time is longer than tens of
-minutes. minutes.
Entities SHOULD choose a keepalive interval no longer than 10 minutes (600 secon Entities <bcp14>SHOULD</bcp14> choose a Keepalive Interval no longer than 10 min
ds). utes (600 seconds).
</t> </t>
<t> <t>
Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP retransmissio ns MAY occur in case of packet loss. The chosen Keepalive Interval <bcp14>SHOULD NOT</bcp14> be too short, as TCP ret ransmissions may occur in the case of packet loss.
Those will have to be triggered by a timeout (TCP retransmission timeout (RTO)), which is dependent on the measured RTT for the TCP connection so that KEEPALIVE messages can experience noticeable latency. Those will have to be triggered by a timeout (TCP retransmission timeout (RTO)), which is dependent on the measured RTT for the TCP connection so that KEEPALIVE messages can experience noticeable latency.
</t> </t>
<t> <t>
The format of a KEEPALIVE message is a one-octet message type code of KEEPALIVE The format of a KEEPALIVE message is a one-octet Message Type code of KEEPALIVE
(as described in <xref target="tab-msg-types"/>) with no additional data. (as described in <xref target="tab-msg-types"/>) with no additional data.
Both sides SHALL send a KEEPALIVE message whenever the negotiated interval has e Both sides <bcp14>SHALL</bcp14> send a KEEPALIVE message whenever the negotiated
lapsed with no transmission of any message (KEEPALIVE or other). interval has elapsed with no transmission of any message (KEEPALIVE or other).
</t> </t>
<t> <t>
If no message (KEEPALIVE or other) has been received in a session after some imp If no message (KEEPALIVE or other) has been received in a session after some imp
lementation-defined time duration, then the entity SHALL terminate the session b lementation-defined time duration, then the entity <bcp14>SHALL</bcp14> terminat
y transmitting a SESS_TERM message (as described in <xref target="sec-SESS_TERM" e the session by transmitting a SESS_TERM message (as described in <xref target=
/>) with reason code "Idle Timeout". "sec-SESS_TERM"/>) with a reason code of "Idle timeout".
If configurable, the idle timeout duration SHOULD be no shorter than twice the k If configurable, the idle timeout duration <bcp14>SHOULD</bcp14> be no shorter t
eepalive interval. han twice the Keepalive Interval.
If not configurable, the idle timeout duration SHOULD be exactly twice the keepa If not configurable, the idle timeout duration <bcp14>SHOULD</bcp14> be exactly
live interval. twice the Keepalive Interval.
</t> </t>
</section> </section>
<section anchor="sec-MSG_REJECT"> <section anchor="sec-MSG_REJECT">
<name>Message Rejection (MSG_REJECT)</name> <name>Message Rejection (MSG_REJECT)</name>
<t> <t>
This message type is not expected to be seen in a well-functioning session. This message type is not expected to be seen in a well-functioning session.
Its purpose is to aid in troubleshooting bad entity behavior by allowing the pee r to observe why an entity is not responding as expected to its messages. Its purpose is to aid in troubleshooting bad entity behavior by allowing the pee r to observe why an entity is not responding as expected to its messages.
</t> </t>
<t> <t>
If a TCPCL entity receives a message type which is unknown to it (possibly due t If a TCPCL entity receives a message type that is unknown to it (possibly due to
o an unhandled protocol version mismatch or a incorrectly-negotiated session ext an unhandled protocol version mismatch or an incorrectly negotiated session ext
ension which defines a new message type), the entity SHALL send a MSG_REJECT mes ension that defines a new message type), the entity <bcp14>SHALL</bcp14> send a
sage with a Reason Code of "Message Type Unknown" and close the TCP connection. MSG_REJECT message with a reason code of "Message Type Unknown" and close the TC
If a TCPCL entity receives a message type which is known but is inappropriate fo P connection.
r the negotiated session parameters (possibly due to incorrectly-negotiated sess If a TCPCL entity receives a message type that is known but is inappropriate for
ion extension), the entity SHALL send a MSG_REJECT message with a Reason Code of the negotiated session parameters (possibly due to an incorrectly negotiated se
"Message Unsupported". ssion extension), the entity <bcp14>SHALL</bcp14> send a MSG_REJECT message with
If a TCPCL entity receives a message which is inappropriate for the current sess a reason code of "Message Unsupported".
ion state (e.g., a SESS_INIT after the session has already been established or a If a TCPCL entity receives a message that is inappropriate for the current sessi
n XFER_ACK message with an unknown Transfer ID), the entity SHALL send a MSG_REJ on state (e.g., a SESS_INIT after the session has already been established or a
ECT message with a Reason Code of "Message Unexpected". XFER_ACK message with an unknown Transfer ID), the entity <bcp14>SHALL</bcp14> s
end a MSG_REJECT message with a reason code of "Message Unexpected".
</t> </t>
<t> <t>
The format of a MSG_REJECT message is as follows in <xref target="fig-MSG_REJECT -fields"/>. The format of a MSG_REJECT message is shown in <xref target="fig-MSG_REJECT-fiel ds"/>.
</t> </t>
<figure anchor="fig-MSG_REJECT-fields"> <figure anchor="fig-MSG_REJECT-fields">
<name>Format of MSG_REJECT Messages</name> <name>Format of MSG_REJECT Messages</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Reason Code (U8) | | Reason Code (U8) |
+-----------------------------+ +-----------------------------+
| Rejected Message Header | | Rejected Message Header |
+-----------------------------+ +-----------------------------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
The fields of the MSG_REJECT message are: The fields of the MSG_REJECT message are as follows:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Reason Code:</dt> <dt>Reason Code:</dt>
<dd> <dd>
A one-octet refusal reason code interpreted according to the descriptions in <xr ef target="tab-MSG_REJECT-reasons"/>. A one-octet refusal reason code interpreted according to the descriptions in <xr ef target="tab-MSG_REJECT-reasons"/>.
</dd> </dd>
<dt>Rejected Message Header:</dt> <dt>Rejected Message Header:</dt>
<dd> <dd>
The Rejected Message Header is a copy of the Message Header to which the MSG_REJ ECT message is sent as a response. The Rejected Message Header is a copy of the Message Header to which the MSG_REJ ECT message is sent as a response.
</dd> </dd>
skipping to change at line 1678 skipping to change at line 1695
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Reason Code:</dt> <dt>Reason Code:</dt>
<dd> <dd>
A one-octet refusal reason code interpreted according to the descriptions in <xr ef target="tab-MSG_REJECT-reasons"/>. A one-octet refusal reason code interpreted according to the descriptions in <xr ef target="tab-MSG_REJECT-reasons"/>.
</dd> </dd>
<dt>Rejected Message Header:</dt> <dt>Rejected Message Header:</dt>
<dd> <dd>
The Rejected Message Header is a copy of the Message Header to which the MSG_REJ ECT message is sent as a response. The Rejected Message Header is a copy of the Message Header to which the MSG_REJ ECT message is sent as a response.
</dd> </dd>
</dl> </dl>
<table align="center" anchor="tab-MSG_REJECT-reasons"> <table align="center" anchor="tab-MSG_REJECT-reasons">
<name>MSG_REJECT Reason Codes</name> <name>MSG_REJECT Reason Codes</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Code</th> <th>Code</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>Message Type Unknown</td> <td>Message Type Unknown</td>
<td>0x01</td> <td>0x01</td>
<td>A message was received with a Message Type code unknown to t he TCPCL entity.</td> <td>A message was received with a Message Type code unknown to t he TCPCL entity.</td>
</tr> </tr>
<tr> <tr>
<td>Message Unsupported</td> <td>Message Unsupported</td>
<td>0x02</td> <td>0x02</td>
<td>A message was received but the TCPCL entity cannot comply wi th the message contents.</td> <td>A message was received, but the TCPCL entity cannot comply w ith the message contents.</td>
</tr> </tr>
<tr> <tr>
<td>Message Unexpected</td> <td>Message Unexpected</td>
<td>0x03</td> <td>0x03</td>
<td>A message was received while the session is in a state in wh ich the message is not expected.</td> <td>A message was received while the session is in a state in wh ich the message is not expected.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="sec-transfer"> <section anchor="sec-transfer">
<name>Bundle Transfer</name> <name>Bundle Transfer</name>
<t> <t>
All of the messages in this section are directly associated with transferring a bundle between TCPCL entities. All of the messages discussed in this section are directly associated with trans ferring a bundle between TCPCL entities.
</t> </t>
<t> <t>
A single TCPCL transfer results in a bundle (handled by the convergence layer as A single TCPCL transfer results in the exchange of a bundle (handled by the conv
opaque data) being exchanged from one entity to the other. ergence layer as opaque data) between two entities.
In TCPCL a transfer is accomplished by dividing a single bundle up into "segment In the TCPCL, a transfer is accomplished by dividing a single bundle up into "se
s" based on the receiving-side Segment MRU (see <xref target="sec-contact-header gments" based on the receiving-side Segment MRU, which is defined in <xref targe
"/>). t="sec-SESS_INIT"/>.
The choice of the length to use for segments is an implementation matter, but ea The choice of the length to use for segments is an implementation matter, but ea
ch segment MUST NOT be larger than the receiving entity's maximum receive unit ( ch segment <bcp14>MUST NOT</bcp14> be larger than the receiving entity's Segment
MRU) (see the field Segment MRU of <xref target="sec-contact-header"/>). MRU.
The first segment for a bundle is indicated by the 'START' flag and the last seg The first segment for a bundle is indicated by the <tt>START</tt> flag, and the
ment is indicated by the 'END' flag. last segment is indicated by the <tt>END</tt> flag.
</t> </t>
<t> <t>
A single transfer (and by extension a single segment) SHALL NOT contain data of A single transfer (and, by extension, a single segment) <bcp14>SHALL NOT</bcp14>
more than a single bundle. contain data of more than a single bundle.
This requirement is imposed on the agent using the TCPCL rather than TCPCL itsel This requirement is imposed on the agent using the TCPCL, rather than on the TCP
f. CL itself.
</t> </t>
<t> <t>
If multiple bundles are transmitted on a single TCPCL connection, they MUST be t ransmitted consecutively without interleaving of segments from multiple bundles. If multiple bundles are transmitted on a single TCPCL connection, they <bcp14>MU ST</bcp14> be transmitted consecutively, without the interleaving of segments fr om multiple bundles.
</t> </t>
<section anchor="sec-transfer-id"> <section anchor="sec-transfer-id">
<name>Bundle Transfer ID</name> <name>Bundle Transfer ID</name>
<t> <t>
Each of the bundle transfer messages contains a Transfer ID which is used to cor Each of the bundle transfer messages contains a Transfer ID, which is used to co
relate messages (from both sides of a transfer) for each bundle. rrelate messages (from both sides of a transfer) for each bundle.
A Transfer ID does not attempt to address uniqueness of the bundle data itself a A Transfer ID does not attempt to address uniqueness of the bundle data itself a
nd has no relation to concepts such as bundle fragmentation. nd is not related to such concepts as bundle fragmentation.
Each invocation of TCPCL by the bundle protocol agent, requesting transmission o Each invocation of the TCPCL by the BPA, requesting transmission of a bundle (fr
f a bundle (fragmentary or otherwise), results in the initiation of a single TCP agmentary or otherwise), results in the initiation of a single TCPCL transfer.
CL transfer.
Each transfer entails the sending of a sequence of some number of XFER_SEGMENT a nd XFER_ACK messages; all are correlated by the same Transfer ID. Each transfer entails the sending of a sequence of some number of XFER_SEGMENT a nd XFER_ACK messages; all are correlated by the same Transfer ID.
The sending entity originates a transfer ID and the receiving entity uses that s ame Transfer ID in acknowledgements. The sending entity originates a Transfer ID, and the receiving entity uses that same Transfer ID in acknowledgments.
</t> </t>
<t> <t>
Transfer IDs from each entity SHALL be unique within a single TCPCL session. Transfer IDs from each entity <bcp14>SHALL</bcp14> be unique within a single TCP
Upon exhaustion of the entire 64-bit Transfer ID space, the sending entity SHALL CL session.
terminate the session with SESS_TERM reason code "Resource Exhaustion". Upon exhaustion of the entire 64-bit Transfer ID space, the sending entity <bcp1
For bidirectional bundle transfers, a TCPCL entity SHOULD NOT rely on any relati 4>SHALL</bcp14> terminate the session with a SESS_TERM reason code of "Resource
on between Transfer IDs originating from each side of the TCPCL session. Exhaustion".
For bidirectional bundle transfers, a TCPCL entity <bcp14>SHOULD NOT</bcp14> rel
y on any relationship between Transfer IDs originating from each side of the TCP
CL session.
</t> </t>
<t> <t>
Although there is not a strict requirement for Transfer ID initial values or ord ering (see <xref target="sec-security-xferid"/>), in the absence of any other me chanism for generating Transfer IDs an entity SHALL use the following algorithm: The initial Transfer ID from each entity is zero and subsequent Transfer ID val ues are incremented from the prior Transfer ID value by one. Although there is not a strict requirement for initial Transfer ID values or the ordering of Transfer IDs (see <xref target="sec-security-xferid"/>), in the abs ence of any other mechanism for generating Transfer IDs, an entity <bcp14>SHALL< /bcp14> use the following algorithm: the initial Transfer ID from each entity is zero, and subsequent Transfer ID values are incremented from the prior Transfer ID value by one.
</t> </t>
</section> </section>
<section anchor="sec-XFER_SEGMENT"> <section anchor="sec-XFER_SEGMENT">
<name>Data Transmission (XFER_SEGMENT)</name> <name>Data Transmission (XFER_SEGMENT)</name>
<t> <t>
Each bundle is transmitted in one or more data segments. Each bundle is transmitted in one or more data segments.
The format of a XFER_SEGMENT message follows in <xref target="fig-XFER_SEGMENT-f ields"/>. The format of a XFER_SEGMENT message is shown in <xref target="fig-XFER_SEGMENT- fields"/>.
</t> </t>
<figure anchor="fig-XFER_SEGMENT-fields"> <figure anchor="fig-XFER_SEGMENT-fields">
<name>Format of XFER_SEGMENT Messages</name> <name>Format of XFER_SEGMENT Messages</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+------------------------------+ +------------------------------+
| Message Header | | Message Header |
+------------------------------+ +------------------------------+
| Message Flags (U8) | | Message Flags (U8) |
+------------------------------+ +------------------------------+
| Transfer ID (U64) | | Transfer ID (U64) |
skipping to change at line 1774 skipping to change at line 1792
| Items (var.) | | Items (var.) |
| (only for START segment) | | (only for START segment) |
+------------------------------+ +------------------------------+
| Data length (U64) | | Data length (U64) |
+------------------------------+ +------------------------------+
| Data contents (octet string) | | Data contents (octet string) |
+------------------------------+ +------------------------------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
The fields of the XFER_SEGMENT message are: The fields of the XFER_SEGMENT message are as follows:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Message Flags:</dt> <dt>Message Flags:</dt>
<dd> <dd>
A one-octet field of single-bit flags, interpreted according to the descriptions in <xref target="tab-XFER_SEGMENT-flags"/>. A one-octet field of single-bit flags, interpreted according to the descriptions in <xref target="tab-XFER_SEGMENT-flags"/>.
All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits <bcp14>SHALL</bcp14> be set to 0 by the sender.
All reserved header flag bits SHALL be ignored by the receiver. All reserved header flag bits <bcp14>SHALL</bcp14> be ignored by the receiver.
</dd> </dd>
<dt>Transfer ID:</dt> <dt>Transfer ID:</dt>
<dd> <dd>
A 64-bit unsigned integer identifying the transfer being made. A 64-bit unsigned integer identifying the transfer being made.
</dd> </dd>
<dt>Transfer Extension Length and Transfer Extension Items:</dt> <dt>Transfer Extension Items Length and Transfer Extension Items lis
<dd> t:</dt>
Together these fields represent protocol extension data for this specification. <dd>&zwsp; Together, these fields represent protocol extension data
The Transfer Extension Length and Transfer Extension Item fields SHALL only be p for this specification.
resent when the 'START' flag is set to 1 on the message. The Transfer Extension Items Length and Transfer Extension Items list <bcp14>SHA
The Transfer Extension Length is the total number of octets to follow which are LL</bcp14> only be present when the <tt>START</tt> flag is set to 1 on the messa
used to encode the Transfer Extension Item list. ge.
The encoding of each Transfer Extension Item is within a consistent data contain The Transfer Extension Items Length is the total number of octets to follow that
er as described in <xref target="sec-transfer-extension"/>. are used to encode the Transfer Extension Items list.
The full set of transfer extension items apply only to the associated single tra The encoding of each Transfer Extension Item is within a consistent data contain
nsfer. er, as described in <xref target="sec-transfer-extension"/>.
The order and multiplicity of these transfer extension items is significant, as The full set of Transfer Extension Items apply only to the associated single tra
defined in the associated type specification(s). nsfer.
If the content of the Transfer Extension Items data disagrees with the Transfer The order and multiplicity of these Transfer Extension Items are significant, as
Extension Length (e.g., the last Item claims to use more octets than are present defined in the associated type specification(s).
in the Transfer Extension Length), the reception of the XFER_SEGMENT is conside If the content of the Transfer Extension Items list disagrees with the Transfer
red to have failed. Extension Items Length (e.g., the last item claims to use more or fewer octets t
han are indicated in the Transfer Extension Items Length), the reception of the
XFER_SEGMENT is considered to have failed.
</dd> </dd>
<dt>Data length:</dt> <dt>Data length:</dt>
<dd> <dd>
A 64-bit unsigned integer indicating the number of octets in the Data contents t o follow. A 64-bit unsigned integer indicating the number of octets in Data contents to fo llow.
</dd> </dd>
<dt>Data contents:</dt> <dt>Data contents:</dt>
<dd> <dd>
The variable-length data payload of the message. The variable-length data payload of the message.
</dd> </dd>
</dl> </dl>
<table align="center" anchor="tab-XFER_SEGMENT-flags"> <table align="center" anchor="tab-XFER_SEGMENT-flags">
<name>XFER_SEGMENT Flags</name> <name>XFER_SEGMENT Flags</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Code</th> <th>Code</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>END</td> <td><tt>END</tt></td>
<td>0x01</td> <td>0x01</td>
<td>If bit is set, indicates that this is the last segment of th e transfer.</td> <td>If this bit is set, it indicates that this is the last segme nt of the transfer.</td>
</tr> </tr>
<tr> <tr>
<td>START</td> <td><tt>START</tt></td>
<td>0x02</td> <td>0x02</td>
<td>If bit is set, indicates that this is the first segment of t he transfer.</td> <td>If this bit is set, it indicates that this is the first segm ent of the transfer.</td>
</tr> </tr>
<tr> <tr>
<td>Reserved</td> <td>Reserved</td>
<td>others</td> <td>others</td>
<td/> <td/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The flags portion of the message contains two flag values in the two low-order b The flags portion of the message contains two flag values in the two low-order b
its, denoted 'START' and 'END' in <xref target="tab-XFER_SEGMENT-flags"/>. its, denoted <tt>START</tt> and <tt>END</tt> in <xref target="tab-XFER_SEGMENT-f
The 'START' flag SHALL be set to 1 when transmitting the first segment of a tran lags"/>.
sfer. The <tt>START</tt> flag <bcp14>SHALL</bcp14> be set to 1 when transmitting the f
The 'END' flag SHALL be set to 1 when transmitting the last segment of a transfe irst segment of a transfer.
r. The <tt>END</tt> flag <bcp14>SHALL</bcp14> be set to 1 when transmitting the las
In the case where an entire transfer is accomplished in a single segment, both t t segment of a transfer.
he 'START' and 'END' flags SHALL be set to 1. In the case where an entire transfer is accomplished in a single segment, both t
he <tt>START</tt> flag and the <tt>END</tt> flag <bcp14>SHALL</bcp14> be set to
1.
</t> </t>
<t> <t>
Once a transfer of a bundle has commenced, the entity MUST only send segments co ntaining sequential portions of that bundle until it sends a segment with the 'E ND' flag set to 1. Once a transfer of a bundle has commenced, the entity <bcp14>MUST</bcp14> only s end segments containing sequential portions of that bundle until it sends a segm ent with the <tt>END</tt> flag set to 1.
No interleaving of multiple transfers from the same entity is possible within a single TCPCL session. No interleaving of multiple transfers from the same entity is possible within a single TCPCL session.
Simultaneous transfers between two entities MAY be achieved using multiple TCPCL sessions. Simultaneous transfers between two entities <bcp14>MAY</bcp14> be achieved using multiple TCPCL sessions.
</t> </t>
</section> </section>
<section anchor="sec-XFER_ACK"> <section anchor="sec-XFER_ACK">
<name>Data Acknowledgments (XFER_ACK)</name> <name>Data Acknowledgments (XFER_ACK)</name>
<t> <t>
Although the TCP transport provides reliable transfer of data between transport peers, the typical BSD sockets interface provides no means to inform a sending a pplication of when the receiving application has processed some amount of transm itted data. Although the TCP transport provides reliable transfer of data between transport peers, the typical BSD sockets interface provides no means to inform a sending a pplication of when the receiving application has processed some amount of transm itted data.
Thus, after transmitting some data, the TCPCL needs an additional mechanism to d etermine whether the receiving agent has successfully received and fully process ed the segment. Thus, after transmitting some data, the TCPCL needs an additional mechanism to d etermine whether the receiving agent has successfully received and fully process ed the segment.
To this end, the TCPCL protocol provides feedback messaging whereby a receiving entity transmits acknowledgments of reception of data segments. To this end, the TCPCL protocol provides feedback messaging whereby a receiving entity transmits acknowledgments of reception of data segments.
</t> </t>
<t> <t>
The format of an XFER_ACK message follows in <xref target="fig-XFER_ACK-fields"/ >. The format of a XFER_ACK message is shown in <xref target="fig-XFER_ACK-fields"/ >.
</t> </t>
<figure anchor="fig-XFER_ACK-fields"> <figure anchor="fig-XFER_ACK-fields">
<name>Format of XFER_ACK Messages</name> <name>Format of XFER_ACK Messages</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Message Flags (U8) | | Message Flags (U8) |
+-----------------------------+ +-----------------------------+
| Transfer ID (U64) | | Transfer ID (U64) |
+-----------------------------+ +-----------------------------+
| Acknowledged length (U64) | | Acknowledged length (U64) |
+-----------------------------+ +-----------------------------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
The fields of the XFER_ACK message are: The fields of the XFER_ACK message are as follows:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Message Flags:</dt> <dt>Message Flags:</dt>
<dd> <dd>
A one-octet field of single-bit flags, interpreted according to the descriptions in <xref target="tab-XFER_SEGMENT-flags"/>. A one-octet field of single-bit flags, interpreted according to the descriptions in <xref target="tab-XFER_SEGMENT-flags"/>.
All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits <bcp14>SHALL</bcp14> be set to 0 by the sender.
All reserved header flag bits SHALL be ignored by the receiver. All reserved header flag bits <bcp14>SHALL</bcp14> be ignored by the receiver.
</dd> </dd>
<dt>Transfer ID:</dt> <dt>Transfer ID:</dt>
<dd> <dd>
A 64-bit unsigned integer identifying the transfer being acknowledged. A 64-bit unsigned integer identifying the transfer being acknowledged.
</dd> </dd>
<dt>Acknowledged length:</dt> <dt>Acknowledged length:</dt>
<dd> <dd>
A 64-bit unsigned integer indicating the total number of octets in the transfer which are being acknowledged. A 64-bit unsigned integer indicating the total number of octets in the transfer that are being acknowledged.
</dd> </dd>
</dl> </dl>
<t> <t>
A receiving TCPCL entity SHALL send an XFER_ACK message in response to each rece A receiving TCPCL entity <bcp14>SHALL</bcp14> send a XFER_ACK message in respons
ived XFER_SEGMENT message after the segment has been fully processed. e to each received XFER_SEGMENT message after the segment has been fully process
The flags portion of the XFER_ACK header SHALL be set to match the corresponding ed.
XFER_SEGMENT message being acknowledged (including flags not decodable to the e The flags portion of the XFER_ACK header <bcp14>SHALL</bcp14> be set to match th
ntity). e corresponding XFER_SEGMENT message being acknowledged (including flags not dec
The acknowledged length of each XFER_ACK contains the sum of the data length fie odable to the entity).
lds of all XFER_SEGMENT messages received so far in the course of the indicated The acknowledged length of each XFER_ACK contains the sum of the Data length fie
transfer. lds of all XFER_SEGMENT messages received so far in the course of the indicated
The sending entity SHOULD transmit multiple XFER_SEGMENT messages without waitin transfer.
g for the corresponding XFER_ACK responses. The sending entity <bcp14>SHOULD</bcp14> transmit multiple XFER_SEGMENT messages
without waiting for the corresponding XFER_ACK responses.
This enables pipelining of messages on a transfer stream. This enables pipelining of messages on a transfer stream.
</t> </t>
<t> <t>
For example, suppose the sending entity transmits four segments of bundle data w ith lengths 100, 200, 500, and 1000, respectively. For example, suppose the sending entity transmits four segments of bundle data w ith lengths 100, 200, 500, and 1000, respectively.
After receiving the first segment, the entity sends an acknowledgment of length 100. After receiving the first segment, the entity sends an acknowledgment of length 100.
After the second segment is received, the entity sends an acknowledgment of leng th 300. After the second segment is received, the entity sends an acknowledgment of leng th 300.
The third and fourth acknowledgments are of length 800 and 1800, respectively. The third and fourth acknowledgments are of lengths 800 and 1800, respectively.
</t> </t>
<t> <t>
</t> </t>
</section> </section>
<section anchor="sec-XFER_REFUSE"> <section anchor="sec-XFER_REFUSE">
<name>Transfer Refusal (XFER_REFUSE)</name> <name>Transfer Refusal (XFER_REFUSE)</name>
<t> <t>
The TCPCL supports a mechanism by which a receiving entity can indicate to the s ender that it does not want to receive the corresponding bundle. The TCPCL supports a mechanism by which a receiving entity can indicate to the s ender that it does not want to receive the corresponding bundle.
To do so, upon receiving an XFER_SEGMENT message, the entity MAY transmit a XFER To do so, upon receiving a XFER_SEGMENT message, the entity <bcp14>MAY</bcp14> t
_REFUSE message. ransmit a XFER_REFUSE message.
As data segments and acknowledgments can cross on the wire, the bundle that is b As data segments and acknowledgments can cross on the wire, the bundle that is b
eing refused SHALL be identified by the Transfer ID of the refusal. eing refused <bcp14>SHALL</bcp14> be identified by the Transfer ID of the refusa
l.
</t> </t>
<t> <t>
There is no required relation between the Transfer MRU of a TCPCL entity (which is supposed to represent a firm limitation of what the entity will accept) and s ending of a XFER_REFUSE message. There is no required relationship between the Transfer MRU of a TCPCL entity (wh ich is supposed to represent a firm limitation of what the entity will accept) a nd the sending of a XFER_REFUSE message.
A XFER_REFUSE can be used in cases where the agent's bundle storage is temporari ly depleted or somehow constrained. A XFER_REFUSE can be used in cases where the agent's bundle storage is temporari ly depleted or somehow constrained.
A XFER_REFUSE can also be used after the bundle header or any bundle data is ins pected by an agent and determined to be unacceptable. A XFER_REFUSE can also be used after the bundle header or any bundle data is ins pected by an agent and determined to be unacceptable.
</t> </t>
<t> <t>
A transfer receiver MAY send an XFER_REFUSE message as soon as it receives any X A transfer receiver <bcp14>MAY</bcp14> send a XFER_REFUSE message as soon as it
FER_SEGMENT message. receives any XFER_SEGMENT message.
The transfer sender MUST be prepared for this and MUST associate the refusal wit The transfer sender <bcp14>MUST</bcp14> be prepared for this and <bcp14>MUST</bc
h the correct bundle via the Transfer ID fields. p14> associate the refusal with the correct bundle via the Transfer ID fields.
</t> </t>
<t> <t>
The TCPCL itself does not have any required behavior to respond to an XFER_REFUS The TCPCL itself does not have any required behavior related to responding to a
E based on its Reason Code; the refusal is passed up as an indication to the BP XFER_REFUSE based on its reason code; the refusal is passed up as an indication
agent that the transfer has been refused. to the BPA that the transfer has been refused.
If a transfer refusal has a Reason Code which is not decodable to the BP agent, If a transfer refusal has a reason code that is not decodable to the BPA, the ag
the agent SHOULD treat the refusal as having an Unknown reason. ent <bcp14>SHOULD</bcp14> treat the refusal as having a reason code of "Unknown"
.
</t> </t>
<t> <t>
The format of the XFER_REFUSE message is as follows in <xref target="fig-msg-XFE R_REFUSE"/>. The format of the XFER_REFUSE message is shown in <xref target="fig-msg-XFER_REF USE"/>.
</t> </t>
<figure anchor="fig-msg-XFER_REFUSE"> <figure anchor="fig-msg-XFER_REFUSE">
<name>Format of XFER_REFUSE Messages</name> <name>Format of XFER_REFUSE Messages</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Reason Code (U8) | | Reason Code (U8) |
+-----------------------------+ +-----------------------------+
| Transfer ID (U64) | | Transfer ID (U64) |
+-----------------------------+ +-----------------------------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
The fields of the XFER_REFUSE message are: The fields of the XFER_REFUSE message are as follows:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Reason Code:</dt> <dt>Reason Code:</dt>
<dd> <dd>
A one-octet refusal reason code interpreted according to the descriptions in <xr ef target="tab-XFER_REFUSE-reasons"/>. A one-octet refusal reason code interpreted according to the descriptions in <xr ef target="tab-XFER_REFUSE-reasons"/>.
</dd> </dd>
<dt>Transfer ID:</dt> <dt>Transfer ID:</dt>
<dd> <dd>
A 64-bit unsigned integer identifying the transfer being refused. A 64-bit unsigned integer identifying the transfer being refused.
</dd> </dd>
skipping to change at line 1952 skipping to change at line 1969
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Reason Code:</dt> <dt>Reason Code:</dt>
<dd> <dd>
A one-octet refusal reason code interpreted according to the descriptions in <xr ef target="tab-XFER_REFUSE-reasons"/>. A one-octet refusal reason code interpreted according to the descriptions in <xr ef target="tab-XFER_REFUSE-reasons"/>.
</dd> </dd>
<dt>Transfer ID:</dt> <dt>Transfer ID:</dt>
<dd> <dd>
A 64-bit unsigned integer identifying the transfer being refused. A 64-bit unsigned integer identifying the transfer being refused.
</dd> </dd>
</dl> </dl>
<table align="center" anchor="tab-XFER_REFUSE-reasons"> <table align="center" anchor="tab-XFER_REFUSE-reasons">
<name>XFER_REFUSE Reason Codes</name> <name>XFER_REFUSE Reason Codes</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Code</th> <th>Code</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>Unknown</td> <td>Unknown</td>
<td>0x00</td> <td>0x00</td>
<td>Reason for refusal is unknown or not specified.</td> <td>The reason for refusal is unknown or is not specified.</td>
</tr> </tr>
<tr> <tr>
<td>Completed</td> <td>Completed</td>
<td>0x01</td> <td>0x01</td>
<td>The receiver already has the complete bundle. The sender MAY consider the bundle as completely received.</td> <td>The receiver already has the complete bundle. The sender <bc p14>MAY</bcp14> consider the bundle as completely received.</td>
</tr> </tr>
<tr> <tr>
<td>No Resources</td> <td>No Resources</td>
<td>0x02</td> <td>0x02</td>
<td>The receiver's resources are exhausted. The sender SHOULD ap ply reactive bundle fragmentation before retrying.</td> <td>The receiver's resources are exhausted. The sender <bcp14>SH OULD</bcp14> apply reactive bundle fragmentation before retrying.</td>
</tr> </tr>
<tr> <tr>
<td>Retransmit</td> <td>Retransmit</td>
<td>0x03</td> <td>0x03</td>
<td>The receiver has encountered a problem that requires the bun dle to be retransmitted in its entirety.</td> <td>The receiver has encountered a problem that requires the bun dle to be retransmitted in its entirety.</td>
</tr> </tr>
<tr> <tr>
<td>Not Acceptable</td> <td>Not Acceptable</td>
<td>0x04</td> <td>0x04</td>
<td>Some issue with the bundle data or the transfer extension da ta was encountered. The sender SHOULD NOT retry the same bundle with the same ex tensions.</td> <td>Some issue with the bundle data or the transfer extension da ta was encountered. The sender <bcp14>SHOULD NOT</bcp14> retry the same bundle w ith the same extensions.</td>
</tr> </tr>
<tr> <tr>
<td>Extension Failure</td> <td>Extension Failure</td>
<td>0x05</td> <td>0x05</td>
<td>A failure processing the Transfer Extension Items has occurr ed.</td> <td>A failure processing the Transfer Extension Items has occurr ed.</td>
</tr> </tr>
<tr> <tr>
<td>Session Terminating</td> <td>Session Terminating</td>
<td>0x06</td> <td>0x06</td>
<td>The receiving entity is in the process of terminating the se ssion. The sender MAY retry the same bundle at a later time in a different sessi on.</td> <td>The receiving entity is in the process of terminating the se ssion. The sender <bcp14>MAY</bcp14> retry the same bundle at a later time in a different session.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The receiver MUST, for each transfer preceding the one to be refused, have eithe r acknowledged all XFER_SEGMENT messages or refused the bundle transfer. The receiver <bcp14>MUST</bcp14>, for each transfer preceding the one to be refu sed, have either acknowledged all XFER_SEGMENT messages or refused the bundle tr ansfer.
</t> </t>
<t> <t>
The bundle transfer refusal MAY be sent before an entire data segment is receive The bundle transfer refusal <bcp14>MAY</bcp14> be sent before an entire data seg
d. ment is received.
If a sender receives a XFER_REFUSE message, the sender MUST complete the transmi If a sender receives a XFER_REFUSE message, the sender <bcp14>MUST</bcp14> compl
ssion of any partially sent XFER_SEGMENT message. ete the transmission of any partially sent XFER_SEGMENT message.
There is no way to interrupt an individual TCPCL message partway through sending it. There is no way to interrupt an individual TCPCL message partway through sending it.
The sender MUST NOT commence transmission of any further segments of the refused The sender <bcp14>MUST NOT</bcp14> subsequently commence transmission of any fur
bundle subsequently. ther segments of the refused bundle.
Note, however, that this requirement does not ensure that an entity will not rec Note, however, that this requirement does not ensure that an entity will not rec
eive another XFER_SEGMENT for the same bundle after transmitting a XFER_REFUSE m eive another XFER_SEGMENT for the same bundle after transmitting a XFER_REFUSE m
essage since messages can cross on the wire; if this happens, subsequent segment essage, since messages can cross on the wire; if this happens, subsequent segmen
s of the bundle SHALL also be refused with a XFER_REFUSE message. ts of the bundle <bcp14>SHALL</bcp14> also be refused with a XFER_REFUSE message
</t> .
<t>
Note: If a bundle transmission is aborted in this way, the receiver does not rec
eive a segment with the 'END' flag set to 1 for the aborted bundle.
The beginning of the next bundle is identified by the 'START' flag set to 1, ind
icating the start of a new transfer, and with a distinct Transfer ID value.
</t> </t>
<aside><t>
Note: If a bundle transmission is aborted in this way, the receiver does not rec
eive a segment with the <tt>END</tt> flag set to 1 for the aborted bundle.
The beginning of the next bundle is identified by the <tt>START</tt> flag set to
1, indicating the start of a new transfer, and with a distinct Transfer ID valu
e.
</t></aside>
</section> </section>
<section anchor="sec-transfer-extension"> <section anchor="sec-transfer-extension">
<name>Transfer Extension Items</name> <name>Transfer Extension Items</name>
<t> <t>
Each of the Transfer Extension Items SHALL be encoded in an identical Type-Lengt h-Value (TLV) container form as indicated in <xref target="fig-transfer-extensio n"/>. Each of the Transfer Extension Items <bcp14>SHALL</bcp14> be encoded in an ident ical Type-Length-Value (TLV) container form as indicated in <xref target="fig-tr ansfer-extension"/>.
</t> </t>
<t> <t>
The fields of the Transfer Extension Item are: The fields of the Transfer Extension Item are as follows:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Item Flags:</dt> <dt>Item Flags:</dt>
<dd> <dd>
A one-octet field containing generic bit flags about the Item, which are listed A one-octet field containing generic bit flags related to the Item, which are li
in <xref target="tab-transfer-extension-flags"/>. sted in <xref target="tab-transfer-extension-flags"/>.
All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits <bcp14>SHALL</bcp14> be set to 0 by the sender.
All reserved header flag bits SHALL be ignored by the receiver. All reserved header flag bits <bcp14>SHALL</bcp14> be ignored by the receiver.
If a TCPCL entity receives a Transfer Extension Item with an unknown Item Type a If a TCPCL entity receives a Transfer Extension Item with an unknown Item Type a
nd the CRITICAL flag is 1, the entity SHALL refuse the transfer with an XFER_REF nd the <tt>CRITICAL</tt> flag is 1, the entity <bcp14>SHALL</bcp14> refuse the t
USE reason code of "Extension Failure". ransfer 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 If the <tt>CRITICAL</tt> flag is 0, an entity <bcp14>SHALL</bcp14> skip over and
unknown Item Type. ignore any item with an unknown Item Type.
</dd> </dd>
<dt>Item Type:</dt> <dt>Item Type:</dt>
<dd> <dd>
A 16-bit unsigned integer field containing the type of the extension item. A 16-bit unsigned integer field containing the type of the extension item.
This specification creates an IANA registry for such codes (see <xref target="se c-iana-transfer-extension-type"/>). This specification creates an IANA registry for such codes (see <xref target="se c-iana-transfer-extension-type"/>).
</dd> </dd>
<dt>Item Length:</dt> <dt>Item Length:</dt>
<dd> <dd>
A 16-bit unsigned integer field containing the number of Item Value octets to fo llow. A 16-bit unsigned integer field containing the number of Item Value octets to fo llow.
</dd> </dd>
<dt>Item Value:</dt> <dt>Item Value:</dt>
<dd> <dd>
A variable-length data field which is interpreted according to the associated It em Type. A variable-length data field that is interpreted according to the associated Ite m Type.
This specification places no restrictions on an extension's use of available Ite m Value data. This specification places no restrictions on an extension's use of available Ite m Value data.
Extension specifications SHOULD avoid the use of large data lengths, as the asso ciated transfer cannot begin until the full extension data is sent. Extension specifications <bcp14>SHOULD</bcp14> avoid the use of large data lengt hs, as the associated transfer cannot begin until the full extension data is sen t.
</dd> </dd>
</dl> </dl>
<figure anchor="fig-transfer-extension"> <figure anchor="fig-transfer-extension">
<name>Transfer Extension Item Format</name> <name>Transfer Extension Item Format</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 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...| | Item Flags | Item Type | Item Length...|
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
skipping to change at line 2070 skipping to change at line 2088
<name>Transfer Extension Item Flags</name> <name>Transfer Extension Item Flags</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Code</th> <th>Code</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>CRITICAL</td> <td><tt>CRITICAL</tt></td>
<td>0x01</td> <td>0x01</td>
<td>If bit is set, indicates that the receiving peer must handle the extension item.</td> <td>If this bit is set, it indicates that the receiving peer mus t handle the extension item.</td>
</tr> </tr>
<tr> <tr>
<td>Reserved</td> <td>Reserved</td>
<td>others</td> <td>others</td>
<td/> <td/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<section anchor="sec-transfer-extension-transfer-length"> <section anchor="sec-transfer-extension-transfer-length">
<name>Transfer Length Extension</name> <name>Transfer Length Extension</name>
<t> <t>
The purpose of the Transfer Length extension is to allow entities to preemptivel y refuse bundles that would exceed their resources or to prepare storage on the receiving entity for the upcoming bundle data. The purpose of the Transfer Length Extension is to allow entities to preemptivel y refuse bundles that would exceed their resources or to prepare storage on the receiving entity for the upcoming bundle data.
</t> </t>
<t> <t>
Multiple Transfer Length extension items SHALL NOT occur within the same transfe Multiple Transfer Length Extension Items <bcp14>SHALL NOT</bcp14> occur within t
r. he same transfer.
The lack of a Transfer Length extension item in any transfer SHALL NOT imply any The lack of a Transfer Length Extension Item in any transfer <bcp14>SHALL NOT</b
thing about the potential length of the transfer. cp14> imply anything regarding the potential length of the transfer.
The Transfer Length extension SHALL be assigned transfer extension type ID 0x000 The Transfer Length Extension <bcp14>SHALL</bcp14> use the IANA-assigned code po
1. int from <xref target="sec-iana-transfer-extension-type"/>.
</t> </t>
<t> <t>
If a transfer occupies exactly one segment (i.e., both START and END flags are 1 ) the Transfer Length extension SHOULD NOT be present. If a transfer occupies exactly one segment (i.e., both the <tt>START</tt> flag a nd the <tt>END</tt> flag are 1), the Transfer Length Extension <bcp14>SHOULD NOT </bcp14> be present.
The extension does not provide any additional information for single-segment tra nsfers. The extension does not provide any additional information for single-segment tra nsfers.
</t> </t>
<t> <t>
The format of the Transfer Length data is as follows in <xref target="fig-Transf er-Length-fields"/>. The format of the Transfer Length Extension data is shown in <xref target="fig-T ransfer-Length-fields"/>.
</t> </t>
<figure anchor="fig-Transfer-Length-fields"> <figure anchor="fig-Transfer-Length-fields">
<name>Format of Transfer Length data</name> <name>Format of Transfer Length Extension Data</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+----------------------+ +----------------------+
| Total Length (U64) | | Total Length (U64) |
+----------------------+ +----------------------+
</artwork> </artwork>
</figure> </figure>
<t>
The fields of the Transfer Length extension are: <t>The Transfer Length Extension data contains the following field:</t>
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Total Length:</dt> <dt>Total Length:</dt>
<dd> <dd>
A 64-bit unsigned integer indicating the size of the data-to-be-transferred. 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. The Total Length field <bcp14>SHALL</bcp14> be treated as authoritative by the r
If, for whatever reason, the actual total length of bundle data received differs eceiver.
from the value indicated by the Total Length value, the receiver SHALL treat th If, for whatever reason, the actual total length of bundle data received differs
e transmitted data as invalid and send an XFER_REFUSE with a Reason Code of "Not from the value indicated by the Total Length value, the receiver <bcp14>SHALL</
Acceptable". bcp14> treat the transmitted data as invalid and send a XFER_REFUSE with a reaso
n code of "Not Acceptable".
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec-termination"> <section anchor="sec-termination">
<name>Session Termination</name> <name>Session Termination</name>
<t> <t>
This section describes the procedures for terminating a TCPCL session. This section describes the procedures for terminating a TCPCL session.
The purpose of terminating a session is to allow transfers to complete before th e TCP connection is closed but not allow any new transfers to start. The purpose of terminating a session is to allow transfers to complete before th e TCP connection is closed but not allow any new transfers to start.
A session state change is necessary for this to happen because transfers can be in-progress in either direction (transfer stream) within a session. A session state change is necessary for this to happen, because transfers can be in progress in either direction (transfer stream) within a session.
Waiting for a transfer to complete in one direction does not control or influenc e the possibility of a transfer in the other direction. Waiting for a transfer to complete in one direction does not control or influenc e the possibility of a transfer in the other direction.
Either peer of a session can terminate an established session at any time. Either peer of a session can terminate an established session at any time.
</t> </t>
<section anchor="sec-SESS_TERM"> <section anchor="sec-SESS_TERM">
<name>Session Termination Message (SESS_TERM)</name> <name>Session Termination Message (SESS_TERM)</name>
<t> <t>
To cleanly terminate a session, a SESS_TERM message SHALL be transmitted by eith To cleanly terminate a session, a SESS_TERM message <bcp14>SHALL</bcp14> be tran
er entity at any point following complete transmission of any other message. smitted by either entity at any point following complete transmission of any oth
When sent to initiate a termination, the REPLY flag of a SESS_TERM message SHALL er message.
be 0. When sent to initiate a termination, the <tt>REPLY</tt> flag of a SESS_TERM mess
Upon receiving a SESS_TERM message after not sending a SESS_TERM message in the age <bcp14>SHALL</bcp14> be 0.
same session, an entity SHALL send an acknowledging SESS_TERM message. Upon receiving a SESS_TERM message after not sending a SESS_TERM message in the
When sent to acknowledge a termination, a SESS_TERM message SHALL have identical same session, an entity <bcp14>SHALL</bcp14> send an acknowledging SESS_TERM mes
data content from the message being acknowledged except for the REPLY flag, whi sage.
ch is set to 1 to indicate acknowledgement. When sent to acknowledge a termination, a SESS_TERM message <bcp14>SHALL</bcp14>
have identical data content from the message being acknowledged except for the
<tt>REPLY</tt> flag, which is set to 1 to indicate acknowledgment.
</t> </t>
<t> <t>
Once a SESS_TERM message is sent the state of that TCPCL session changes to Endi Once a SESS_TERM message is sent, the state of that TCPCL session changes to End
ng. ing.
While the session is in the Ending state, an entity MAY finish an in-progress tr While the session is in the Ending state,
ansfer in either direction. </t>
While the session is in the Ending state, an entity SHALL NOT begin any new outg <ul spacing="normal">
oing transfer for the remainder of the session. <li>an entity <bcp14>MAY</bcp14> finish an in-progress transfer in either dir
While the session is in the Ending state, an entity SHALL NOT accept any new inc ection.</li>
oming transfer for the remainder of the session. <li>an entity <bcp14>SHALL NOT</bcp14> begin any new outgoing transfer for th
If a new incoming transfer is attempted while in the Ending state, the receiving e remainder of the session.</li>
entity SHALL send an XFER_REFUSE with a Reason Code of "Session Terminating". <li>an entity <bcp14>SHALL NOT</bcp14> accept any new incoming transfer for t
he remainder of the session.</li>
</ul>
<t>If a new incoming transfer is attempted while in the Ending state, the receiv
ing entity <bcp14>SHALL</bcp14> send a XFER_REFUSE with a reason code of "Sessio
n Terminating".
</t> </t>
<t> <t>
There are circumstances where an entity has an urgent need to close a TCP connec There are circumstances where an entity has an urgent need to close a TCP connec
tion associated with a TCPCL session, without waiting for transfers to complete tion associated with a TCPCL session, without waiting for transfers to complete
but also in a way which doesn't force timeouts to occur; for example, due to imp but also in a way that doesn't force timeouts to occur -- for example, due to im
ending shutdown of the underlying data link layer. pending shutdown of the underlying data-link layer.
Instead of following a clean termination sequence, after transmitting a SESS_TER Instead of following a clean termination sequence, after transmitting a SESS_TER
M message an entity MAY perform an unclean termination by immediately closing th M message, an entity <bcp14>MAY</bcp14> perform an unclean termination by immedi
e associated TCP connection. ately closing the associated TCP connection.
When performing an unclean termination, an entity SHOULD acknowledge all receive When performing an unclean termination, an entity <bcp14>SHOULD</bcp14> acknowle
d XFER_SEGMENTs with an XFER_ACK before closing the TCP connection. dge all received XFER_SEGMENTs with a XFER_ACK before closing the TCP connection
Not acknowledging received segments can result in unnecessary bundle or bundle f .
ragment retransmission. Not acknowledging received segments can result in unnecessary bundle or bundle f
Any delay between request to close the TCP connection and actual closing of the ragment retransmissions.
connection (a "half-closed" state) MAY be ignored by the TCPCL entity. Any delay between a request to close the TCP connection and the actual closing o
If the underlying TCP connection is closed during a transmission (in either tran f the connection (a "half-closed" state) <bcp14>MAY</bcp14> be ignored by the TC
sfer stream), the transfer SHALL be indicated to the BP agent as failed (see the PCL entity.
transmission failure and reception failure indications of <xref target="sec-cl- If the underlying TCP connection is closed during a transmission (in either tran
services"/>). sfer stream), the transfer <bcp14>SHALL</bcp14> be indicated to the BPA as faile
d (see the transmission failure and reception failure indications defined in <xr
ef target="sec-cl-services"/>).
</t> </t>
<t> <t>
The TCPCL itself does not have any required behavior to respond to an SESS_TERM The TCPCL itself does not have any required behavior related to responding to a
based on its Reason Code; the termination is passed up as an indication to the B SESS_TERM based on its reason code; the termination is passed up as an indicatio
P agent that the session state has changed. n to the BPA that the session state has changed.
If a termination has a Reason Code which is not decodable to the BP agent, the a If a termination has a reason code that is not decodable to the BPA, the agent <
gent SHOULD treat the termination as having an Unknown reason. bcp14>SHOULD</bcp14> treat the termination as having a reason code of "Unknown".
</t> </t>
<t> <t>
The format of the SESS_TERM message is as follows in <xref target="fig-msg-SESS_ TERM-fields"/>. The format of the SESS_TERM message is shown in <xref target="fig-msg-SESS_TERM- fields"/>.
</t> </t>
<figure anchor="fig-msg-SESS_TERM-fields"> <figure anchor="fig-msg-SESS_TERM-fields">
<name>Format of SESS_TERM Messages</name> <name>Format of SESS_TERM Messages</name>
<artwork align="center" type="ascii-art"> <artwork align="center" type="ascii-art">
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Message Flags (U8) | | Message Flags (U8) |
+-----------------------------+ +-----------------------------+
| Reason Code (U8) | | Reason Code (U8) |
+-----------------------------+ +-----------------------------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
The fields of the SESS_TERM message are: The fields of the SESS_TERM message are as follows:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Message Flags:</dt> <dt>Message Flags:</dt>
<dd> <dd>
A one-octet field of single-bit flags, interpreted according to the descriptions in <xref target="tab-SESS_TERM-flags"/>. A one-octet field of single-bit flags, interpreted according to the descriptions in <xref target="tab-SESS_TERM-flags"/>.
All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits <bcp14>SHALL</bcp14> be set to 0 by the sender.
All reserved header flag bits SHALL be ignored by the receiver. All reserved header flag bits <bcp14>SHALL</bcp14> be ignored by the receiver.
</dd> </dd>
<dt>Reason Code:</dt> <dt>Reason Code:</dt>
<dd> <dd>
A one-octet refusal reason code interpreted according to the descriptions in <xr ef target="tab-SESS_TERM-reasons"/>. A one-octet refusal reason code interpreted according to the descriptions in <xr ef target="tab-SESS_TERM-reasons"/>.
</dd> </dd>
</dl> </dl>
<table align="center" anchor="tab-SESS_TERM-flags"> <table align="center" anchor="tab-SESS_TERM-flags">
<name>SESS_TERM Flags</name> <name>SESS_TERM Flags</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Code</th> <th>Code</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>REPLY</td> <td><tt>REPLY</tt></td>
<td>0x01</td> <td>0x01</td>
<td>If bit is set, indicates that this message is an acknowledgeme nt of an earlier SESS_TERM message.</td> <td>If this bit is set, it indicates that this message is an ackno wledgment of an earlier SESS_TERM message.</td>
</tr> </tr>
<tr> <tr>
<td>Reserved</td> <td>Reserved</td>
<td>others</td> <td>others</td>
<td/> <td/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<table align="center" anchor="tab-SESS_TERM-reasons"> <table align="center" anchor="tab-SESS_TERM-reasons">
<name>SESS_TERM Reason Codes</name> <name>SESS_TERM Reason Codes</name>
skipping to change at line 2252 skipping to change at line 2273
<td>The entity cannot interpret or negotiate a Contact Header or S ESS_INIT option.</td> <td>The entity cannot interpret or negotiate a Contact Header or S ESS_INIT option.</td>
</tr> </tr>
<tr> <tr>
<td>Resource Exhaustion</td> <td>Resource Exhaustion</td>
<td>0x05</td> <td>0x05</td>
<td>The entity has run into some resource limit and cannot continu e the session.</td> <td>The entity has run into some resource limit and cannot continu e the session.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The earliest a TCPCL session termination MAY occur is immediately after transmis The earliest a TCPCL session termination <bcp14>MAY</bcp14> occur is immediately
sion of a Contact Header (and prior to any further message transmit). after transmission of a Contact Header (and prior to any further message transm
This can, for example, be used to notify that the entity is currently not able o issions).
r willing to communicate. This can, for example, be used as a notification that the entity is currently no
However, an entity MUST always send the Contact Header to its peer before sendin t able or willing to communicate.
g a SESS_TERM message. However, an entity <bcp14>MUST</bcp14> always send the Contact Header to its pee
r before sending a SESS_TERM message.
</t> </t>
<t> <t>
Termination of the TCP connection MAY occur prior to receiving the Contact heade Termination of the TCP connection <bcp14>MAY</bcp14> occur prior to receiving th
r as discussed in <xref target="sec-tcp-connection"/>. e Contact Header as discussed in <xref target="sec-tcp-connection"/>.
If reception of the Contact Header itself somehow fails (e.g., an invalid "magic If reception of the Contact Header itself somehow fails (e.g., an invalid magic
string" is received), an entity SHALL close the TCP connection without sending string is received), an entity <bcp14>SHALL</bcp14> close the TCP connection wit
a SESS_TERM message. hout sending a SESS_TERM message.
</t> </t>
<t> <t>
If a session is to be terminated before a protocol message has completed being s If a session is to be terminated before the sending of a protocol message has c
ent, then the entity MUST NOT transmit the SESS_TERM message but still SHALL clo ompleted, then the entity <bcp14>MUST NOT</bcp14> transmit the SESS_TERM message
se the TCP connection. but still <bcp14>SHALL</bcp14> close the TCP connection.
Each TCPCL message is contiguous in the octet stream and has no ability to be cu Each TCPCL message is contiguous in the octet stream and has no ability to be cu
t short and/or preempted by an other message. t short and/or preempted by another message.
This is particularly important when large segment sizes are being transmitted; e This is particularly important when large segment sizes are being transmitted; e
ither entire XFER_SEGMENT is sent before a SESS_TERM message or the connection i ither the entire XFER_SEGMENT is sent before a SESS_TERM message or the connecti
s simply terminated mid-XFER_SEGMENT. on is simply terminated mid-XFER_SEGMENT.
</t> </t>
</section> </section>
<section anchor="sec-idle-terminate"> <section anchor="sec-idle-terminate">
<name>Idle Session Shutdown</name> <name>Idle Session Termination</name>
<t> <t>
The protocol includes a provision for clean termination of idle sessions. The protocol includes a provision for clean termination of idle sessions.
Determining the length of time to wait before terminating idle sessions, if they are to be terminated at all, is an implementation and configuration matter. Determining the length of time to wait before terminating idle sessions, if they are to be terminated at all, is an implementation and configuration matter.
</t> </t>
<t> <t>
If there is a configured time to terminate idle sessions and if no TCPCL message s (other than KEEPALIVE messages) has been received for at least that amount of time, then either entity MAY terminate the session by transmitting a SESS_TERM m essage indicating the reason code of "Idle timeout" (as described in <xref targe t="tab-SESS_TERM-reasons"/>). If there is a configured time to terminate idle sessions and if no TCPCL message s (other than KEEPALIVE messages) have been received for at least that amount of time, then either entity <bcp14>MAY</bcp14> terminate the session by transmitti ng a SESS_TERM message with a reason code of "Idle timeout" (as described in <xr ef target="tab-SESS_TERM-reasons"/>).
</t> </t>
</section> </section>
</section> </section>
<section removeInRFC="true">
<name>Implementation Status</name>
<t>
[NOTE to the RFC Editor: please remove this section before publication, as well
as the reference to <xref target="RFC7942"/>, <xref target="github-dtn-demo-agen
t"/>, and <xref target="github-dtn-wireshark"/>.]
</t>
<t>
This section records the status of known implementations of the protocol defined
by this specification at the time of posting of this Internet-Draft, and is bas
ed on a proposal described in <xref target="RFC7942"/>.
The description of implementations in this section is intended to assist the IET
F in its decision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation here does not impl
y endorsement by the IETF.
Furthermore, no effort has been spent to verify the information presented here t
hat was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a catalog of available
implementations or their features.
Readers are advised to note that other implementations can exist.
</t>
<t>
An example implementation of the this draft of TCPCLv4 has been created as a Git
Hub project <xref target="github-dtn-demo-agent"/> and is intended to use as a p
roof-of-concept and as a possible source of interoperability testing.
This example implementation uses D-Bus as the CL-BP Agent interface, so it only
runs on hosts which provide the Python "dbus" library.
</t>
<t>
A wireshark dissector for TCPCLv4 has been created as a GitHub project <xref tar
get="github-dtn-wireshark"/> and has been kept in-sync with the latest encoding
of this specification.
</t>
</section>
<section anchor="sec-security"> <section anchor="sec-security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
This section separates security considerations into threat categories based on g uidance of BCP 72 <xref target="RFC3552"/>. This section separates security considerations into threat categories based on g uidance provided in <xref target="RFC3552">BCP 72</xref>.
</t> </t>
<section> <section>
<name>Threat: Passive Leak of Node Data</name> <name>Threat: Passive Leak of Node Data</name>
<t> <t>
When used without TLS security, the TCPCL exposes the Node ID and other configur ation data to passive eavesdroppers. When used without TLS security, the TCPCL exposes the node ID and other configur ation data to passive eavesdroppers.
This occurs even when no transfers occur within a TCPCL session. This occurs even when no transfers occur within a TCPCL session.
This can be avoided by always using TLS, even if authentication is not available (see <xref target="sec-security-tlsalt"/>). This can be avoided by always using TLS, even if authentication is not available (see <xref target="sec-security-tlsalt"/>).
</t> </t>
</section> </section>
<section> <section>
<name>Threat: Passive Leak of Bundle Data</name> <name>Threat: Passive Leak of Bundle Data</name>
<t> <t>
TCPCL can be used to provide point-to-point transport security, but does not pro The TCPCL can be used to provide point-to-point transport security, but it does
vide security of data-at-rest and does not guarantee end-to-end bundle security. not provide security of data at rest and does not guarantee end-to-end bundle se
The bundle security mechanisms defined in <xref target="I-D.ietf-dtn-bpsec"/> ar curity.
e to be used instead. The bundle security mechanisms defined in <xref target="RFC9172"/> are to be use
d instead.
</t> </t>
<t> <t>
When used without TLS security, the TCPCL exposes all bundle data to passive eav esdroppers. When used without TLS security, the TCPCL exposes all bundle data to passive eav esdroppers.
This can be avoided by always using TLS, even if authentication is not available (see <xref target="sec-security-tlsalt"/>). This can be avoided by always using TLS, even if authentication is not available (see <xref target="sec-security-tlsalt"/>).
</t> </t>
</section> </section>
<section> <section>
<name>Threat: TCPCL Version Downgrade</name> <name>Threat: TCPCL Version Downgrade</name>
<t> <t>
When a TCPCL entity supports multiple versions of the protocol it is possible fo When a TCPCL entity supports multiple versions of the protocol, it is possible f
r a malicious or misconfigured peer to use an older version of TCPCL which does or a malicious or misconfigured peer to use an older version of the TCPCL protoc
not support transport security. ol that does not support transport security.
A on-path attacker can also manipulate a Contact Header to present a lower proto An on-path attacker can also manipulate a Contact Header to present a lower prot
col version than desired. ocol version than desired.
</t> </t>
<t> <t>
It is up to security policies within each TCPCL entity to ensure that the negoti ated TCPCL version meets transport security requirements. It is up to security policies within each TCPCL entity to ensure that the negoti ated TCPCL version meets transport security requirements.
</t> </t>
</section> </section>
<section anchor="sec-threat-tls-strip"> <section anchor="sec-threat-tls-strip">
<name>Threat: Transport Security Stripping</name> <name>Threat: Transport Security Stripping</name>
<t> <t>
When security policy allows non-TLS sessions, TCPCL does not protect against act When security policy allows non-TLS sessions, the TCPCL does not protect against
ive network attackers. active network attackers.
It is possible for a on-path attacker to set the CAN_TLS flag to 0 on either sid It is possible for an on-path attacker to set the <tt>CAN_TLS</tt> flag to 0 on
e of the Contact Header exchange, which will cause the negotiation of <xref targ either side of the Contact Header exchange, which will cause the negotiation dis
et="sec-contact-negotiate"/> to disable TLS. cussed in <xref target="sec-contact-negotiate"/> to disable TLS.
This leads to the "SSL Stripping" attack described in <xref target="RFC7457"/>. This leads to the "SSL Stripping" attack described in <xref target="RFC7457"/>.
</t> </t>
<t> <t>
The purpose of the CAN_TLS flag is to allow the use of TCPCL on entities which s imply do not have a TLS implementation available. The purpose of the <tt>CAN_TLS</tt> flag is to allow the use of the TCPCL on ent ities that simply do not have a TLS implementation available.
When TLS is available on an entity, it is strongly encouraged that the security policy disallow non-TLS sessions. When TLS is available on an entity, it is strongly encouraged that the security policy disallow non-TLS sessions.
This requires that the TLS handshake occurs, regardless of the policy-driven par ameters of the handshake and policy-driven handling of the handshake outcome. This requires that the TLS handshake occur, regardless of the policy-driven para meters of the handshake and policy-driven handling of the handshake outcome.
</t> </t>
<t> <t>
One mechanism to mitigate the possibility of TLS stripping is the use of DNS-bas ed Authentication of Named Entities (DANE) <xref target="RFC6698"/> toward the p assive peer. One mechanism to mitigate the possibility of TLS Stripping is the use of DNS-bas ed Authentication of Named Entities (DANE) <xref target="RFC6698"/> toward the p assive peer.
This mechanism relies on DNS and is unidirectional, so it doesn't help with appl ying policy toward the active peer, but it can be useful in an environment using opportunistic security. This mechanism relies on DNS and is unidirectional, so it doesn't help with appl ying policy toward the active peer, but it can be useful in an environment using opportunistic security.
The configuration and use of DANE are outside of the scope of this document. The configuration and use of DANE are outside of the scope of this document.
</t> </t>
<t> <t>
The negotiated use of TLS is identical behavior to STARTTLS use in <xref target= "RFC2595"/>, <xref target="RFC4511"/>, and others. The negotiated use of TLS is identical in behavior to the use of STARTTLS as des cribed in <xref target="RFC2595"/>, <xref target="RFC4511"/>, and others.
</t> </t>
</section> </section>
<section> <section>
<name>Threat: Weak TLS Configurations</name> <name>Threat: Weak TLS Configurations</name>
<t> <t>
Even when using TLS to secure the TCPCL session, the actual ciphersuite negotiat Even when using TLS to secure the TCPCL session, the actual cipher suite negotia
ed between the TLS peers can be insecure. ted between the TLS peers can be insecure.
Recommendations for ciphersuite use are included in BCP 195 <xref target="RFC752 Recommendations for using cipher suites are included in <xref target="RFC7525">B
5"/>. CP 195</xref>.
It is up to security policies within each TCPCL entity to ensure that the negoti It is up to security policies within each TCPCL entity to ensure that the negoti
ated TLS ciphersuite meets transport security requirements. ated TLS cipher suite meets transport security requirements.
</t> </t>
</section> </section>
<section anchor="sec-threat-untrust-cert"> <section anchor="sec-threat-untrust-cert">
<name>Threat: Untrusted End-Entity Certificate</name> <name>Threat: Untrusted End-Entity Certificate</name>
<t> <t>
The profile in <xref target="sec-tls-authentication"/> uses end-entity certifica The authentication method discussed in <xref target="sec-tls-authentication"/> u
tes chained up to a trusted root CA. ses end-entity certificates chained to a trusted root CA. During a TLS handshake
During TLS handshake, either entity can send a certificate set which does not co , either entity can send a certificate set that does not contain the full chain,
ntain the full chain, possibly excluding intermediate or root CAs. possibly excluding intermediate or root CAs.
In an environment where peers are known to already contain needed root and inter In an environment where peers are known to already contain needed root and inter
mediate CAs there is no need to include those CAs, but this has a risk of an ent mediate CAs, there is no need to include those CAs, but this carries the risk of
ity not actually having one of the needed CAs. an entity not actually having one of the needed CAs.
</t> </t>
</section> </section>
<section> <section>
<name>Threat: Certificate Validation Vulnerabilities</name> <name>Threat: Certificate Validation Vulnerabilities</name>
<t> <t>
Even when TLS itself is operating properly an attacker can attempt to exploit vu Even when TLS itself is operating properly, an attacker can attempt to exploit v
lnerabilities within certificate check algorithms or configuration to establish ulnerabilities within certificate check algorithms or configuration to establish
a secure TCPCL session using an invalid certificate. a secure TCPCL session using an invalid certificate.
A BP agent treats the peer Node ID within a TCPCL session as authoritative and a A BPA treats the peer node ID within a TCPCL session as authoritative, and explo
n invalid certificate exploit could lead to bundle data leaking and/or denial of itation via an invalid certificate could lead to bundle data leaking and/or deni
service to the Node ID being impersonated. al of service to the node ID being impersonated.
</t> </t>
<t> <t>
There are many reasons, described in <xref target="RFC5280"/> and <xref target=" RFC6125"/>, why a certificate can fail to validate, including using the certific ate outside of its valid time interval, using purposes for which it was not auth orized, or using it after it has been revoked by its CA. There are many reasons, as described in <xref target="RFC5280"/> and <xref targe t="RFC6125"/>, why a certificate can fail to validate, including using the certi ficate outside of its valid time interval, using purposes for which it was not a uthorized, or using it after it has been revoked by its CA.
Validating a certificate is a complex task and can require network connectivity outside of the primary TCPCL network path(s) if a mechanism such as OCSP <xref t arget="RFC6960"/> is used by the CA. Validating a certificate is a complex task and can require network connectivity outside of the primary TCPCL network path(s) if a mechanism such as OCSP <xref t arget="RFC6960"/> is used by the CA.
The configuration and use of particular certificate validation methods are outsi de of the scope of this document. The configuration and use of particular certificate validation methods are outsi de of the scope of this document.
</t> </t>
</section> </section>
<section> <section>
<name>Threat: Symmetric Key Limits</name> <name>Threat: Symmetric Key Limits</name>
<t> <t>Even with a secure block cipher and securely established session keys
Even with a secure block cipher and securely-established session keys, there are , there are limits to the amount of plaintext that can be safely encrypted with
limits to the amount of plaintext which can be safely encrypted with a given se a given set of keys, as described in <xref target="AEAD-LIMITS"/>.
t of keys as described in <xref target="AEAD-LIMITS"/>.
When permitted by the negotiated TLS version (see <xref target="RFC8446"/>), it is advisable to take advantage of session key updates to avoid those limits. When permitted by the negotiated TLS version (see <xref target="RFC8446"/>), it is advisable to take advantage of session key updates to avoid those limits.
</t> </t>
</section> </section>
<section anchor="sec-threat-node-impersonation"> <section anchor="sec-threat-node-impersonation">
<name>Threat: BP Node Impersonation</name> <name>Threat: BP Node Impersonation</name>
<t> <t>
The certificates exchanged by TLS enable authentication of peer DNS name and Nod The certificates exchanged by TLS enable authentication of the peer DNS name and
e ID, but it is possible that a peer either not provide a valid certificate or t node ID, but it is possible that either a peer does not provide a valid certifi
hat the certificate does not validate either the DNS-ID/IPADDR-ID or NODE-ID of cate or the certificate does not validate either the DNS-ID/IPADDR-ID or NODE-ID
the peer (see <xref target="sec-pkix-env"/>). of the peer (see <xref target="sec-pkix-env"/>).
Having a CA-validated certificate does not alone guarantee the identity of the n Having a CA-validated certificate does not alone guarantee the identity of the n
etwork host or BP node from which the certificate is provided; additional valida etwork host or BP node from which the certificate is provided; additional valida
tion procedures in <xref target="sec-tls-handshake"/> bind the DNS-ID/IPADDR-ID tion procedures as provided in <xref target="sec-tls-authentication"/> bind the
or NODE-ID based on the contents of the certificate. DNS-ID/IPADDR-ID or NODE-ID based on the contents of the certificate.
</t> </t>
<t> <t>
The DNS-ID/IPADDR-ID validation is a weaker form of authentication, because even The DNS-ID/IPADDR-ID validation is a weaker form of authentication, because even
if a peer is operating on an authenticated network DNS name or IP address it ca if a peer is operating on an authenticated network DNS name or IP address it ca
n provide an invalid Node ID and cause bundles to be "leaked" to an invalid node n provide an invalid node ID and cause bundles to be "leaked" to an invalid node
. .
Especially in DTN environments, network names and addresses of nodes can be time Especially in DTN environments, network names and addresses of nodes can be time
-variable so binding a certificate to a Node ID is a more stable identity. -variable, so binding a certificate to a node ID results in a more stable identi
ty.
</t> </t>
<t> <t>
NODE-ID validation ensures that the peer to which a bundle is transferred is in NODE-ID validation ensures that the peer to which a bundle is transferred is in
fact the node which the BP Agent expects it to be. fact the node that the BPA expects it to be.
In circumstances where certificates can only be issued to DNS names, Node ID val In circumstances where certificates can only be issued to DNS names, node ID val
idation is not possible but it could be reasonable to assume that a trusted host idation is not possible, but it could be reasonable to assume that a trusted hos
is not going to present an invalid Node ID. t is not going to present an invalid node ID.
Determining when a DNS-ID/IPADDR-ID authentication can be trusted to validate a Determining when a DNS-ID/IPADDR-ID authentication can be trusted to validate a
Node ID is also a policy matter outside of the scope of this document. node ID is also a policy matter outside of the scope of this document.
</t> </t>
<t> <t>
One mitigation to arbitrary entities with valid PKIX certificates impersonating One mitigation regarding arbitrary entities with valid PKIX certificates imperso
arbitrary Node IDs is the use of the PKIX Extended Key Usage key purpose <tt>id- nating arbitrary node IDs is the use of the PKIX EKU key purpose <tt>id-kp-bundl
kp-bundleSecurity</tt> (see <xref target="sec-pkix-oids"/>). eSecurity</tt> (<xref target="sec-pkix-oids"/>).
When this Extended Key Usage is present in the certificate, it represents a stro When this EKU is present in the certificate, it represents a stronger assertion
nger assertion that the private key holder should in fact be trusted to operate that the private key holder should in fact be trusted to operate as a bundle nod
as a DTN Node. e.
</t> </t>
</section> </section>
<section> <section>
<name>Threat: Denial of Service</name> <name>Threat: Denial of Service</name>
<t> <t>
The behaviors described in this section all amount to a potential denial-of-serv The behaviors described in this section all amount to a potential denial of serv
ice to a TCPCL entity. ice to a TCPCL entity.
The denial-of-service could be limited to an individual TCPCL session, could aff The denial of service could be limited to an individual TCPCL session, could aff
ect other well-behaving sessions on an entity, or could affect all sessions on a ect other well-behaved sessions on an entity, or could affect all sessions on a
host. host.
</t> </t>
<t> <t>
A malicious entity can continually establish TCPCL sessions and delay sending of A malicious entity can trigger timeouts by continually establishing TCPCL sessio
protocol-required data to trigger timeouts. ns and delaying the sending of protocol-required data.
The victim entity can block TCP connections from network peers which are thought The victim entity can block TCP connections from network peers that are thought
to be incorrectly behaving within TCPCL. to behave incorrectly within the TCPCL.
</t> </t>
<t> <t>
An entity can send a large amount of data over a TCPCL session, requiring the re ceiving entity to handle the data. An entity can send a large amount of data over a TCPCL session, requiring the re ceiving entity to handle the data.
The victim entity can attempt to stop the flood of data by sending an XFER_REFUS E message, or forcibly terminate the session. The victim entity can attempt to stop the flood of data by sending a XFER_REFUSE message or can forcibly terminate the session.
</t> </t>
<t> <t>
There is the possibility of a "data dribble" attack in which an entity presents A "data dribble" attack is also possible, in which an entity presents a very sma
a very small Segment MRU which causes transfers to be split among an large numbe ll Segment MRU that causes transfers to be split among a large number of very sm
r of very small segments and causes the segmentation overhead to overwhelm the a all segments and causes the resultant segmentation overhead to overwhelm the act
ctual bundle data segments. ual bundle data segments.
Similarly, an entity can present a very small Transfer MRU which will cause reso Similarly, an entity can present a very small Transfer MRU that will cause resou
urces to be wasted on establishment and upkeep of a TCPCL session over which a b rces to be wasted on establishment and upkeep of a TCPCL session over which a bu
undle could never be transferred. ndle could never be transferred.
The victim entity can terminate the session during the negotiation of <xref targ The victim entity can terminate the session during parameter negotiation (<xref
et="sec-session-negotiate"/> if the MRUs are unacceptable. target="sec-session-negotiate"/>) if the MRUs are unacceptable.
</t> </t>
<t> <t>
The keepalive mechanism can be abused to waste throughput within a network link An abusive entity could cause the keepalive mechanism to waste throughput within
which would otherwise be usable for bundle transmissions. a network link that would otherwise be usable for bundle transmissions.
Due to the quantization of the Keepalive Interval parameter the smallest Session Due to the quantization of the Keepalive Interval parameter, the smallest Sessio
Keepalive is one second, which should be long enough to not flood the link. n Keepalive is one second, which should be long enough to not flood the link.
The victim entity can terminate the session during the negotiation of <xref targ The victim entity can terminate the session during parameter negotiation (<xref
et="sec-session-negotiate"/> if the Keepalive Interval is unacceptable. target="sec-session-negotiate"/>) if the Keepalive Interval is unacceptable.
</t> </t>
<t> <t>
Finally, an attacker or a misconfigured entity can cause issues at the TCP conne ction which will cause unnecessary TCP retransmissions or connection resets, eff ectively denying the use of the overlying TCPCL session. Finally, an attacker or a misconfigured entity can cause issues at the TCP conne ction that will cause unnecessary TCP retransmissions or connection resets, effe ctively denying the use of the overlying TCPCL session.
</t> </t>
</section> </section>
<section anchor="sec-security-tls-mandate"> <section anchor="sec-security-tls-mandate">
<name>Mandatory-to-Implement TLS</name> <name>Mandatory-to-Implement TLS</name>
<t> <t>
Following IETF best current practice, TLS is mandatory to implement for all TCPC L implementations but TLS is optional to use for a given TCPCL session. Following IETF best current practice, TLS is mandatory to implement for all TCPC L implementations but TLS is optional to use for a given TCPCL session.
The recommended configuration of <xref target="sec-contact-header"/> is to alway The policy recommendations in Sections&nbsp;<xref target="sec-contact-header" fo
s enable TLS, but entities are permitted to disable TLS based on local configura rmat="counter"/> and <xref target="sec-contact-negotiate" format="counter"/> bot
tion. h enable TLS and require TLS, but entities are permitted to disable and not requ
The configuration to enable or disable TLS for an entity or a session is outside ire TLS based on local configuration. The configuration to enable or require TLS
of the scope of this document. for an entity or a session is outside of the scope of this document.
The configuration to disable TLS is different from the threat of TLS stripping d The configuration to disable TLS is different from the threat of TLS Stripping a
escribed in <xref target="sec-threat-tls-strip"/>. s described in <xref target="sec-threat-tls-strip"/>.
</t> </t>
</section> </section>
<section anchor="sec-security-tlsalt"> <section anchor="sec-security-tlsalt">
<name>Alternate Uses of TLS</name> <name>Alternate Uses of TLS</name>
<t> <t>
This specification makes use of PKIX certificate validation and authentication w ithin TLS. This specification makes use of PKIX certificate validation and authentication w ithin TLS.
There are alternate uses of TLS which are not necessarily incompatible with the security goals of this specification, but are outside of the scope of this docum ent. There are alternate uses of TLS that are not necessarily incompatible with the s ecurity goals of this specification but that are outside of the scope of this do cument.
The following subsections give examples of alternate TLS uses. The following subsections give examples of alternate TLS uses.
</t> </t>
<section anchor="sec-security-tlsnoauth"> <section anchor="sec-security-tlsnoauth">
<name>TLS Without Authentication</name> <name>TLS without Authentication</name>
<t> In environments where PKI is available but there are restrictions <t> In environments where PKI is available but there are restrictions
on the issuance of certificates (including the contents of certificates), it may on the issuance of certificates (including the contents of certificates), it may
be possible to make use of TLS in a way which authenticates only the passive en be possible to make use of TLS in a way that authenticates only the passive ent
tity of a TCPCL session or which does not authenticate either entity. ity of a TCPCL session or that does not authenticate either entity.
Using TLS in a way which does not successfully authenticate some claim of both p Using TLS in a way that does not successfully authenticate some claim of both pe
eer entities of a TCPCL session is outside of the scope of this document but doe er entities of a TCPCL session is outside of the scope of this document but does
s have similar properties to the opportunistic security model of <xref target="R have properties similar to the opportunistic security model <xref target="RFC7
FC7435"/>. 435"/>.
</t> </t>
</section> </section>
<section anchor="sec-security-tlsnopki"> <section anchor="sec-security-tlsnopki">
<name>Non-Certificate TLS Use</name> <name>Non-certificate TLS Use</name>
<t> <t>
In environments where PKI is unavailable, alternate uses of TLS which do not req uire certificates such as pre-shared key (PSK) authentication <xref target="RFC5 489"/> and the use of raw public keys <xref target="RFC7250"/> are available and can be used to ensure confidentiality within TCPCL. In environments where PKI is unavailable, alternate uses of TLS that do not requ ire certificates such as pre-shared key (PSK) authentication <xref target="RFC54 89"/> and the use of raw public keys <xref target="RFC7250"/> are available and can be used to ensure confidentiality within the TCPCL.
Using non-PKI node authentication methods is outside of the scope of this docume nt. Using non-PKI node authentication methods is outside of the scope of this docume nt.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec-security-xferid"> <section anchor="sec-security-xferid">
<name>Predictability of Transfer IDs</name> <name>Predictability of Transfer IDs</name>
<t> <t>
The only requirement on Transfer IDs is that they be unique with each session fr om the sending peer only. The only requirement on Transfer IDs is that they be unique within each session from the sending peer only.
The trivial algorithm of the first transfer starting at zero and later transfers incrementing by one causes absolutely predictable Transfer IDs. The trivial algorithm of the first transfer starting at zero and later transfers incrementing by one causes absolutely predictable Transfer IDs.
Even when a TCPCL session is not TLS secured and there is a on-path attacker cau sing denial of service with XFER_REFUSE messages, it is not possible to preempti vely refuse a transfer so there is no benefit in having unpredictable Transfer I Ds within a session. Even when a TCPCL session is not TLS secured and there is an on-path attacker ca using denial of service with XFER_REFUSE messages, it is not possible to preempt ively refuse a transfer, so there is no benefit in having unpredictable Transfer IDs within a session.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec-iana"> <section anchor="sec-iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>
Registration procedures referred to in this section are defined in <xref target= "RFC8126"/>. Registration procedures referred to in this section (e.g., the RFC Required poli cy) are defined in <xref target="RFC8126"/>.
</t> </t>
<t> <t>
Some of the registries have been defined as version specific to TCPCLv4, and imp Some of the registries have been defined as version specific for TCPCLv4, and th
orts some or all codepoints from TCPCLv3. ese registries reuse some or all codepoints from TCPCLv3. This was done to disam
This was done to disambiguate the use of these codepoints between TCPCLv3 and TC biguate the use of these codepoints between TCPCLv3 and TCPCLv4 while preserving
PCLv4 while preserving the semantics of some of the codepoints. the semantics of some of the codepoints.
</t> </t>
<section anchor="sec-iana-port"> <section anchor="sec-iana-port">
<name>Port Number</name> <name>Port Number</name>
<t> <t>
Within the port registry of <xref target="IANA-PORTS"/>, TCP port number 4556 ha Within the "Service Name and Transport Protocol Port Number Registry" <xref targ
s been previously assigned as the default port for the TCP convergence layer in et="IANA-PORTS"/>, TCP port number 4556 had previously been assigned as the defa
<xref target="RFC7242"/>. ult port for the TCPCL; see <xref target="RFC7242"/>.
This assignment is unchanged by TCPCL version 4, but the assignment reference is This assignment is unchanged by TCPCL version 4, but the assignment reference ha
updated to this specification. s been updated to point to this specification.
Each TCPCL entity identifies its TCPCL protocol version in its initial contact ( Each TCPCL entity identifies its TCPCL protocol version in its initial contact (
see <xref target="sec-iana-protonum"/>), so there is no ambiguity about what pro see Sections&nbsp;<xref target="sec-protocol-session" format="counter"/> and <xr
tocol is being used. ef target="sec-iana-protonum" format="counter"/>), so there is no ambiguity rega
rding what protocol is being used.
The related assignments for UDP and DCCP port 4556 (both registered by <xref tar get="RFC7122"/>) are unchanged. The related assignments for UDP and DCCP port 4556 (both registered by <xref tar get="RFC7122"/>) are unchanged.
<!-- RPC note: leave "TCP CL" as is here, per
<https://www.iana.org/assignments/service-names-port-numbers/service-names-port-
numbers.txt>, even though it looks odd, because of "UDP CL" and
"DCCP CL" on the same page. -->
</t> </t>
<table align="center"> <table align="center">
<name>TCP Port Number for the TCPCL</name>
<thead> <thead>
<tr> <tr>
<th>Parameter</th> <th>Parameter</th>
<th>Value</th> <th>Value</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>Service Name:</td> <td>Service Name:</td>
<td>dtn-bundle</td> <td>dtn-bundle</td>
</tr> </tr>
<tr> <tr>
<td>Transport Protocol(s):</td> <td>Transport Protocol(s):</td>
<td>TCP</td> <td>TCP</td>
</tr> </tr>
<tr> <tr>
<td>Assignee:</td> <td>Assignee:</td>
<td>IESG &lt;iesg@ietf.org&gt;</td> <td>IESG (iesg@ietf.org)</td>
</tr> </tr>
<tr> <tr>
<td>Contact:</td> <td>Contact:</td>
<td>IESG &lt;iesg@ietf.org&gt;</td> <td>IESG (iesg@ietf.org)</td>
</tr> </tr>
<tr> <tr>
<td>Description:</td> <td>Description:</td>
<td>DTN Bundle TCP CL Protocol</td> <td>DTN Bundle TCP CL Protocol</td>
</tr> </tr>
<tr> <tr>
<td>Reference:</td> <td>Reference:</td>
<td>This specification.</td> <td>This specification</td>
</tr> </tr>
<tr> <tr>
<td>Port Number:</td> <td>Port Number:</td>
<td>4556</td> <td>4556</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-iana-protonum"> <section anchor="sec-iana-protonum">
<name>Protocol Versions</name> <name>Protocol Versions</name>
<t> <t>
IANA has created, under the "Bundle Protocol" registry <xref target="IANA-BUNDLE IANA has registered the following value in the "Bundle Protocol TCP Convergence-
"/>, a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version Number Layer Version Numbers" registry <xref target="RFC7242"/>.
s".
The version number table is updated to include this specification.
The registration procedure is RFC Required.
</t> </t>
<table align="center"> <table align="center">
<name>New TCPCL Version Number</name>
<thead> <thead>
<tr> <tr>
<th>Value</th> <th>Value</th>
<th>Description</th> <th>Description</th>
<th>Reference</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>0</td>
<td>Reserved</td>
<td>
<xref target="RFC7242"/>
</td>
</tr>
<tr>
<td>1</td>
<td>Reserved</td>
<td>
<xref target="RFC7242"/>
</td>
</tr>
<tr>
<td>2</td>
<td>Reserved</td>
<td>
<xref target="RFC7242"/>
</td>
</tr>
<tr>
<td>3</td>
<td>TCPCL</td>
<td>
<xref target="RFC7242"/>
</td>
</tr>
<tr>
<td>4</td> <td>4</td>
<td>TCPCLv4</td> <td>TCPCLv4</td>
<td>This specification.</td> <td>This specification</td>
</tr>
<tr>
<td>5-255</td>
<td>Unassigned</td>
<td/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-iana-session-extension-type"> <section anchor="sec-iana-session-extension-type">
<name>Session Extension Types</name> <name>Session Extension Types</name>
<t>EDITOR NOTE: sub-registry to-be-created upon publication of this spec ification.</t>
<t> <t>
IANA will create, under the "Bundle Protocol" registry <xref target="IANA-BUNDLE Under the "Bundle Protocol" registry <xref target="IANA-BUNDLE"/>, IANA has crea
"/>, a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 4 Sess ted the "Bundle Protocol TCP Convergence-Layer Version 4 Session Extension Types
ion Extension Types" and initialize it with the contents of <xref target="tab-ia " registry and populated it with the contents of <xref target="tab-iana-session-
na-session-extension-type"/>. extension-type"/>.
The registration procedure is Expert Review within the lower range 0x0001--0x7FF The registration procedure is Expert Review within the lower range 0x0001-0x7FFF
F. .
Values in the range 0x8000--0xFFFF are reserved for use on private networks for Values in the range 0x8000-0xFFFF are reserved for Private or Experimental Use,
functions not published to the IANA. which are not recorded by IANA.
</t> </t>
<t> <t>
Specifications of new session extension types need to define the encoding of the Item Value data as well as any meaning or restriction on the number of or order of instances of the type within an extension item list. Specifications of new session extension types need to define the encoding of the Item Value data as well as any meaning or restriction on the number of or order of instances of the type within an extension item list.
Specifications need to define how the extension functions when no instance of th e new extension type is received during session negotiation. Specifications need to define how the extension functions when no instance of th e new extension type is received during session negotiation.
</t> </t>
<t> <t>
Expert(s) are encouraged to be biased towards approving registrations unless the y are abusive, frivolous, or actively harmful (not merely aesthetically displeas ing, or architecturally dubious). Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely esthetically displeasing or architecturally dubious).
</t> </t>
<table align="center" anchor="tab-iana-session-extension-type"> <table align="center" anchor="tab-iana-session-extension-type">
<name>Session Extension Type Codes</name> <name>Session Extension Type Codes</name>
<thead> <thead>
<tr> <tr>
<th>Code</th> <th>Code</th>
<th>Session Extension Type</th> <th>Session Extension Type</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>0x0000</td> <td>0x0000</td>
<td>Reserved</td> <td>Reserved</td>
</tr> </tr>
<tr> <tr>
<td>0x0001--0x7FFF</td> <td>0x0001-0x7FFF</td>
<td>Unassigned</td> <td>Unassigned</td>
</tr> </tr>
<tr> <tr>
<td>0x8000--0xFFFF</td> <td>0x8000-0xFFFF</td>
<td>Private/Experimental Use</td> <td>Reserved for Private or Experimental Use</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-iana-transfer-extension-type"> <section anchor="sec-iana-transfer-extension-type">
<name>Transfer Extension Types</name> <name>Transfer Extension Types</name>
<t>EDITOR NOTE: sub-registry to-be-created upon publication of this spec ification.</t>
<t> <t>
IANA will create, under the "Bundle Protocol" registry <xref target="IANA-BUNDLE Under the "Bundle Protocol" registry <xref target="IANA-BUNDLE"/>, IANA has crea
"/>, a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 4 Tran ted the "Bundle Protocol TCP Convergence-Layer Version 4 Transfer Extension Type
sfer Extension Types" and initialize it with the contents of <xref target="tab-i s" registry and populated it with the contents of <xref target="tab-iana-transfe
ana-transfer-extension-type"/>. r-extension-type"/>. The registration procedure is Expert Review within the lowe
The registration procedure is Expert Review within the lower range 0x0001--0x7FF r range 0x0001-0x7FFF.
F. Values in the range 0x8000-0xFFFF are reserved for Private or Experimental Use,
Values in the range 0x8000--0xFFFF are reserved for use on private networks for which are not recorded by
functions not published to the IANA. IANA.
</t> </t>
<t> <t>
Specifications of new transfer extension types need to define the encoding of th e Item Value data as well as any meaning or restriction on the number of or orde r of instances of the type within an extension item list. Specifications of new transfer extension types need to define the encoding of th e Item Value data as well as any meaning or restriction on the number of or orde r of instances of the type within an extension item list.
Specifications need to define how the extension functions when no instance of th e new extension type is received in a transfer. Specifications need to define how the extension functions when no instance of th e new extension type is received in a transfer.
</t> </t>
<t> <t>
Expert(s) are encouraged to be biased towards approving registrations unless the y are abusive, frivolous, or actively harmful (not merely aesthetically displeas ing, or architecturally dubious). Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely esthetically displeasing or architecturally dubious).
</t> </t>
<table align="center" anchor="tab-iana-transfer-extension-type"> <table align="center" anchor="tab-iana-transfer-extension-type">
<name>Transfer Extension Type Codes</name> <name>Transfer Extension Type Codes</name>
<thead> <thead>
<tr> <tr>
<th>Code</th> <th>Code</th>
<th>Transfer Extension Type</th> <th>Transfer Extension Type</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>0x0000</td> <td>0x0000</td>
<td>Reserved</td> <td>Reserved</td>
</tr> </tr>
<tr> <tr>
<td>0x0001</td> <td>0x0001</td>
<td>Transfer Length Extension</td> <td>Transfer Length Extension</td>
</tr> </tr>
<tr> <tr>
<td>0x0002--0x7FFF</td> <td>0x0002-0x7FFF</td>
<td>Unassigned</td> <td>Unassigned</td>
</tr> </tr>
<tr> <tr>
<td>0x8000--0xFFFF</td> <td>0x8000-0xFFFF</td>
<td>Private/Experimental Use</td> <td>Reserved for Private or Experimental Use</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-iana-message-types"> <section anchor="sec-iana-message-types">
<name>Message Types</name> <name>Message Types</name>
<t>EDITOR NOTE: sub-registry to-be-created upon publication of this spec ification.</t>
<t> <t>
IANA will create, under the "Bundle Protocol" registry <xref target="IANA-BUNDLE Under the "Bundle Protocol" registry <xref target="IANA-BUNDLE"/>, IANA has crea
"/>, a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 4 Mess ted the "Bundle Protocol TCP Convergence-Layer Version 4 Message Types" registry
age Types" and initialize it with the contents of <xref target="tab-iana-message and populated it with the contents of <xref target="tab-iana-message-types"/>.
-types"/>. The registration procedure is RFC Required within the lower range 0x01-0xEF.
The registration procedure is RFC Required within the lower range 0x01--0xEF. Values in the range 0xF0-0xFF are reserved for Private or Experimental Use, whic
Values in the range 0xF0--0xFF are reserved for use on private networks for func h are not recorded by
tions not published to the IANA. IANA.
</t> </t>
<t> <t>
Specifications of new message types need to define the encoding of the message d ata as well as the purpose and relationship of the new message to existing sessi on/transfer state within the baseline message sequencing. Specifications of new message types need to define the encoding of the message d ata as well as the purpose and relationship of the new message to existing sessi on/transfer state within the baseline message sequencing.
The use of new message types need to be negotiated between TCPCL entities within a session (using the session extension mechanism) so that the receiving entity can properly decode all message types used in the session. The use of new message types needs to be negotiated between TCPCL entities withi n a session (using the session extension mechanism) so that the receiving entity can properly decode all message types used in the session.
</t> </t>
<t> <t>
Expert(s) are encouraged to favor new session/transfer extension types over new message types. Experts are encouraged to favor new session/transfer extension types over new me ssage types.
TCPCL messages are not self-delimiting, so care must be taken in introducing new message types. TCPCL messages are not self-delimiting, so care must be taken in introducing new message types.
If an entity receives an unknown message type the only thing that can be done is to send a MSG_REJECT and close the TCP connection; not even a clean termination can be done at that point. If an entity receives an unknown message type, the only thing that can be done i s to send a MSG_REJECT and close the TCP connection; not even a clean terminatio n can be done at that point.
</t> </t>
<table align="center" anchor="tab-iana-message-types"> <table align="center" anchor="tab-iana-message-types">
<name>Message Type Codes</name> <name>Message Type Codes</name>
<thead> <thead>
<tr> <tr>
<th>Code</th> <th>Code</th>
<th>Message Type</th> <th>Message Type</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
skipping to change at line 2729 skipping to change at line 2696
</tr> </tr>
<tr> <tr>
<td>0x06</td> <td>0x06</td>
<td>MSG_REJECT</td> <td>MSG_REJECT</td>
</tr> </tr>
<tr> <tr>
<td>0x07</td> <td>0x07</td>
<td>SESS_INIT</td> <td>SESS_INIT</td>
</tr> </tr>
<tr> <tr>
<td>0x08--0xEF</td> <td>0x08-0xEF</td>
<td>Unassigned</td> <td>Unassigned</td>
</tr> </tr>
<tr> <tr>
<td>0xF0--0xFF</td> <td>0xF0-0xFF</td>
<td>Private/Experimental Use</td> <td>Reserved for Private or Experimental Use</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-iana-XFER_REFUSE-codes"> <section anchor="sec-iana-XFER_REFUSE-codes">
<name>XFER_REFUSE Reason Codes</name> <name>XFER_REFUSE Reason Codes</name>
<t>EDITOR NOTE: sub-registry to-be-created upon publication of this spec ification.</t>
<t> <t>
IANA will create, under the "Bundle Protocol" registry <xref target="IANA-BUNDLE Under the "Bundle Protocol" registry <xref target="IANA-BUNDLE"/>, IANA has crea
"/>, a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 4 XFER ted the "Bundle Protocol TCP Convergence-Layer Version 4 XFER_REFUSE Reason Code
_REFUSE Reason Codes" and initialize it with the contents of <xref target="tab-i s" registry and populated it with the contents of <xref target="tab-iana-XFER_RE
ana-XFER_REFUSE-codes"/>. FUSE-codes"/>.
The registration procedure is Specification Required within the lower range 0x00 The registration procedure is Specification Required within the lower range 0x00
--0xEF. -0xEF.
Values in the range 0xF0--0xFF are reserved for use on private networks for func Values in the range 0xF0-0xFF are reserved for Private or Experimental Use, whic
tions not published to the IANA. h are not recorded by
IANA.
</t> </t>
<t> <t>
Specifications of new XFER_REFUSE reason codes need to define the meaning of the Specifications of new XFER_REFUSE reason codes need to define the meaning of the
reason and disambiguate it with pre-existing reasons. reason and disambiguate it from preexisting reasons. Each refusal reason needs
Each refusal reason needs to be usable by the receiving BP Agent to make retrans to be usable by the receiving BPA to make retransmission or rerouting decisions.
mission or re-routing decisions.
</t> </t>
<t> <t>
Expert(s) are encouraged to be biased towards approving registrations unless the y are abusive, frivolous, or actively harmful (not merely aesthetically displeas ing, or architecturally dubious). Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely esthetically displeasing or architecturally dubious).
</t> </t>
<table align="center" anchor="tab-iana-XFER_REFUSE-codes"> <table align="center" anchor="tab-iana-XFER_REFUSE-codes">
<name>XFER_REFUSE Reason Codes</name> <name>XFER_REFUSE Reason Codes</name>
<thead> <thead>
<tr> <tr>
<th>Code</th> <th>Code</th>
<th>Refusal Reason</th> <th>Refusal Reason</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
skipping to change at line 2792 skipping to change at line 2758
</tr> </tr>
<tr> <tr>
<td>0x05</td> <td>0x05</td>
<td>Extension Failure</td> <td>Extension Failure</td>
</tr> </tr>
<tr> <tr>
<td>0x06</td> <td>0x06</td>
<td>Session Terminating</td> <td>Session Terminating</td>
</tr> </tr>
<tr> <tr>
<td>0x07--0xEF</td> <td>0x07-0xEF</td>
<td>Unassigned</td> <td>Unassigned</td>
</tr> </tr>
<tr> <tr>
<td>0xF0--0xFF</td> <td>0xF0-0xFF</td>
<td>Private/Experimental Use</td> <td>Reserved for Private or Experimental Use</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-iana-SESS_TERM-codes"> <section anchor="sec-iana-SESS_TERM-codes">
<name>SESS_TERM Reason Codes</name> <name>SESS_TERM Reason Codes</name>
<t>EDITOR NOTE: sub-registry to-be-created upon publication of this spec ification.</t>
<t> <t>
IANA will create, under the "Bundle Protocol" registry <xref target="IANA-BUNDLE Under the "Bundle Protocol" registry <xref target="IANA-BUNDLE"/>, IANA has crea
"/>, a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 4 SESS ted the "Bundle Protocol TCP Convergence-Layer Version 4 SESS_TERM Reason Codes"
_TERM Reason Codes" and initialize it with the contents of <xref target="tab-ian registry and populated it with the contents of <xref target="tab-iana-SESS_TERM
a-SESS_TERM-codes"/>. -codes"/>.
The registration procedure is Specification Required within the lower range 0x00 The registration procedure is Specification Required within the lower range 0x00
--0xEF. -0xEF.
Values in the range 0xF0--0xFF are reserved for use on private networks for func Values in the range 0xF0-0xFF are reserved for Private or Experimental Use, whic
tions not published to the IANA. h are not recorded by
IANA.
</t> </t>
<t> <t>
Specifications of new SESS_TERM reason codes need to define the meaning of the r Specifications of new SESS_TERM reason codes need to define the meaning of the r
eason and disambiguate it with pre-existing reasons. eason and disambiguate it from preexisting reasons.
Each termination reason needs to be usable by the receiving BP Agent to make re- Each termination reason needs to be usable by the receiving BPA to make reconnec
connection decisions. tion decisions.
</t> </t>
<t> <t>
Expert(s) are encouraged to be biased towards approving registrations unless the y are abusive, frivolous, or actively harmful (not merely aesthetically displeas ing, or architecturally dubious). Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely esthetically displeasing or architecturally dubious).
</t> </t>
<table align="center" anchor="tab-iana-SESS_TERM-codes"> <table align="center" anchor="tab-iana-SESS_TERM-codes">
<name>SESS_TERM Reason Codes</name> <name>SESS_TERM Reason Codes</name>
<thead> <thead>
<tr> <tr>
<th>Code</th> <th>Code</th>
<th>Termination Reason</th> <th>Termination Reason</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
skipping to change at line 2851 skipping to change at line 2817
</tr> </tr>
<tr> <tr>
<td>0x04</td> <td>0x04</td>
<td>Contact Failure</td> <td>Contact Failure</td>
</tr> </tr>
<tr> <tr>
<td>0x05</td> <td>0x05</td>
<td>Resource Exhaustion</td> <td>Resource Exhaustion</td>
</tr> </tr>
<tr> <tr>
<td>0x06--0xEF</td> <td>0x06-0xEF</td>
<td>Unassigned</td> <td>Unassigned</td>
</tr> </tr>
<tr> <tr>
<td>0xF0--0xFF</td> <td>0xF0-0xFF</td>
<td>Private/Experimental Use</td> <td>Reserved for Private or Experimental Use</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-iana-MSG_REJECT-codes"> <section anchor="sec-iana-MSG_REJECT-codes">
<name>MSG_REJECT Reason Codes</name> <name>MSG_REJECT Reason Codes</name>
<t>EDITOR NOTE: sub-registry to-be-created upon publication of this spec ification.</t>
<t> <t>
IANA will create, under the "Bundle Protocol" registry <xref target="IANA-BUNDLE Under the "Bundle Protocol" registry <xref target="IANA-BUNDLE"/>, IANA has crea
"/>, a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 4 MSG_ ted the "Bundle Protocol TCP Convergence-Layer Version 4 MSG_REJECT Reason Codes
REJECT Reason Codes" and initialize it with the contents of <xref target="tab-ia " registry and populated it with the contents of <xref target="tab-iana-MSG_REJE
na-MSG_REJECT-codes"/>. CT-codes"/>.
The registration procedure is Specification Required within the lower range 0x01 The registration procedure is Specification Required within the lower range 0x01
--0xEF. -0xEF.
Values in the range 0xF0--0xFF are reserved for use on private networks for func Values in the range 0xF0-0xFF are reserved for Private or Experimental Use, whic
tions not published to the IANA. h are not recorded
by IANA.
</t> </t>
<t> <t>
Specifications of new MSG_REJECT reason codes need to define the meaning of the Specifications of new MSG_REJECT reason codes need to define the meaning of the
reason and disambiguate it with pre-existing reasons. reason and disambiguate it from preexisting reasons.
Each rejection reason needs to be usable by the receiving TCPCL Entity to make m Each rejection reason needs to be usable by the receiving TCPCL entity to make m
essage sequencing and/or session termination decisions. essage sequencing and/or session termination decisions.
</t> </t>
<t> <t>
Expert(s) are encouraged to be biased towards approving registrations unless the y are abusive, frivolous, or actively harmful (not merely aesthetically displeas ing, or architecturally dubious). Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely esthetically displeasing or architecturally dubious).
</t> </t>
<table align="center" anchor="tab-iana-MSG_REJECT-codes"> <table align="center" anchor="tab-iana-MSG_REJECT-codes">
<name>MSG_REJECT Reason Codes</name> <name>MSG_REJECT Reason Codes</name>
<thead> <thead>
<tr> <tr>
<th>Code</th> <th>Code</th>
<th>Rejection Reason</th> <th>Rejection Reason</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>0x00</td> <td>0x00</td>
<td>reserved</td> <td>Reserved</td>
</tr> </tr>
<tr> <tr>
<td>0x01</td> <td>0x01</td>
<td>Message Type Unknown</td> <td>Message Type Unknown</td>
</tr> </tr>
<tr> <tr>
<td>0x02</td> <td>0x02</td>
<td>Message Unsupported</td> <td>Message Unsupported</td>
</tr> </tr>
<tr> <tr>
<td>0x03</td> <td>0x03</td>
<td>Message Unexpected</td> <td>Message Unexpected</td>
</tr> </tr>
<tr> <tr>
<td>0x04--0xEF</td> <td>0x04-0xEF</td>
<td>Unassigned</td> <td>Unassigned</td>
</tr> </tr>
<tr> <tr>
<td>0xF0--0xFF</td> <td>0xF0-0xFF</td>
<td>Private/Experimental Use</td> <td>Reserved for Private or Experimental Use</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-iana-smi-mod"> <section anchor="sec-iana-smi-mod">
<name>Object Identifier for PKIX Module Identifier</name> <name>Object Identifier for PKIX Module Identifier</name>
<t> <t>
IANA has created, under the "Structure of Management Information (SMI) Numbers" IANA has registered the following in the "SMI Security for PKIX Module Identifie
registry <xref target="IANA-SMI"/>, a sub-registry titled "SMI Security for PKIX r" registry <xref target="IANA-SMI"/> for identifying the module described in <x
Module Identifier". ref target="sec-asn1-mod"/>.
The table is updated to include a row "id-mod-dtn-tcpclv4-2021" for identifying
the module in <xref target="sec-asn1-mod"/> as in the following table.
</t> </t>
<table align="center"> <table anchor="id-mod-dtn-tcpclv4-2021" align="center">
<name>New SMI Security Module</name>
<thead> <thead>
<tr> <tr>
<th>Decimal</th> <th>Decimal</th>
<th>Description</th> <th>Description</th>
<th>References</th> <th>References</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>MOD-TBD</td> <td>103</td>
<td>id-mod-dtn-tcpclv4-2021</td> <td>id-mod-dtn-tcpclv4-2021</td>
<td>This specification.</td> <td>This specification</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-iana-pkix-on-oid"> <section anchor="sec-iana-pkix-on-oid">
<name>Object Identifier for PKIX Other Name Forms</name> <name>Object Identifier for PKIX Other Name Forms</name>
<t> <t>
IANA has created, under the "Structure of Management Information (SMI) Numbers" IANA has registered the following in the "SMI Security for PKIX Other Name Forms
registry <xref target="IANA-SMI"/>, a sub-registry titled "SMI Security for PKIX " registry <xref target="IANA-SMI"/> for
Other Name Forms". identifying bundle endpoint IDs:
The other name forms table is updated to include a row "id-on-bundleEID" for ide
ntifying DTN Endpoint IDs as in the following table.
</t> </t>
<table align="center"> <table anchor="id-on-bundleEID" align="center">
<name>New PKIX Other Name Form</name>
<thead> <thead>
<tr> <tr>
<th>Decimal</th> <th>Decimal</th>
<th>Description</th> <th>Description</th>
<th>References</th> <th>References</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>ON-TBD</td> <td>11</td>
<td>id-on-bundleEID</td> <td>id-on-bundleEID</td>
<td>This specification.</td> <td>This specification</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>The formal structure of the associated Other Name Form is provided in <xref t
The formal structure of the associated other name form is in <xref target="sec-a arget="sec-asn1-mod"/>. The use of this OID is defined in Sections&nbsp;<xref ta
sn1-mod"/>. rget="sec-tls-identification" format="counter"/> and <xref target="sec-tcpcl-cer
The use of this OID is defined in <xref target="sec-tls-identification"/> and <x t-profile" format="counter"/>.
ref target="sec-tcpcl-cert-profile"/>. </t>
</t>
</section> </section>
<section anchor="sec-iana-pkix-kp-oid"> <section anchor="sec-iana-pkix-kp-oid">
<name>Object Identifier for PKIX Extended Key Usage</name> <name>Object Identifier for PKIX Extended Key Usage</name>
<t> <t>
IANA has created, under the "Structure of Management Information (SMI) Numbers" IANA has registered the following in the "SMI Security for PKIX Extended Key Pur
registry <xref target="IANA-SMI"/>, a sub-registry titled "SMI Security for PKIX pose" registry <xref target="IANA-SMI"/> for securing BP bundles.
Extended Key Purpose".
The extended key purpose table is updated to include a purpose "id-kp-bundleSecu
rity" for identifying DTN endpoints as in the following table.
</t> </t>
<table align="center"> <table anchor="tbl-id-kp-bundleSecurity" align="center">
<name>New PKIX Extended Key Purpose</name>
<thead> <thead>
<tr> <tr>
<th>Decimal</th> <th>Decimal</th>
<th>Description</th> <th>Description</th>
<th>References</th> <th>References</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>KP-TBD</td> <td>35</td>
<td>id-kp-bundleSecurity</td> <td>id-kp-bundleSecurity</td>
<td>This specification.</td> <td>This specification</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>The formal definition of this EKU is provided in <xref target="sec-asn1-mod"/
The formal definition of this EKU is in <xref target="sec-asn1-mod"/>. >. The use of this OID is defined in <xref target="sec-tcpcl-cert-profile"/>.</t
The use of this OID is defined in <xref target="sec-tcpcl-cert-profile"/>. >
</t>
</section> </section>
</section> </section>
<section anchor="sec-doc-ack">
<name>Acknowledgments</name>
<t>
This specification is based on comments on implementation of <xref target="RFC72
42"/> provided from Scott Burleigh.
</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-dtn-bibect" to="DTN-BIBECT"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="IANA-BUNDLE" target="https://www.iana.org/assignments /bundle/"> <reference anchor="IANA-BUNDLE" target="https://www.iana.org/assignments /bundle/">
<front> <front>
<title>Bundle Protocol</title> <title>Bundle Protocol</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="IANA-PORTS" target="https://www.iana.org/assignments/ service-names-port-numbers/"> <reference anchor="IANA-PORTS" target="https://www.iana.org/assignments/ service-names-port-numbers/">
<front> <front>
<title>Service Name and Transport Protocol Port Number Registry</tit le> <title>Service Name and Transport Protocol Port Number Registry</tit le>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="IANA-SMI" target="https://www.iana.org/assignments/sm i-numbers/"> <reference anchor="IANA-SMI" target="https://www.iana.org/assignments/sm i-numbers/">
<front> <front>
<title>Structure of Management Information (SMI) Numbers</title> <title>Structure of Management Information (SMI) Numbers (MIB Module Registrations)</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.0793.xml"/> FC.0793.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.1122.xml"/> FC.1122.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.2119.xml"/> FC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.3986.xml"/> FC.3986.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.5280.xml"/> FC.5280.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.6066.xml"/> FC.6066.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.6125.xml"/> FC.6125.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.6960.xml"/> FC.6960.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.7525.xml"/> FC.7525.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.8126.xml"/> FC.8126.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.8174.xml"/> FC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.8446.xml"/> FC.8446.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.ietf-dtn-bpbis.xml"/> <!-- draft-ietf-dtn-bpbis (RFC 9171) -->
<reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680-20 <reference anchor='RFC9171' target="https://www.rfc-editor.org/info/rfc9171">
1508-I/en"> <front>
<title>Bundle Protocol Version 7</title>
<author initials='S' surname='Burleigh' fullname='Scott Burleigh'>
<organization />
</author>
<author initials='K' surname='Fall' fullname='Kevin Fall'>
<organization />
</author>
<author initials="E." surname="Birrane, III" fullname="Edward J. Birrane, III">
<organization />
</author>
<date month='January' year='2022' />
</front>
<seriesInfo name="RFC" value="9171"/>
<seriesInfo name="DOI" value="10.17487/RFC9171"/>
</reference>
<reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680-20
2102-I/en">
<front> <front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1 ): Specification of basic notation</title> <title>Information technology - Abstract Syntax Notation One (ASN.1) : Specification of basic notation</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date month="August" year="2015"/> <date month="February" year="2021"/>
</front> </front>
<refcontent>ITU-T Recommendation X.680, ISO/IEC 8824-1:2015</refconten t> <refcontent>ITU-T Recommendation X.680, ISO/IEC 8824-1:2021</refconten t>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="AEAD-LIMITS" target="http://www.isg.rhul.ac.uk/~kp/TL
S-AEbounds.pdf"> <reference anchor="AEAD-LIMITS" target="https://www.isg.rhul.ac.uk/~kp/T
LS-AEbounds.pdf">
<front> <front>
<title>Limits on Authenticated Encryption Use in TLS</title> <title>Limits on Authenticated Encryption Use in TLS</title>
<author initials="A." surname="Luykx"/> <author initials="A." surname="Luykx"/>
<author initials="K." surname="Paterson"/> <author initials="K." surname="Paterson"/>
<date month="August" year="2017"/> <date month="August" year="2017"/>
</front> </front>
</reference> </reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.2595.xml"/> FC.2595.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.3552.xml"/> FC.3552.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.4511.xml"/> FC.4511.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.4838.xml"/> FC.4838.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.5489.xml"/> FC.5489.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.5912.xml"/> FC.5912.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.6698.xml"/> FC.6698.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.7122.xml"/> FC.7122.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.7242.xml"/> FC.7242.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.7250.xml"/> FC.7250.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.7435.xml"/> FC.7435.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.7457.xml"/> FC.7457.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.7942.xml"/> FC.8555.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8555.xml"/> <!-- draft-ietf-dtn-bpsec (RFC 9172) -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe <reference anchor='RFC9172' target="https://www.rfc-editor.org/info/rfc9172">
rence.I-D.ietf-dtn-bpsec.xml"/> <front>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe <title>Bundle Protocol Security (BPSec)</title>
rence.I-D.ietf-dtn-bibect.xml"/> <author initials="E." surname="Birrane, III" fullname="Edward J. Birrane, III">
<reference anchor="github-dtn-demo-agent" target="https://github.com/BSi <organization />
pos-RKF/dtn-demo-agent/"> </author>
<front> <author initials='K' surname='McKeever' fullname='Kenneth McKeever'>
<title>TCPCL Example Implementation</title> <organization />
<author fullname="Brian Sipos" initials="B." surname="Sipos"> </author>
<organization abbrev="RKF Engineering"> <date month='January' year='2022' />
RKF Engineering Solutions, LLC </front>
</organization> <seriesInfo name="RFC" value="9172"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC9172"/>
<date/> </reference>
</front>
</reference> <!-- draft-ietf-dtn-bibect (Expired) -->
<reference anchor="github-dtn-wireshark" target="https://github.com/BSip <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
os-RKF/dtn-wireshark/"> I-D.ietf-dtn-bibect.xml"/>
<front>
<title>TCPCL Wireshark Dissector</title>
<author fullname="Brian Sipos" initials="B." surname="Sipos">
<organization abbrev="RKF Engineering">
RKF Engineering Solutions, LLC
</organization>
</author>
<date/>
</front>
</reference>
</references> </references>
</references> </references>
<section> <section>
<name>Significant changes from RFC7242</name> <name>Significant Changes from RFC 7242</name>
<t> <t>
The areas in which changes from <xref target="RFC7242"/> have been made to exist ing headers and messages are: The areas in which changes from <xref target="RFC7242"/> have been made to exist ing headers and messages are as follows:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Split Contact Header into pre-TLS protocol negotiation and SESS_INIT parameter negotiation. The Contact Header is now fixed-length.</li> <li>Split Contact Header into pre-TLS protocol negotiation and SESS_INIT parameter negotiation. The Contact Header is now fixed length.</li>
<li>Changed Contact Header content to limit number of negotiated options .</li> <li>Changed Contact Header content to limit number of negotiated options .</li>
<li>Added session option to negotiate maximum segment size (per each dir ection).</li> <li>Added session option to negotiate maximum segment size (per each dir ection).</li>
<li>Renamed "Endpoint ID" to "Node ID" to conform with BPv7 terminology. </li> <li>Renamed "endpoint ID" to "node ID" to conform with BPv7 terminology. </li>
<li>Added session extension capability.</li> <li>Added session extension capability.</li>
<li>Added transfer extension capability. Moved transfer total length int o an extension item.</li> <li>Added transfer extension capability. Moved transfer total length int o an extension item.</li>
<li>Defined new IANA registries for message / type / reason codes to all ow renaming some codes for clarity.</li> <li>Defined new IANA registries for message / type / reason codes to all ow renaming some codes for clarity.</li>
<li>Segments of all new IANA registries are reserved for private/experim ental use.</li> <li>Pointed out that segments of all new IANA registries are reserved fo r private/experimental use.</li>
<li>Expanded Message Header to octet-aligned fields instead of bit-packi ng.</li> <li>Expanded Message Header to octet-aligned fields instead of bit-packi ng.</li>
<li>Added a bundle transfer identification number to all bundle-related messages (XFER_SEGMENT, XFER_ACK, XFER_REFUSE).</li> <li>Added a bundle transfer identification number to all bundle-related messages (XFER_SEGMENT, XFER_ACK, XFER_REFUSE).</li>
<li>Use flags in XFER_ACK to mirror flags from XFER_SEGMENT.</li> <li>Added flags in XFER_ACK to mirror flags from XFER_SEGMENT.</li>
<li>Removed all uses of SDNV fields and replaced with fixed-bit-length ( <li>Removed all uses of Self-Delimiting Numeric Value (SDNV) fields and
network byte order) fields.</li> replaced with fixed-bit-length (network byte order) fields.
</li>
<li>Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown" related to TCP connections.</li> <li>Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown" related to TCP connections.</li>
<li>Removed the notion of a re-connection delay parameter.</li> <li>Removed the notion of a reconnection delay parameter.</li>
</ul> </ul>
<t> <t>
The areas in which extensions from <xref target="RFC7242"/> have been made as ne w messages and codes are: The areas in which extensions from <xref target="RFC7242"/> have been made as ne w messages and codes are as follows:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Added contact negotiation failure SESS_TERM reason code.</li> <li>Added MSG_REJECT message to indicate that an unknown or unhandled me
<li>Added MSG_REJECT message to indicate an unknown or unhandled message ssage was received.</li>
was received.</li>
<li>Added TLS connection security mechanism.</li> <li>Added TLS connection security mechanism.</li>
<li>Added "Not Acceptable", "Extension Failure", and "Session Terminatin g" XFER_REFUSE reason codes.</li> <li>Added "Not Acceptable", "Extension Failure", and "Session Terminatin g" XFER_REFUSE reason codes.</li>
<li>Added "Resource Exhaustion" SESS_TERM reason code.</li> <li>Added "Contact Failure" (contact negotiation failure) and "Resource Exhaustion" SESS_TERM reason codes.</li>
</ul> </ul>
</section> </section>
<section anchor="sec-asn1-mod"> <section anchor="sec-asn1-mod">
<name>ASN.1 Module</name> <name>ASN.1 Module</name>
<t> <t>
The following ASN.1 module formally specifies the <tt>BundleEID</tt> structure, its Other Name form, and the <tt>bundleSecurity</tt> Extended Key Usage in the s yntax of <xref target="X.680"/>. The following ASN.1 module formally specifies the <tt>BundleEID</tt> structure, its Other Name Form, and the <tt>bundleSecurity</tt> EKU, using ASN.1 syntax per <xref target="X.680"/>.
This specification uses the ASN.1 definitions from <xref target="RFC5912"/> with the 2002 ASN.1 notation used in that document. This specification uses the ASN.1 definitions from <xref target="RFC5912"/> with the 2002 ASN.1 notation used in that document.
</t> </t>
<sourcecode markers="true" type="asn.1"> <sourcecode markers="true" type="asn.1">
DTN-TCPCLv4-2021
DTN-TCPCLPv4-2021
{ iso(1) identified-organization(3) dod(6) { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-dtn-tcpclv4-2021(MOD-TBD) } id-mod-dtn-tcpclv4-2021(103) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
OTHER-NAME OTHER-NAME
FROM PKIX1Implicit-2009 -- [RFC5912] FROM PKIX1Implicit-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-implicit-02(59) } id-mod-pkix1-implicit-02(59) }
skipping to change at line 3170 skipping to change at line 3147
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) } ; id-mod-pkix1-explicit-02(51) } ;
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 } id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
DTNOtherNames OTHER-NAME ::= { on-bundleEID, ... } DTNOtherNames OTHER-NAME ::= { on-bundleEID, ... }
-- The otherName definition for BundleEID
on-bundleEID OTHER-NAME ::= { on-bundleEID OTHER-NAME ::= {
BundleEID IDENTIFIED BY { id-on-bundleEID } BundleEID IDENTIFIED BY { id-on-bundleEID }
} }
id-on-bundleEID OBJECT IDENTIFIER ::= { id-on ON-TBD } id-on-bundleEID OBJECT IDENTIFIER ::= { id-on 11 }
-- Same encoding as GeneralName of uniformResourceIdentifier -- Same encoding as GeneralName of uniformResourceIdentifier
BundleEID ::= IA5String BundleEID ::= IA5String
-- The Extended Key Usage key for bundle security -- The Extended Key Usage key for bundle security
id-kp-bundleSecurity OBJECT IDENTIFIER ::= { id-kp KP-TBD } id-kp-bundleSecurity OBJECT IDENTIFIER ::= { id-kp 35 }
END END
</sourcecode> </sourcecode>
</section> </section>
<section> <section>
<name>Example of the BundleEID Other Name Form</name> <name>Example of the BundleEID Other Name Form</name>
<t>EDITOR NOTE: The encoded hex part "0b" and OID segment "11" are to be r eplaced by ON-TBD allocated value. It was necessary to choose some OID value, so I chose the first not-allocated code point.</t>
<t> <t>
This non-normative example demonstrates an otherName with a name form of <tt>Bun dleEID</tt> to encode the Node ID "dtn://example/". This non-normative example demonstrates an otherName with a name form of <tt>Bun dleEID</tt> to encode the node ID "dtn://example/".
</t> </t>
<t> <t>
The hexadecimal form of the DER encoding of the otherName is: The hexadecimal form of the DER encoding of the otherName is as follows:
</t> </t>
<sourcecode type="hex"> <sourcecode type="hex">
a01c06082b0601050507080ba010160e64746e3a2f2f6578616d706c652f a01c06082b0601050507080ba010160e64746e3a2f2f6578616d706c652f
</sourcecode> </sourcecode>
<t> <t>
And the text decoding in <xref target="fig-example-dtneid"/> is an output of Pet er Gutmann's "dumpasn1" program. And the text decoding in <xref target="fig-example-dtneid"/> is an output of Pet er Gutmann's "dumpasn1" program.
</t> </t>
<figure anchor="fig-example-dtneid"> <figure anchor="fig-example-dtneid">
<name>Visualized decoding of the <tt>on-bundleEID</tt></name> <name>Visualized Decoding of the on-bundleEID</name>
<artwork align="left" type="ascii-art"> <artwork align="left" type="ascii-art">
0 28: [0] { 0 28: [0] {
2 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 11' 2 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 11'
12 16: [0] { 12 16: [0] {
14 14: IA5String 'dtn://example/' 14 14: IA5String 'dtn://example/'
: } : }
: } : }
</artwork> </artwork>
</figure> </figure>
</section> </section>
<section anchor="sec-doc-ack" numbered="false">
<name>Acknowledgments</name>
<t>
This specification is based on comments regarding the implementation of <xref ta
rget="RFC7242"/> as provided by <contact fullname="Scott Burleigh"/>.
</t>
<t>
The ASN.1 module and its Other Name Form are based on a recommendation provided
by Russ Housley.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 417 change blocks. 
1373 lines changed or deleted 1391 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/