draft-ietf-dtn-tcpclv4-00.txt   draft-ietf-dtn-tcpclv4-01.txt 
Delay Tolerant Networking B. Sipos Delay Tolerant Networking B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Obsoletes: RFC7242 (if approved) M. Demmer Obsoletes: RFC7242 (if approved) M. Demmer
Intended status: Standards Track UC Berkeley Intended status: Standards Track UC Berkeley
Expires: April 22, 2017 J. Ott Expires: May 31, 2017 J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
October 19, 2016 November 27, 2016
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-00 draft-ietf-dtn-tcpclv4-01
Abstract Abstract
This document describes a revised protocol for the TCP-based This document describes a revised protocol for the TCP-based
convergence layer for Delay-Tolerant Networking (DTN). The protocol convergence layer for Delay-Tolerant Networking (DTN). The protocol
revision is based on implementation issues in the original [RFC7242] revision is based on implementation issues in the original [RFC7242]
and updates to the Bundle Protocol contents, encodings, and and updates to the Bundle Protocol contents, encodings, and
convergence layer requirements in [I-D.ietf-dtn-bpbis]. The majority convergence layer requirements in [I-D.ietf-dtn-bpbis].
of this specification is unchanged from TCPCL version 3.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2017. This Internet-Draft will expire on May 31, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 28
4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 8 4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 8
4.2. Validation and Parameter Negotiation . . . . . . . . . . 10 4.2. Validation and Parameter Negotiation . . . . . . . . . . 10
5. Established Session Operation . . . . . . . . . . . . . . . . 11 5. Established Session Operation . . . . . . . . . . . . . . . . 11
5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 11 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 11
5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 12 5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 12
5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 12 5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 12
5.2.2. Message Rejection (REJECT) . . . . . . . . . . . . . 13 5.2.2. Message Rejection (REJECT) . . . . . . . . . . . . . 13
5.3. Session Security . . . . . . . . . . . . . . . . . . . . 14 5.3. Session Security . . . . . . . . . . . . . . . . . . . . 14
5.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 14 5.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 14
5.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 15 5.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 15
5.4. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 16 5.4. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 15
5.4.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 16 5.4.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 16
5.4.2. Bundle Length (LENGTH) . . . . . . . . . . . . . . . 16 5.4.2. Bundle Length (LENGTH) . . . . . . . . . . . . . . . 16
5.4.3. Bundle Data Transmission (DATA_SEGMENT) . . . . . . . 17 5.4.3. Bundle Data Transmission (DATA_SEGMENT) . . . . . . . 17
5.4.4. Bundle Acknowledgments (ACK_SEGMENT) . . . . . . . . 18 5.4.4. Bundle Acknowledgments (ACK_SEGMENT) . . . . . . . . 18
5.4.5. Bundle Refusal (REFUSE_BUNDLE) . . . . . . . . . . . 19 5.4.5. Bundle Refusal (REFUSE_BUNDLE) . . . . . . . . . . . 19
6. Session Termination . . . . . . . . . . . . . . . . . . . . . 20 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 21
6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 21 6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 21
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 23 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 25 8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 25
8.3. Message Types . . . . . . . . . . . . . . . . . . . . . . 25 8.3. Message Types . . . . . . . . . . . . . . . . . . . . . . 26
8.4. REFUSE_BUNDLE Reason Codes . . . . . . . . . . . . . . . 26 8.4. REFUSE_BUNDLE Reason Codes . . . . . . . . . . . . . . . 26
8.5. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 27 8.5. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 27
8.6. REJECT Reason Codes . . . . . . . . . . . . . . . . . . . 27 8.6. REJECT Reason Codes . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 29 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
skipping to change at page 3, line 18 skipping to change at page 3, line 18
Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to-
end architecture providing communications in and/or through highly end architecture providing communications in and/or through highly
stressed environments, including those with intermittent stressed environments, including those with intermittent
connectivity, long and/or variable delays, and high bit error rates. connectivity, long and/or variable delays, and high bit error rates.
More detailed descriptions of the rationale and capabilities of these More detailed descriptions of the rationale and capabilities of these
networks can be found in "Delay-Tolerant Network Architecture" networks can be found in "Delay-Tolerant Network Architecture"
[RFC4838]. [RFC4838].
An important goal of the DTN architecture is to accommodate a wide An important goal of the DTN architecture is to accommodate a wide
range of networking technologies and environments. The protocol used range of networking technologies and environments. The protocol used
for DTN communications is the revsided Bundle Protocol (BP) for DTN communications is the revised Bundle Protocol (BP)
[I-D.ietf-dtn-bpbis], an application-layer protocol that is used to [I-D.ietf-dtn-bpbis], an application-layer protocol that is used to
construct a store-and- forward overlay network. As described in the construct a store-and- forward overlay network. As described in the
Bundle Protocol specification [I-D.ietf-dtn-bpbis], it requires the Bundle Protocol specification [I-D.ietf-dtn-bpbis], it requires the
services of a "convergence- layer adapter" (CLA) to send and receive services of a "convergence- layer adapter" (CLA) to send and receive
bundles using the service of some "native" link, network, or Internet bundles using the service of some "native" link, network, or Internet
protocol. This document describes one such convergence-layer adapter protocol. This document describes one such convergence-layer adapter
that uses the well-known Transmission Control Protocol (TCP). This that uses the well-known Transmission Control Protocol (TCP). This
convergence layer is referred to as TCPCL. convergence layer is referred to as TCPCL.
The locations of the TCPCL and the BP in the Internet model protocol The locations of the TCPCL and the BP in the Internet model protocol
skipping to change at page 5, line 22 skipping to change at page 5, line 22
First, one node establishes a TCPCL session to the other by First, one node establishes a TCPCL session to the other by
initiating a TCP connection. After setup of the TCP connection is initiating a TCP connection. After setup of the TCP connection is
complete, an initial contact header is exchanged in both directions complete, an initial contact header is exchanged in both directions
to set parameters of the TCPCL session and exchange a singleton to set parameters of the TCPCL session and exchange a singleton
endpoint identifier for each node (not the singleton Endpoint endpoint identifier for each node (not the singleton Endpoint
Identifier (EID) of any application running on the node) to denote Identifier (EID) of any application running on the node) to denote
the bundle-layer identity of each DTN node. This is used to assist the bundle-layer identity of each DTN node. This is used to assist
in routing and forwarding messages, e.g., to prevent loops. in routing and forwarding messages, e.g., to prevent loops.
Once the TCPCL session is established and configured in this way, Once the TCPCL session is established and configured in this way,
bundles can be transmitted in either direction. Each bundle is bundles can be transferred in either direction. Each transfer is
transmitted in one or more logical segments of formatted bundle data. performed in one or more logical segments of data. Each logical data
Each logical data segment consists of a DATA_SEGMENT message header, segment consists of a DATA_SEGMENT message header, a count of the
a count of the length of the segment, and finally the octet range of length of the segment, and finally the octet range of the bundle
the bundle data. The choice of the length to use for segments is an data. The choice of the length to use for segments is an
implementation matter. The first segment for a bundle MUST set the implementation matter (but must be within the Segment MRU size of
'start' flag, and the last one MUST set the 'end' flag in the Section 4.1). The first segment for a bundle MUST set the 'start'
DATA_SEGMENT message header. flag, and the last one MUST set the 'end' flag in the DATA_SEGMENT
message header.
If multiple bundles are transmitted on a single TCPCL connection, If multiple bundles are transmitted on a single TCPCL connection,
they MUST be transmitted consecutively. Interleaving data segments they MUST be transmitted consecutively. Interleaving data segments
from different bundles is not allowed. Bundle interleaving can be from different bundles is not allowed. Bundle interleaving can be
accomplished by fragmentation at the BP layer or by establishing accomplished by fragmentation at the BP layer or by establishing
multiple TCPCL sessions. multiple TCPCL sessions.
A feature of this protocol is for the receiving node to send A feature of this protocol is for the receiving node to send
acknowledgments as bundle data segments arrive (ACK_SEGMENT). The acknowledgments as bundle data segments arrive (ACK_SEGMENT). The
rationale behind these acknowledgments is to enable the sender node rationale behind these acknowledgments is to enable the sender node
skipping to change at page 7, line 12 skipping to change at page 7, line 12
No errors or rejections are shown in this example. No errors or rejections are shown in this example.
Node A Node B Node A Node B
====== ====== ====== ======
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
| Contact Header | -> <- | Contact Header | | Contact Header | -> <- | Contact Header |
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| LENGTH | ->
| Transfer ID [I1] |
| Total Length [L1] |
+-------------------------+
+-------------------------+
| DATA_SEGMENT (start) | -> | DATA_SEGMENT (start) | ->
| Transfer ID [I1] | -> | Transfer ID [I1] |
| Length [L1] | -> | Length [L1] |
| Bundle Data 0..(L1-1) | -> | Bundle Data 0..(L1-1) |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
| DATA_SEGMENT | -> <- | ACK_SEGMENT | | DATA_SEGMENT | -> <- | ACK_SEGMENT (start) |
| Transfer ID [I1] | -> <- | Transfer ID [I1] | | Transfer ID [I1] | | Transfer ID [I1] |
| Length [L2] | -> <- | Length [L1] | | Length [L2] | | Length [L1] |
|Bundle Data L1..(L1+L2-1)| -> +-------------------------+ |Bundle Data L1..(L1+L2-1)| +-------------------------+
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
| DATA_SEGMENT (end) | -> <- | ACK_SEGMENT | | DATA_SEGMENT (end) | -> <- | ACK_SEGMENT |
| Transfer ID [I1] | -> <- | Transfer ID [I1] | | Transfer ID [I1] | | Transfer ID [I1] |
| Length [L3] | -> <- | Length [L1+L2] | | Length [L3] | | Length [L1+L2] |
|Bundle Data | -> +-------------------------+ |Bundle Data | +-------------------------+
| (L1+L2)..(L1+L2+L3-1)| | (L1+L2)..(L1+L2+L3-1)|
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
<- | ACK_SEGMENT | <- | ACK_SEGMENT (end) |
<- | Transfer ID [I1] | | Transfer ID [I1] |
<- | Length [L1+L2+L3] | | Length [L1+L2+L3] |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
| SHUTDOWN | -> <- | SHUTDOWN | | SHUTDOWN | -> <- | SHUTDOWN |
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
Figure 2: A Simple Visual Example of the Flow of Protocol Messages on Figure 2: A Simple Visual Example of the Flow of Protocol Messages on
a Single TCP Session between Two Nodes (A and B) a Single TCP Session between Two Nodes (A and B)
4. Session Establishment 4. Session Establishment
skipping to change at page 11, line 14 skipping to change at page 11, line 16
A node calculates the parameters for a TCPCL session by negotiating A node calculates the parameters for a TCPCL session by negotiating
the values from its own preferences (conveyed by the contact header the values from its own preferences (conveyed by the contact header
it sent to the peer) with the preferences of the peer node (expressed it sent to the peer) with the preferences of the peer node (expressed
in the contact header that it received from the peer). The in the contact header that it received from the peer). The
negotatiated parameters defined by this specification are described negotatiated parameters defined by this specification are described
in the following paragraphs. in the following paragraphs.
Session Keepalive: Negotiation of the Session Keepalive parameter is Session Keepalive: Negotiation of the Session Keepalive parameter is
performed by taking the minimum of this two contact headers' performed by taking the minimum of this two contact headers'
Keepalive Interval. If the negotiated Session Keepalve is zero Keepalive Interval. If the negotiated Session Keepalive is zero
(i.e. one or both contact headers contains a zero Keepalive (i.e. one or both contact headers contains a zero Keepalive
Interval), then the keepalive feature (described in Section 5.2.1) Interval), then the keepalive feature (described in Section 5.2.1)
is disabled. is disabled.
Enable TLS: Negotiation of the Enable TLS parameter is performed by Enable TLS: Negotiation of the Enable TLS parameter is performed by
taking the logical AND of the two contact headers' CAN_TLS flags. taking the logical AND of the two contact headers' CAN_TLS flags.
If the negotiated Enable TLS value is true then TLS negotiation If the negotiated Enable TLS value is true then TLS negotiation
feature (described in Section 5.3) begins immediately following feature (described in Section 5.3) begins immediately following
the contact header exchange. the contact header exchange.
Once this process of parameter negotiation is completed, the protocol Once this process of parameter negotiation is completed, the protocol
defines no additional mechanism to change the parameters of an defines no additional mechanism to change the parameters of an
established session; to effect such a change, the session MUST be established session; to effect such a change, the session MUST be
terminated and a new session established. terminated and a new session established.
5. Established Session Operation 5. Established Session Operation
This section describes the protocol operation for the duration of an This section describes the protocol operation for the duration of an
established session, including the mechanisms for transmitting established session, including the mechanism for transmitting bundles
bundles over the session. over the session.
5.1. Message Type Codes 5.1. Message Type Codes
After the initial exchange of a contact header, all messages After the initial exchange of a contact header, all messages
transmitted over the session are identified by a one-octet header transmitted over the session are identified by a one-octet header
with the following structure: with the following structure:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| type | flags | | type | flags |
skipping to change at page 12, line 32 skipping to change at page 12, line 34
| | | described in Section 5.2.1. | | | | described in Section 5.2.1. |
| | | | | | | |
| SHUTDOWN | 0x5 | Indicates that one of the nodes | | SHUTDOWN | 0x5 | Indicates that one of the nodes |
| | | participating in the session wishes to | | | | participating in the session wishes to |
| | | cleanly terminate the session, as | | | | cleanly terminate the session, as |
| | | described in Section 6. | | | | described in Section 6. |
| | | | | | | |
| LENGTH | 0x6 | Contains the length (in octets) of the | | LENGTH | 0x6 | Contains the length (in octets) of the |
| | | next bundle, as described in Section | | | | next bundle, as described in Section |
| | | 5.4.2. | | | | 5.4.2. |
| | | |
| REJECT | TBD | Contains a TCPCL message rejection, as |
| | | described in Section 5.2.2. |
+---------------+------+--------------------------------------------+ +---------------+------+--------------------------------------------+
Table 2: TCPCL Message Types Table 2: TCPCL Message Types
5.2. Upkeep and Status Messages 5.2. Upkeep and Status Messages
5.2.1. Session Upkeep (KEEPALIVE) 5.2.1. Session Upkeep (KEEPALIVE)
The protocol includes a provision for transmission of KEEPALIVE The protocol includes a provision for transmission of KEEPALIVE
messages over the TCPCL session to help determine if the underlying messages over the TCPCL session to help determine if the underlying
TCP connection has been disrupted. TCP connection has been disrupted.
As described in Section 4.1, one of the parameters in the contact As described in Section 4.1, one of the parameters in the contact
header is the keepalive_interval. Both sides populate this field header is the Keepalive Interval. Both sides populate this field
with their requested intervals (in seconds) between KEEPALIVE with their requested intervals (in seconds) between KEEPALIVE
messages. messages.
The format of a KEEPALIVE message is a one-octet message type code of The format of a KEEPALIVE message is a one-octet message type code of
KEEPALIVE (as described in Table 2) with no additional data. Both KEEPALIVE (as described in Table 2) with no additional data. Both
sides SHOULD send a KEEPALIVE message whenever the negotiated sides SHOULD send a KEEPALIVE message whenever the negotiated
interval has elapsed with no transmission of any message (KEEPALIVE interval has elapsed with no transmission of any message (KEEPALIVE
or other). or other).
If no message (KEEPALIVE or other) has been received for at least If no message (KEEPALIVE or other) has been received for at least
twice the keepalive_interval, then either party MAY terminate the twice the Keepalive Interval, then either party MAY terminate the
session by transmitting a one-octet SHUTDOWN message (as described in session by transmitting a one-octet SHUTDOWN message (as described in
Table 2) and by closing the session. Table 2, with reason code "Idle Timeout") and by closing the session.
Note: The keepalive_interval SHOULD not be chosen too short as TCP Note: The Keepalive Interval SHOULD not be chosen too short as TCP
retransmissions MAY occur in case of packet loss. Those will have to retransmissions MAY occur in case of packet loss. Those will have to
be triggered by a timeout (TCP retransmission timeout (RTO)), which be triggered by a timeout (TCP retransmission timeout (RTO)), which
is dependent on the measured RTT for the TCP connection so that is dependent on the measured RTT for the TCP connection so that
KEEPALIVE messages MAY experience noticeable latency. KEEPALIVE messages MAY experience noticeable latency.
5.2.2. Message Rejection (REJECT) 5.2.2. Message Rejection (REJECT)
If a TCPCL endpoint receives a message which is uknown to it If a TCPCL endpoint receives a message which is unknown to it
(possibly due to an unhandled protocol mismatch) or is inappropriate (possibly due to an unhandled protocol mismatch) or is inappropriate
for the current session state (e.g. a KEEPALIVE or LENGTH message for the current session state (e.g. a KEEPALIVE message received
received after feature negotation has disabled those features), there after contact header negotation has disabled that feature), there is
is a protocol-level message to signal this condition in the form of a a protocol-level message to signal this condition in the form of a
REJECT reply. REJECT reply.
The format of a REJECT message follows: The format of a REJECT message follows:
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Reason Code (U8) | | Reason Code (U8) |
+-----------------------------+ +-----------------------------+
| Rejected Message Header | | Rejected Message Header |
skipping to change at page 14, line 27 skipping to change at page 14, line 27
| Unexpected | | in a state in which the message is not | | Unexpected | | in a state in which the message is not |
| | | expected. | | | | expected. |
+-------------+------+----------------------------------------------+ +-------------+------+----------------------------------------------+
Table 3: REJECT Reason Codes Table 3: REJECT Reason Codes
5.3. Session Security 5.3. Session Security
This version of the TCPCL supports establishing a session-level This version of the TCPCL supports establishing a session-level
Transport Layer Security (TLS) session within an existing TCPCL Transport Layer Security (TLS) session within an existing TCPCL
session. session. Negotation of whether or not to initiate TLS within TCPCL
session is part of the contact header as described in Section 4.2.
When TLS is used within the TCPCL it affects the entire session. By When TLS is used within the TCPCL it affects the entire session. By
convention, this protocol uses the endpoint which initiated the convention, this protocol uses the endpoint which initiated the
underlying TCP connection as the "client" role of the TLS handshake underlying TCP connection as the "client" role of the TLS handshake
request. Once a TLS session is established within TCPCL, there is no request. Once a TLS session is established within TCPCL, there is no
mechanism provided to end the TLS session and downgrade the session. mechanism provided to end the TLS session and downgrade the session.
If a non-TLS session is desired after a TLS session is started then If a non-TLS session is desired after a TLS session is started then
the entire TCPCL session MUST be shutdown first. the entire TCPCL session MUST be shutdown first.
After negotiating an Enable TLS parameter of true, and before any After negotiating an Enable TLS parameter of true, and before any
other TCPCL messages are sent within the session, the session other TCPCL messages are sent within the session, the session
endpoints SHALL begin a TLS handshake in accordance with [RFC5246]. endpoints SHALL begin a TLS handshake in accordance with [RFC5246].
The parameters within each TLS negotation are implementation The parameters within each TLS negotation are implementation
dependent but any TCPCL endpoint SHOULD follow all recommended best dependent but any TCPCL endpoint SHOULD follow all recommended best
practices of [RFC7525]. practices of [RFC7525].
5.3.1. TLS Handshake Result 5.3.1. TLS Handshake Result
If a TLS handshake cannot negotiate a TLS session, both endpoints of If a TLS handshake cannot negotiate a TLS session, both endpoints of
the TCPCL session SHALL cause a TCPCL shutdown with reason "TLS the TCPCL session SHALL cause a TCPCL shutdown with reason "TLS
negotiation failed". Unless the TLS parameters change between two negotiation failed".
sequential handshakes, the subsequent handshake is likely to fail
just as the earlier one.
After a TLS session is successfuly established, both TCPCL endpoints After a TLS session is successfuly established, both TCPCL endpoints
SHALL re-exchange TCPCL Contact Header messages. Any information SHALL re-exchange TCPCL Contact Header messages. Any information
cached from the prior Contact Header exchange SHALL be discarded. cached from the prior Contact Header exchange SHALL be discarded.
This re-exchange avoids man-in-the-middle attack in identical fashon This re-exchange avoids man-in-the-middle attack in identical fashion
to [RFC2595]. to [RFC2595].
5.3.2. Example TLS Initiation 5.3.2. Example TLS Initiation
A summary of a typical CAN_TLS usage is shown in the sequence below A summary of a typical CAN_TLS usage is shown in the sequence in
where the client/requester role is represented by the prefix "C" and Figure 6 below.
the server/responder role is represented by the prefix "S".
Unordered or "simultaneous" actions are shown as "C/S".
Node A Node B Node A Node B
====== ====== ====== ======
+-------------------------+ +-------------------------+
| Open TCP Connnection | -> | Open TCP Connnection | ->
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
<- | Accept Connection | <- | Accept Connection |
+-------------------------+ +-------------------------+
skipping to change at page 16, line 10 skipping to change at page 15, line 49
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
Figure 6: A simple visual example of TCPCL TLS Establishment between Figure 6: A simple visual example of TCPCL TLS Establishment between
two nodes two nodes
5.4. Bundle Transfer 5.4. Bundle Transfer
All of the message in this section are directly associated with All of the message in this section are directly associated with
tranfering a bundle between TCPCL endpoints. tranfering a bundle between TCPCL endpoints.
A single TCPCL transfer results in a bundle (handled by the
convergence layer as opaque data) being exchanged from one endpoint
to the other. In TCPCL a transfer is accomplished by dividing a
single bundle up into "segments" based on the receving-side Segment
MRU (see Section 4.1).
A single transfer (and by extension a single segment) SHALL NOT
contain data of more than a single bundle. This requirement is
imposed on the agent using the TCPCL rather than TCPCL itself.
5.4.1. Bundle Transfer ID 5.4.1. Bundle Transfer ID
Each of the bundle transfer messages contains a Transfer ID number Each of the bundle transfer messages contains a Transfer ID number
which is used to correlate messages originating from sender and which is used to correlate messages originating from sender and
receiver of a bundle. The Transfer ID provides a similar behaivior receiver of a bundle. A Transfer ID does not attempt to address
to a datagram sequence number. A Transfer ID does not attempt to uniqueness of the bundle data itself and has no relation to concepts
address uniqueness of the bundle data itself and has no relation to such as bundle fragmentation. Each invocation of TCPCL by the bundle
concepts such as bundle fragmentation. Transmitting the same bundle protocol agent, requesting transmission of a bundle (fragmentary or
repeatedly, or fragments of the same bundle, or any other combination otherwise), results in the initiation of a single TCPCL transfer.
will result in a unique Transfer ID for each transmission sequence. Each transfer entails the sending of a LENGTH message and some number
of DATA_SEGMENT and ACK_SEGMENT messages; all are correlated by the
same Transfer ID.
Transfer IDs from each endpoint SHALL be unique within a single TCPCL Transfer IDs from each endpoint SHALL be unique within a single TCPCL
session. The initial Transfer ID from each endpoint SHALL have value session. The initial Transfer ID from each endpoint SHALL have value
zero. Subsequent Transfer ID values SHALL be incremented from the zero. Subsequent Transfer ID values SHALL be incremented from the
prior Transfer ID value by one. Upon exhaustion of the entire 64-bit prior Transfer ID value by one. Upon exhaustion of the entire 64-bit
Transfer ID space, the sending endpoint SHALL terminate the session Transfer ID space, the sending endpoint SHALL terminate the session
with SHUTDOWN reason code "Resource Exhaustion". with SHUTDOWN reason code "Resource Exhaustion".
For bidirectional bundle transfers, a TCPCL endpoint SHOULD NOT rely For bidirectional bundle transfers, a TCPCL endpoint SHOULD NOT rely
on any relation between Transfer IDs originating from each side of on any relation between Transfer IDs originating from each side of
the TCPCL session. the TCPCL session.
5.4.2. Bundle Length (LENGTH) 5.4.2. Bundle Length (LENGTH)
The LENGTH message contains the total length, in octets, of the next The LENGTH message contains the total length, in octets, of the
bundle, formatted as a 64-bit unsigned integer. Its purpose is to bundle data in the associated transfer. The total length is
allow nodes to preemptively refuse bundles that would exceed their formatted as a 64-bit unsigned integer.
resources or to prepare storage on the receiving node for the
upcoming bundle data. The Total Bundle Length field within a LENGTH The purpose of the LENGTH message is to allow nodes to preemptively
message SHALL be used as informative data by the receiver. If, for refuse bundles that would exceed their resources or to prepare
whatever reason, the actual total legnth of bundle data received storage on the receiving node for the upcoming bundle data. See
differs from the value indicated by the LENGTH message, the receiver Section 5.4.5 for details on when refusal based on LENGTH content is
SHOULD accept the full set of bundle data as valid. acceptable.
The Total Bundle Length field within a LENGTH message SHALL be used
as informative data by the receiver. If, for whatever reason, the
actual total length of bundle data received differs from the value
indicated by the LENGTH message, the receiver SHOULD accept the full
set of bundle data as valid.
The format of the LENGTH message is as follows: The format of the LENGTH message is as follows:
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Transfer ID (U64) | | Transfer ID (U64) |
+-----------------------------+ +-----------------------------+
| Total bundle length (U64) | | Total bundle length (U64) |
+-----------------------------+ +-----------------------------+
Figure 7: Format of LENGTH Messages Figure 7: Format of LENGTH Messages
LENGTH messages SHALL be sent immediately before transmission of any LENGTH messages SHALL be sent immediately before transmission of any
DATA_SEGMENT messages. LENGTH messages MUST NOT be sent unless the DATA_SEGMENT messages. LENGTH messages MUST NOT be sent unless the
next DATA_SEGMENT message has the 'S' bit set to "1" (i.e., just next DATA_SEGMENT message has the 'S' bit set to "1" (i.e., just
before the start of a new bundle). before the start of a new transfer).
A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a
LENGTH message without waiting for the next DATA_SEGMENT message. LENGTH message without waiting for the next DATA_SEGMENT message.
The sender MUST be prepared for this and MUST associate the refusal The sender MUST be prepared for this and MUST associate the refusal
with the correct bundle via the Transfer ID fields. with the correct bundle via the Transfer ID fields.
Upon reception of a LENGTH message not immediately before the start Upon reception of a LENGTH message not immediately before the start
of a starting DATA_SEGMENT the reciever SHALL send a REJECT message of a starting DATA_SEGMENT the reciever SHALL send a REJECT message
with a Reason Code of "Message Unexpected". with a Reason Code of "Message Unexpected".
skipping to change at page 17, line 46 skipping to change at page 18, line 4
| Message Header | | Message Header |
+------------------------------+ +------------------------------+
| Transfer ID (U64) | | Transfer ID (U64) |
+------------------------------+ +------------------------------+
| Data length (U64) | | Data length (U64) |
+------------------------------+ +------------------------------+
| Data contents (octet string) | | Data contents (octet string) |
+------------------------------+ +------------------------------+
Figure 8: Format of DATA_SEGMENT Messages Figure 8: Format of DATA_SEGMENT Messages
4 5 6 7 4 5 6 7
+-+-+-+-+ +-+-+-+-+
|0|0|S|E| |0|0|S|E|
+-+-+-+-+ +-+-+-+-+
Figure 9: Format of DATA_SEGMENT Header flags Figure 9: Format of DATA_SEGMENT Header flags
The type portion of the message header contains the value 0x1.
The flags portion of the message header octet contains two optional The flags portion of the message header octet contains two optional
values in the two low-order bits, denoted 'S' and 'E' above. The 'S' values in the two low-order bits, denoted 'S' and 'E' in Figure 9.
bit MUST be set to one if it precedes the transmission of the first The 'S' bit MUST be set to one if it precedes the transmission of the
segment of a new bundle. The 'E' bit MUST be set to one when first segment of a transfer. The 'E' bit MUST be set to one when
transmitting the last segment of a bundle. In the case where an transmitting the last segment of a transfer. In the case where an
entire transfer is accomplished in a single segment, both the 'S' and entire transfer is accomplished in a single segment, both the 'S' and
'E' bits MUST be set to one. 'E' bits MUST be set to one.
Following the message header, the length field is a 64-bit unsigned Following the message header, the length field is a 64-bit unsigned
integer containing the number of octets of bundle data that are integer containing the number of octets of bundle data that are
transmitted in this segment. Following this length is the actual transmitted in this segment. Following the length are the actual
data contents. data contents.
Once a transmission of a bundle has commenced, the node MUST only Once a transfer of a bundle has commenced, the node MUST only send
send segments containing sequential portions of that bundle until it segments containing sequential portions of that bundle until it sends
sends a segment with the 'E' bit set. a segment with the 'E' bit set. No interleaving of multiple
transfers from the same endpoint is possible (within a single TCPCL
session).
5.4.4. Bundle Acknowledgments (ACK_SEGMENT) 5.4.4. Bundle Acknowledgments (ACK_SEGMENT)
Although the TCP transport provides reliable transfer of data between Although the TCP transport provides reliable transfer of data between
transport peers, the typical BSD sockets interface provides no means transport peers, the typical BSD sockets interface provides no means
to inform a sending application of when the receiving application has to inform a sending application of when the receiving application has
processed some amount of transmitted data. Thus, after transmitting processed some amount of transmitted data. Thus, after transmitting
some data, a Bundle Protocol agent needs an additional mechanism to some data, a Bundle Protocol agent needs an additional mechanism to
determine whether the receiving agent has successfully received the determine whether the receiving agent has successfully received the
segment. To this end, the TCPCL protocol provides feedback messaging segment. To this end, the TCPCL protocol provides feedback messaging
skipping to change at page 18, line 51 skipping to change at page 19, line 15
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Transfer ID (U64) | | Transfer ID (U64) |
+-----------------------------+ +-----------------------------+
| Acknowledged length (U64) | | Acknowledged length (U64) |
+-----------------------------+ +-----------------------------+
Figure 10: Format of ACK_SEGMENT Messages Figure 10: Format of ACK_SEGMENT Messages
To transmit an acknowledgment, a node first transmits a message A receving TCPCL endpoing SHALL send an ACK_SEGMENT message in
header with the ACK_SEGMENT type code and all flags set to zero, then response to each received DATA_SEGMENT message. The flags portion of
transmits a 64-bit unsigned integer containing the cumulative length the ACK_SEGMENT header SHALL be set to match the corresponding
in octets of the received segment(s) of the current bundle. The DATA_SEGEMNT message being acknowledged. The acknowledged length of
length MUST fall on a segment boundary. That is, only full segments each ACK_SEGMENT contains the sum of the data length fields of all
can be acknowledged. DATA_SEGMENT messages received so far in the course of the indicated
transfer.
For example, suppose the sending node transmits four segments of For example, suppose the sending node transmits four segments of
bundle data with lengths 100, 200, 500, and 1000, respectively. bundle data with lengths 100, 200, 500, and 1000, respectively.
After receiving the first segment, the node sends an acknowledgment After receiving the first segment, the node sends an acknowledgment
of length 100. After the second segment is received, the node sends of length 100. After the second segment is received, the node sends
an acknowledgment of length 300. The third and fourth an acknowledgment of length 300. The third and fourth
acknowledgments are of length 800 and 1800, respectively. acknowledgments are of length 800 and 1800, respectively.
5.4.5. Bundle Refusal (REFUSE_BUNDLE) 5.4.5. Bundle Refusal (REFUSE_BUNDLE)
As bundles can be large, the TCPCL supports an optional mechanisms by As bundles can be large, the TCPCL supports an optional mechanism by
which a receiving node MAY indicate to the sender that it does not which a receiving node MAY indicate to the sender that it does not
want to receive the corresponding bundle. want to receive the corresponding bundle.
To do so, upon receiving a LENGTH or DATA_SEGMENT message, the node To do so, upon receiving a LENGTH or DATA_SEGMENT message, the node
MAY transmit a REFUSE_BUNDLE message. As data segments and MAY transmit a REFUSE_BUNDLE message. As data segments and
acknowledgments MAY cross on the wire, the bundle that is being acknowledgments MAY cross on the wire, the bundle that is being
refused SHALL be identified by the Transfer ID of the refusal. refused SHALL be identified by the Transfer ID of the refusal.
The format of the message is as follows: There is no required relation between the Transfer MRU of a TCPCL
endpoint (which is supposed to represent a firm limitation of what
the endpoint will accept) and sending of a REFUSE_BUNDLE message. A
REFUSE_BUNDLE can be used in cases where the agent's bundle storage
is temporarily depleted or somehow constrained. A REFUSE_BUNDLE can
also be used after the bundle header or any bundle data is inspected
by an agent and determined to be unacceptable.
+-----------------------------+ The format of the REFUSE_BUNDLE message is as follows:
| Message Header |
+-----------------------------+ +-----------------------------+
| Transfer ID (U64) | | Message Header |
+-----------------------------+ +-----------------------------+
| Transfer ID (U64) |
+-----------------------------+
Figure 11: Format of REFUSE_BUNDLE Messages Figure 11: Format of REFUSE_BUNDLE Messages
4 5 6 7 4 5 6 7
+-+-+-+-+ +-+-+-+-+
| RCode | | RCode |
+-+-+-+-+ +-+-+-+-+
Figure 12: Format of REFUSE_BUNDLE Header flags Figure 12: Format of REFUSE_BUNDLE Header flags
skipping to change at page 20, line 26 skipping to change at page 20, line 46
| Resources | | sender SHOULD apply reactive bundle | | Resources | | sender SHOULD apply reactive bundle |
| | | fragmentation before retrying. | | | | fragmentation before retrying. |
| | | | | | | |
| Retransmit | 0x3 | The receiver has encountered a problem that | | Retransmit | 0x3 | The receiver has encountered a problem that |
| | | requires the bundle to be retransmitted in | | | | requires the bundle to be retransmitted in |
| | | its entirety. | | | | its entirety. |
+------------+-------+----------------------------------------------+ +------------+-------+----------------------------------------------+
Table 4: REFUSE_BUNDLE Reason Codes Table 4: REFUSE_BUNDLE Reason Codes
The receiver MUST, for each bundle preceding the one to be refused, The receiver MUST, for each transfer preceding the one to be refused,
have either acknowledged all DATA_SEGMENTs or refused the bundle. have either acknowledged all DATA_SEGMENTs or refused the bundle
This allows the sender to identify the bundles accepted and refused transfer.
by means of a simple FIFO list of segments and acknowledgments.
The bundle refusal MAY be sent before the entire data segment is The bundle transfer refusal MAY be sent before an entire data segment
received. If a sender receives a REFUSE_BUNDLE message, the sender is received. If a sender receives a REFUSE_BUNDLE message, the
MUST complete the transmission of any partially sent DATA_SEGMENT sender MUST complete the transmission of any partially sent
message (so that the receiver stays in sync). The sender MUST NOT DATA_SEGMENT message. 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 bundle commence transmission of any further segments of the refused bundle
subsequently. Note, however, that this requirement does not ensure subsequently. Note, however, that this requirement does not ensure
that a node will not receive another DATA_SEGMENT for the same bundle that a node will not receive another DATA_SEGMENT for the same bundle
after transmitting a REFUSE_BUNDLE message since messages MAY cross after transmitting a REFUSE_BUNDLE message since messages MAY cross
on the wire; if this happens, subsequent segments of the bundle on the wire; if this happens, subsequent segments of the bundle
SHOULD also be refused with a REFUSE_BUNDLE message. SHOULD also be refused with a REFUSE_BUNDLE message.
Note: If a bundle transmission is aborted in this way, the receiver Note: If a bundle transmission is aborted in this way, the receiver
MAY not receive a segment with the 'E' flag set to '1' for the MAY not receive a segment with the 'E' flag set to '1' for the
aborted bundle. The beginning of the next bundle is identified by aborted bundle. The beginning of the next bundle is identified by
the 'S' bit set to '1', indicating the start of a new bundle. the 'S' bit set to '1', indicating the start of a new transfer, and
with a distinct Transfer ID value.
6. Session Termination 6. Session Termination
This section describes the procedures for ending a TCPCL session. This section describes the procedures for ending a TCPCL session.
6.1. Shutdown Message (SHUTDOWN) 6.1. Shutdown Message (SHUTDOWN)
To cleanly shut down a session, a SHUTDOWN message MUST be To cleanly shut down a session, a SHUTDOWN message MUST be
transmitted by either node at any point following complete transmitted by either node at any point following complete
transmission of any other message. A node SHOULD acknowledge all transmission of any other message. A receiving node SHOULD
received data segments before sending a SHUTDOWN message to end the acknowledge all received data segments before sending a SHUTDOWN
session. message to end the session. A transmitting node SHALL treat a
SHUTDOWN message received mid-transfer (i.e. before the final
acknowledgement) as a failure of the transfer.
The format of the SHUTDOWN message is as follows: The format of the SHUTDOWN message is as follows:
+-----------------------------------+ +-----------------------------------+
| Message Header | | Message Header |
+-----------------------------------+ +-----------------------------------+
| Reason Code (optional U8) | | Reason Code (optional U8) |
+-----------------------------------+ +-----------------------------------+
| Reconnection Delay (optional U16) | | Reconnection Delay (optional U16) |
+-----------------------------------+ +-----------------------------------+
skipping to change at page 22, line 31 skipping to change at page 22, line 37
| | | and cannot continue the session. | | | | and cannot continue the session. |
| | | | | | | |
| Resource | 0x05 | The node has run into some resoure limit | | Resource | 0x05 | The node has run into some resoure limit |
| Exhaustion | | and cannot continue the session. | | Exhaustion | | and cannot continue the session. |
+--------------+------+---------------------------------------------+ +--------------+------+---------------------------------------------+
Table 5: SHUTDOWN Reason Codes Table 5: SHUTDOWN Reason Codes
It is also possible to convey a requested reconnection delay to It is also possible to convey a requested reconnection delay to
indicate how long the other node MUST wait before attempting session indicate how long the other node MUST wait before attempting session
re-establishment. To do so, the node sets the 'D' bit in re-establishment. To do so, the node sets the 'D' bit in the message
header flags and then transmits an 16-bit unsigned integer specifying
the message header flags and then transmits an 16-bit unsigned the requested delay, in seconds, following the message header (and
integer specifying the requested delay, in seconds, following the optionally, the SHUTDOWN reason code). The value 0 SHALL be
message header (and optionally, the SHUTDOWN reason code). The value interpreted as an infinite delay, i.e., that the connecting node MUST
0 SHALL be interpreted as an infinite delay, i.e., that the NOT re-establish the session. In contrast, if the node does not wish
connecting node MUST NOT re-establish the session. In contrast, if to request a delay, it SHOULD omit the reconnection delay field (and
the node does not wish to request a delay, it SHOULD omit the set the 'D' bit to zero).
reconnection delay field (and set the 'D' bit to zero).
A session shutdown MAY occur immediately after TCP connection A session shutdown MAY occur immediately after TCP connection
establishment or reception of a contact header (and prior to any establishment or reception of a contact header (and prior to any
further data exchange). This MAY, for example, be used to notify further data exchange). This MAY, for example, be used to notify
that the node is currently not able or willing to communicate. that the node is currently not able or willing to communicate.
However, a node MUST always send the contact header to its peer However, a node MUST always send the contact header to its peer
before sending a SHUTDOWN message. before sending a SHUTDOWN message.
If either node terminates a session prematurely in this manner, it If either node terminates a session prematurely in this manner, it
SHOULD send a SHUTDOWN message and MUST indicate a reason code unless SHOULD send a SHUTDOWN message and MUST indicate a reason code unless
the incoming connection did not include the magic string. If a node the incoming connection did not include the magic string. If the
does not want its peer to reopen a connection immediately, it SHOULD magic string was not present, a node SHOULD close the TCP connection
set the 'D' bit in the flags and include a reconnection delay to without sending a SHUTDOWN message. If a node does not want its peer
indicate when the peer is allowed to attempt another session setup. to reopen a connection immediately, it SHOULD set the 'D' bit in the
flags and include a reconnection delay to indicate when the peer is
allowed to attempt another session setup.
If a session is to be terminated before another protocol message has If a session is to be terminated before another protocol message has
completed, then the node MUST NOT transmit the SHUTDOWN message but completed being sent, then the node MUST NOT transmit the SHUTDOWN
still SHOULD close the TCP connection. In particular, if the session message but still SHOULD close the TCP connection. This means that a
is to be closed (for whatever reason) while a node is in the process SHUTDOWN cannot be used to preempt any other TCPCL messaging in-
of transmitting a bundle data segment, the receiving node is still progress (particularly important when large segment sizes are being
expecting segment data and might erroneously interpret the SHUTDOWN transmitted).
message to be part of the data segment.
6.2. Idle Session Shutdown 6.2. Idle Session Shutdown
The protocol includes a provision for clean shutdown of idle The protocol includes a provision for clean shutdown of idle
sessions. Determining the length of time to wait before closing idle sessions. Determining the length of time to wait before closing idle
sessions, if they are to be closed at all, is an implementation and sessions, if they are to be closed at all, is an implementation and
configuration matter. configuration matter.
If there is a configured time to close idle links and if no bundle If there is a configured time to close idle links and if no bundle
data (other than KEEPALIVE messages) has been received for at least data (other than KEEPALIVE messages) has been received for at least
that amount of time, then either node MAY terminate the session by that amount of time, then either node MAY terminate the session by
transmitting a SHUTDOWN message indicating the reason code of 'Idle transmitting a SHUTDOWN message indicating the reason code of 'Idle
timeout' (as described in Table 4). After receiving a SHUTDOWN timeout' (as described in Table 5). After receiving a SHUTDOWN
message in response, both sides MAY close the TCP connection. message in response, both sides MAY close the TCP connection.
7. Security Considerations 7. Security Considerations
One security consideration for this protocol relates to the fact that One security consideration for this protocol relates to the fact that
nodes present their endpoint identifier as part of the session header nodes present their endpoint identifier as part of the contact header
exchange. It would be possible for a node to fake this value and exchange. It would be possible for a node to fake this value and
present the identity of a singleton endpoint in which the node is not present the identity of a singleton endpoint in which the node is not
a member, essentially masquerading as another DTN node. If this a member, essentially masquerading as another DTN node. If this
identifier is used outside of a TLS-secured session or without identifier is used outside of a TLS-secured session or without
further verification as a means to determine which bundles are further verification as a means to determine which bundles are
transmitted over the session, then the node that has falsified its transmitted over the session, then the node that has falsified its
identity MAY be able to obtain bundles that it SHOULD not have. identity would be able to obtain bundles that it otherwise would not
Therefore, a node SHALL NOT use the endpoint identifier conveyed in have. Therefore, a node SHALL NOT use the EID value of an unsecured
the TCPCL session message to derive a peer node's identity unless it contact header to derive a peer node's identity unless it can
can corroborate it via other means. corroborate it via other means. When TCPCL session security is
mandatory, an endpoint SHALL transmit initial unsecured contact
header values indicated in Table 6 in order. These values avoid
unnecessarily leaking endpoing parameters and will be ignored when
secure contact header re-exchange occurs.
These concerns MAY be mitigated through the use of the Bundle +--------------------+---------------------------------------------+
Security Protocol [RFC6257]. In particular, the Bundle | Parameter | Value |
Authentication Block defines mechanism for secure exchange of bundles +--------------------+---------------------------------------------+
between DTN nodes. Thus, an implementation could delay trusting the | Flags | The USE_TLS flag is set. |
presented endpoint identifier until the node can securely validate | | |
that its peer is in fact the only member of the given singleton | Keepalive Interval | Zero, indicating no keepalive. |
endpoint. | | |
| Segment MRU | Zero, indicating all segments are refused. |
| | |
| Transfer MRU | Zero, indicating all transfers are refused. |
| | |
| EID | Empty, indating lack of EID. |
+--------------------+---------------------------------------------+
Table 6: Recommended Unsecured Contact Header
TCPCL can be used to provide point-to-point transport security, but TCPCL can be used to provide point-to-point transport security, but
does not provide security of data-at-rest and does not guarantee end- does not provide security of data-at-rest and does not guarantee end-
to-end bundle security. The mechanisms defined in [RFC6257] and to-end bundle security. The mechanisms defined in [RFC6257] and
[I-D.ietf-dtn-bpsec] are to be used instead. [I-D.ietf-dtn-bpsec] are to be used instead.
Even when using TLS to secure the TCPCL session, the actual Even when using TLS to secure the TCPCL session, the actual
ciphersuite negotiated between the TLS peers MAY be insecure. TLS ciphersuite negotiated between the TLS peers MAY be insecure. TLS
can be used to perform authentication without data confidentiality, can be used to perform authentication without data confidentiality,
for example. It is up to security policies within each TCPCL node to for example. It is up to security policies within each TCPCL node to
skipping to change at page 26, line 22 skipping to change at page 26, line 29
| 0x2 | ACK_SEGMENT | | 0x2 | ACK_SEGMENT |
| | | | | |
| 0x3 | REFUSE_BUNDLE | | 0x3 | REFUSE_BUNDLE |
| | | | | |
| 0x4 | KEEPALIVE | | 0x4 | KEEPALIVE |
| | | | | |
| 0x5 | SHUTDOWN | | 0x5 | SHUTDOWN |
| | | | | |
| 0x6 | LENGTH | | 0x6 | LENGTH |
| | | | | |
| 0x7 | REJECT | | TBD | REJECT |
| | |
| 0x8 | STARTTLS |
| | | | | |
| 0x9--0xf | Unassigned | | TBD--0xf | Unassigned |
+----------+---------------+ +----------+---------------+
Message Type Codes Message Type Codes
8.4. REFUSE_BUNDLE Reason Codes 8.4. REFUSE_BUNDLE Reason Codes
IANA has created, under the "Bundle Protocol" registry, a sub- IANA has created, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer REFUSE_BUNDLE registry titled "Bundle Protocol TCP Convergence-Layer REFUSE_BUNDLE
Reason Codes" and initialized it with the contents of Table 3. The Reason Codes" and initialized it with the contents of Table 3. The
registration procedure is RFC Required. registration procedure is RFC Required.
skipping to change at page 27, line 30 skipping to change at page 27, line 30
REFUSE_BUNDLE Reason Codes REFUSE_BUNDLE Reason Codes
8.5. SHUTDOWN Reason Codes 8.5. SHUTDOWN Reason Codes
IANA has created, under the "Bundle Protocol" registry, a sub- IANA has created, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer SHUTDOWN registry titled "Bundle Protocol TCP Convergence-Layer SHUTDOWN
Reason Codes" and initialized it with the contents of Table 4. The Reason Codes" and initialized it with the contents of Table 4. The
registration procedure is RFC Required. registration procedure is RFC Required.
+------------+------------------+ +-----------+------------------+
| Code | Shutdown Reason | | Code | Shutdown Reason |
+------------+------------------+ +-----------+------------------+
| 0x00 | Idle timeout | | 0x00 | Idle timeout |
| | | | | |
| 0x01 | Version mismatch | | 0x01 | Version mismatch |
| | | | | |
| 0x02 | Busy | | 0x02 | Busy |
| | | | | |
| 0x03 | Contact Failure | | TBD | Contact Failure |
| | | | | |
| 0x04 | TLS failure | | TBD | TLS failure |
| | | | | |
| 0x05--0xFF | Unassigned | | TBD--0xFF | Unassigned |
+------------+------------------+ +-----------+------------------+
SHUTDOWN Reason Codes SHUTDOWN Reason Codes
8.6. REJECT Reason Codes 8.6. REJECT Reason Codes
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer REJECT Reason registry titled "Bundle Protocol TCP Convergence-Layer REJECT Reason
skipping to change at page 29, line 5 skipping to change at page 29, line 5
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol", Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol",
draft-ietf-dtn-bpbis-05 (work in progress), September draft-ietf-dtn-bpbis-06 (work in progress), October 2016.
2016.
[refs.IANA-BP] [refs.IANA-BP]
IANA, "Bundle Protocol registry", May 2016. IANA, "Bundle Protocol registry", May 2016.
10.2. Informative References 10.2. Informative References
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, DOI 10.17487/RFC2595, June 1999, RFC 2595, DOI 10.17487/RFC2595, June 1999,
<http://www.rfc-editor.org/info/rfc2595>. <http://www.rfc-editor.org/info/rfc2595>.
skipping to change at page 29, line 34 skipping to change at page 29, line 39
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257, "Bundle Security Protocol Specification", RFC 6257,
DOI 10.17487/RFC6257, May 2011, DOI 10.17487/RFC6257, May 2011,
<http://www.rfc-editor.org/info/rfc6257>. <http://www.rfc-editor.org/info/rfc6257>.
[RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant
Networking TCP Convergence-Layer Protocol", RFC 7242, Networking TCP Convergence-Layer Protocol", RFC 7242,
DOI 10.17487/RFC7242, June 2014, DOI 10.17487/RFC7242, June 2014,
<http://www.rfc-editor.org/info/rfc7242>. <http://www.rfc-editor.org/info/rfc7242>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[I-D.ietf-dtn-bpsec] [I-D.ietf-dtn-bpsec]
Birrane, E. and K. McKeever, "Bundle Protocol Security Birrane, E. and K. McKeever, "Bundle Protocol Security
Specification", draft-ietf-dtn-bpsec-02 (work in Specification", draft-ietf-dtn-bpsec-03 (work in
progress), July 2016. progress), October 2016.
Appendix A. Significant changes from RFC7242 Appendix A. Significant changes from RFC7242
The areas in which changes from [RFC7242] have been made to existing The areas in which changes from [RFC7242] have been made to existing
messages are: messages are:
o Changed contact header content to limit number of negotated o Changed contact header content to limit number of negotiated
options. options.
o Added contact option to negotiate maximum segment size (per each o Added contact option to negotiate maximum segment size (per each
direction). direction).
o Added a bundle transfer identification number to all bundle- o Added a bundle transfer identification number to all bundle-
related messages (LENGTH, DATA_SEGMENT, ACK_SEGMENT, related messages (LENGTH, DATA_SEGMENT, ACK_SEGMENT,
REFUSE_BUNDLE). REFUSE_BUNDLE).
o Use flags in ACK_SEGMENT to mirror flags from DATA_SEGMENT. o Use flags in ACK_SEGMENT to mirror flags from DATA_SEGMENT.
o Removed all uses of SDNV fields and replaced with fixed-bit-length o Removed all uses of SDNV fields and replaced with fixed-bit-length
fields. fields.
The areas in which extensions from [RFC7242] have been made as new The areas in which extensions from [RFC7242] have been made as new
messages and codes are: messages and codes are:
o Added contact negotation failure SHUTDOWN reason code.
o Added REJECT message to indicate an unknown or unhandled message o Added REJECT message to indicate an unknown or unhandled message
was received. was received.
o Added TLS session security mechanism. o Added TLS session security mechanism.
o Added TLS failure SHUTDOWN reason code. o Added TLS failure SHUTDOWN reason code.
Authors' Addresses Authors' Addresses
Brian Sipos Brian Sipos
 End of changes. 62 change blocks. 
166 lines changed or deleted 211 lines changed or added

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