draft-ietf-dtn-tcpclv4-04.txt   draft-ietf-dtn-tcpclv4-05.txt 
Delay Tolerant Networking B. Sipos Delay Tolerant Networking B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Obsoletes: 7242 (if approved) M. Demmer Obsoletes: 7242 (if approved) M. Demmer
Intended status: Standards Track UC Berkeley Intended status: Standards Track UC Berkeley
Expires: June 13, 2018 J. Ott Expires: June 17, 2018 J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
December 10, 2017 December 14, 2017
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-04 draft-ietf-dtn-tcpclv4-05
Abstract Abstract
This document describes a revised protocol for the TCP-based This document describes a revised protocol for the TCP-based
convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The
protocol revision is based on implementation issues in the original protocol revision is based on implementation issues in the original
TCPCL Version 3 and updates to the Bundle Protocol contents, TCPCL Version 3 and updates to the Bundle Protocol contents,
encodings, and convergence layer requirements in Bundle Protocol encodings, and convergence layer requirements in Bundle Protocol
Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles
as its service data unit being transported and provides a reliable as its service data unit being transported and provides a reliable
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 June 13, 2018. This Internet-Draft will expire on June 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 4 2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 4
3. General Protocol Description . . . . . . . . . . . . . . . . 5 3. General Protocol Description . . . . . . . . . . . . . . . . 6
3.1. TCPCL Session Overview . . . . . . . . . . . . . . . . . 6 3.1. TCPCL Session Overview . . . . . . . . . . . . . . . . . 6
3.2. Example Message Exchange . . . . . . . . . . . . . . . . 7 3.2. Example Message Exchange . . . . . . . . . . . . . . . . 7
4. Session Establishment . . . . . . . . . . . . . . . . . . . . 8 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 9
4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 10 4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Header Extension Items . . . . . . . . . . . . . . . 12 4.1.1. Header Extension Items . . . . . . . . . . . . . . . 12
4.2. Validation and Parameter Negotiation . . . . . . . . . . 13 4.2. Validation and Parameter Negotiation . . . . . . . . . . 13
4.3. Session Security . . . . . . . . . . . . . . . . . . . . 14 4.3. Session Security . . . . . . . . . . . . . . . . . . . . 15
4.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 15 4.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 15
4.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 15 4.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 15
5. Established Session Operation . . . . . . . . . . . . . . . . 16 5. Established Session Operation . . . . . . . . . . . . . . . . 16
5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 16 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 16
5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 17 5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 17
5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 17 5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 17
5.2.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 18 5.2.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 18
5.3. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 19 5.3. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 19
5.3.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 19 5.3.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 19
5.3.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 20 5.3.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 20
skipping to change at page 5, line 35 skipping to change at page 5, line 35
and thereby to the TCPCL is implementation dependent. However, and thereby to the TCPCL is implementation dependent. However,
the mechanism by which two bundle nodes exchange and negotiate the the mechanism by which two bundle nodes exchange and negotiate the
values to be used for a given session is described in Section 4.2. values to be used for a given session is described in Section 4.2.
Transfer: Transfer refers to the procedures and mechanisms Transfer: Transfer refers to the procedures and mechanisms
(described below) for conveyance of an individual bundle from one (described below) for conveyance of an individual bundle from one
node to another. Each transfer within TCPCLv4 is identified by a node to another. Each transfer within TCPCLv4 is identified by a
Transfer ID number which is unique only to a single direction Transfer ID number which is unique only to a single direction
within a single Session. within a single Session.
Idle Session: A TCPCL session is idle while the only messages being
transmitted or received are KEEPALIVE messages.
Lively Session: A TCPCL session is lively while any messages are
being transmitted or received.
Reason Codes: The TCPCL uses numeric codes to encode specific Reason Codes: The TCPCL uses numeric codes to encode specific
reasons for individual failure/error message types. This limits reasons for individual failure/error message types. This limits
the expressiveness of TCPCL error encodings, but simplifies the the expressiveness of TCPCL error encodings, but simplifies the
encoding of errors and allows an application policy to attempt encoding of errors and allows an application policy to attempt
recovery from expected 'failure' modes (e.g. if a Session cannot recovery from expected 'failure' modes (e.g. if a Session cannot
be established with USE_TLS disabled because of a Contact Failure be established with USE_TLS disabled because of a Contact Failure
shutdown, a re-attempt can be made with USE_TLS enabled). shutdown, a re-attempt can be made with USE_TLS enabled).
3. General Protocol Description 3. General Protocol Description
skipping to change at page 7, line 8 skipping to change at page 7, line 17
Another feature is that a receiver MAY interrupt the transmission of Another feature is that a receiver MAY interrupt the transmission of
a bundle at any point in time by replying with a XFER_REFUSE message, a bundle at any point in time by replying with a XFER_REFUSE message,
which causes the sender to stop transmission of the current bundle, which causes the sender to stop transmission of the current bundle,
after completing transmission of a partially sent data segment. after completing transmission of a partially sent data segment.
Note: This enables a cross-layer optimization in that it allows a Note: This enables a cross-layer optimization in that it allows a
receiver that detects that it already has received a certain bundle receiver that detects that it already has received a certain bundle
to interrupt transmission as early as possible and thus save to interrupt transmission as early as possible and thus save
transmission capacity for other bundles. transmission capacity for other bundles.
For sessions that are idle, a KEEPALIVE message is sent at a For sessions that are idle, a KEEPALIVE message is sent at a
negotiated interval. This is used to convey node liveness negotiated interval. This is used to convey node liveliqness
information. information during otherwise message-less time intervals.
Finally, before sessions close, a SHUTDOWN message is sent to the Finally, before sessions close, a SHUTDOWN message is sent to the
session peer. A SHUTDOWN message MAY also be used to refuse a session peer (see Section 6.1). After sending a SHUTDOWN message,
session setup by a peer (see Section 4.2). After sending a SHUTDOWN the peer can not initiate any further transfers and the session
message, the sender of the message MAY send further acknowledgments enters a closing-down phase. After receiving a SHUTDOWN message and
(XFER_ACK or XFER_REFUSE) but no further data messages (XFER_INIT or when no transfers are in-progress (i.e. have pending or
XFER_SEGMENT). After receving a SHUTDOWN message and when no unacknowledged segments), the receiving peer can close the session
transfers are in-progress (i.e. have unacknowledged segemnts) without chance of lost transfers. A SHUTDOWN message can also be
used to refuse a session setup by a peer (see Section 4.2). It is an
implementation matter to determine whether or not to close a TCPCL
session while there are no transfers queued or in-progress.
There are specific messages for sending and receiving operations (in There are specific messages for sending and receiving operations (in
addition to session setup/teardown). TCPCL is symmetric, i.e., both addition to session setup/teardown). TCPCL is symmetric, i.e., both
sides can start sending data segments in a session, and one side's sides can start sending data segments in a session, and one side's
bundle transfer does not have to complete before the other side can bundle transfer does not have to complete before the other side can
start sending data segments on its own. Hence, the protocol allows start sending data segments on its own. Hence, the protocol allows
for a bi-directional mode of communication. Note that in the case of for a bi-directional mode of communication. Note that in the case of
concurrent bidirectional transmission, acknowledgment segments MAY be concurrent bidirectional transmission, acknowledgment segments MAY be
interleaved with data segments. interleaved with data segments.
skipping to change at page 11, line 5 skipping to change at page 11, line 8
magic: A four-octet field that always contains the octet sequence magic: A four-octet field that always contains the octet sequence
0x64 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII (and 0x64 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII (and
UTF-8). UTF-8).
Version: A one-octet field value containing the value 4 (current Version: A one-octet field value containing the value 4 (current
version of the protocol). version of the protocol).
Flags: A one-octet field of single-bit flags, interpreted according Flags: A one-octet field of single-bit flags, interpreted according
to the descriptions in Table 1. to the descriptions in Table 1.
Keepalive Interval: A 16-bit unsigned integer indicating the longest Keepalive Interval: A 16-bit unsigned integer indicating the
allowable interval, in seconds, between any message being received interval, in seconds, between any subsequent messages being
in this session and a subsequent KEEPALIVE message being received. transmitted by the peer. The peer receiving this contact header
uses this interval to determine how long to wait after any last-
message transmission and a necessary subsequent KEEPALIVE message
transmission.
Segment MRU: A 64-bit unsigned integer indicating the largest Segment MRU: A 64-bit unsigned integer indicating the largest
allowable single-segment data payload size to be received in this allowable single-segment data payload size to be received in this
session. Any XFER_SEGMENT sent to this peer SHALL have a data session. Any XFER_SEGMENT sent to this peer SHALL have a data
payload no longer than the peer's Segment MRU. The two nodes of a payload no longer than the peer's Segment MRU. The two nodes of a
single session MAY have different Segment MRUs, and no relation single session MAY have different Segment MRUs, and no relation
between the two is required. between the two is required.
Transfer MRU: A 64-bit unsigned integer indicating the largest Transfer MRU: A 64-bit unsigned integer indicating the largest
allowable total-bundle data size to be received in this session. allowable total-bundle data size to be received in this session.
skipping to change at page 12, line 16 skipping to change at page 12, line 27
Each of the Header Extension items SHALL be encoded in an identical Each of the Header Extension items SHALL be encoded in an identical
Type-Length-Value (TLV) container form as indicated in Figure 4. The Type-Length-Value (TLV) container form as indicated in Figure 4. The
fields of the header extension item are: fields of the header extension item are:
Flags: A one-octet field containing generic bit flags about the Flags: A one-octet field containing generic bit flags about the
item, which are listed in Table 2. If a TCPCL node receives an item, which are listed in Table 2. If a TCPCL node receives an
extension item with an unknown Item Type and the CRITICAL flag extension item with an unknown Item Type and the CRITICAL flag
set, the node SHALL close the TCPCL session with SHUTDOWN reason set, the node SHALL close the TCPCL session with SHUTDOWN reason
code of "Contact Failure". If the CRITICAL flag is not set, an code of "Contact Failure". If the CRITICAL flag is not set, an
node SHALL skip over and ignore any item with an unkonwn Item node SHALL skip over and ignore any item with an unknown Item
Type. Type.
Item Type: A 16-bit unsigned integer field containing the type of Item Type: A 16-bit unsigned integer field containing the type of
the extension item. This specification does not define any the extension item. This specification does not define any
extension types directly, but does allocate an IANA registry for extension types directly, but does allocate an IANA registry for
such codes (see Section 8.3). such codes (see Section 8.3).
Item Length: A 32-bit unsigned integer field containing the number Item Length: A 32-bit unsigned integer field containing the number
of Item Value octets to follow. of Item Value octets to follow.
skipping to change at page 13, line 51 skipping to change at page 14, line 14
a version that is lower than the version of the protocol that the a version that is lower than the version of the protocol that the
node implements, the node MAY either terminate the session (with a node implements, the node MAY either terminate the session (with a
reason code of "Version mismatch"). Otherwise, the node MAY adapt reason code of "Version mismatch"). Otherwise, the node MAY adapt
its operation to conform to the older version of the protocol. The its operation to conform to the older version of the protocol. The
decision of version fall-back is an implementation matter. decision of version fall-back is an implementation matter.
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 negotiated parameters defined by this specification are described in
in the following paragraphs. 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 Keepalive 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. There is no logical minimum value for the keepalive is disabled. There is no logical minimum value for the keepalive
interval, but when used for many sessions on an open, shared interval, but when used for many sessions on an open, shared
network a short interval could lead to excessive traffic. For network a short interval could lead to excessive traffic. For
shared network use, nodes SHOULD choose a keepalive interval no shared network use, nodes SHOULD choose a keepalive interval no
skipping to change at page 14, line 35 skipping to change at page 14, line 47
MAY forbid the establishment of a TCPCL session for any Enable TLS MAY forbid the establishment of a TCPCL session for any Enable TLS
result (or for any combination of local or peer CAN_TLS flag), in result (or for any combination of local or peer CAN_TLS flag), in
which case the node SHALL shutdown the session with a reason code which case the node SHALL shutdown the session with a reason code
of "Contact Failure". For example, one node may disallow TCPCL of "Contact Failure". For example, one node may disallow TCPCL
sessions without TLS, while a second node may disallow sessions sessions without TLS, while a second node may disallow sessions
with TLS. Also note that this Contact Failure (of the header with TLS. Also note that this Contact Failure (of the header
negotiation) is different than a TLS Failure (after an agreed-upon negotiation) is different than a TLS Failure (after an agreed-upon
Enable TLS state). Enable TLS state).
Once this process of parameter negotiation is completed (which Once this process of parameter negotiation is completed (which
includes a possible completed TLS handshakede of the connection to includes a possible completed TLS handshake of the connection to use
use TLS), this protocol defines no additional mechanism to change the TLS), this protocol defines no additional mechanism to change the
parameters of an established session; to effect such a change, the parameters of an established session; to effect such a change, the
TCPCL session MUST be terminated and a new session established. TCPCL session MUST be terminated and a new session established.
4.3. Session Security 4.3. Session Security
This version of the TCPCL supports establishing a Transport Layer This version of the TCPCL supports establishing a Transport Layer
Security (TLS) session within an existing TCP connection. Negotation Security (TLS) session within an existing TCP connection.
of whether or not to initiate TLS within a TCPCL session is part of Negotiation of whether or not to initiate TLS within a TCPCL session
the contact header as described in Section 4.2. The TLS handshake, is part of the contact header as described in Section 4.2. The TLS
if it occurs, is considered to be part of the contact negotiation handshake, if it occurs, is considered to be part of the contact
before the TCPCL session itself is established. Specifics about negotiation before the TCPCL session itself is established.
sensitive data exposure are discussed in Section 7. Specifics about sensitive data exposure are discussed in Section 7.
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 node which initiated the convention, this protocol uses the node 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 nodes other TCPCL messages are sent within the session, the session nodes
SHALL begin a TLS handshake in accordance with [RFC5246]. The SHALL begin a TLS handshake in accordance with [RFC5246]. The
parameters within each TLS negotation are implementation dependent parameters within each TLS nqion are implementation dependent but any
but any TCPCL node SHOULD follow all recommended best practices of TCPCL node SHOULD follow all recommended best practices of [RFC7525].
[RFC7525].
4.3.1. TLS Handshake Result 4.3.1. TLS Handshake Result
If a TLS handshake cannot negotiate a TLS session, both nodes of the If a TLS handshake cannot negotiate a TLS session, both nodes of the
TCPCL session SHALL cause a TCPCL shutdown with reason "TLS Failure". TCPCL session SHALL cause a TCPCL shutdown with reason "TLS Failure".
After a TLS session is successfuly established, both TCPCL nodes After a TLS session is successfully established, both TCPCL nodes
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 fashion This re-exchange avoids man-in-the-middle attack in identical fashion
to [RFC2595]. Each re-exchange header CAN_TLS flag SHALL be to [RFC2595]. Each re-exchange header CAN_TLS flag SHALL be
identical to the original header CAN_TLS flag from the same node. identical to the original header CAN_TLS flag from the same node.
The CAN_TLS logic (TLS negotiation) SHALL NOT apply during header re- The CAN_TLS logic (TLS negotiation) SHALL NOT apply during header re-
exchange. This reinforces the fact that there is no TLS downgrade exchange. This reinforces the fact that there is no TLS downgrade
mechanism. mechanism.
4.3.2. Example TLS Initiation 4.3.2. Example TLS Initiation
skipping to change at page 18, line 19 skipping to change at page 18, line 19
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 3) with no additional data. Both KEEPALIVE (as described in Table 3) 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
Section 6.1, with reason code "Idle Timeout") and by closing the Section 6.1) with reason code "Idle Timeout", and by closing the
session. 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 (MSG_REJECT) 5.2.2. Message Rejection (MSG_REJECT)
If a TCPCL node receives a message which is unknown to it (possibly If a TCPCL node receives a message which is unknown to it (possibly
due to an unhandled protocol mismatch) or is inappropriate for the due to an unhandled protocol mismatch) or is inappropriate for the
current session state (e.g. a KEEPALIVE message received after current session state (e.g. a KEEPALIVE message received after
contact header negotation has disabled that feature), there is a contact header negotiation has disabled that feature), there is a
protocol-level message to signal this condition in the form of a protocol-level message to signal this condition in the form of a
MSG_REJECT reply. MSG_REJECT reply.
The format of a MSG_REJECT message follows: The format of a MSG_REJECT message follows:
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Reason Code (U8) | | Reason Code (U8) |
+-----------------------------+ +-----------------------------+
skipping to change at page 19, line 29 skipping to change at page 19, line 29
| Message | 0x03 | A message was received while the session is | | Message | 0x03 | A message was received while the session is |
| Unexpected | | in a state in which the message is not | | Unexpected | | in a state in which the message is not |
| | | expected. | | | | expected. |
+-------------+------+----------------------------------------------+ +-------------+------+----------------------------------------------+
Table 4: MSG_REJECT Reason Codes Table 4: MSG_REJECT Reason Codes
5.3. Bundle Transfer 5.3. Bundle Transfer
All of the message in this section are directly associated with All of the message in this section are directly associated with
transfering a bundle between TCPCL nodes. transferring a bundle between TCPCL nodes.
A single TCPCL transfer results in a bundle (handled by the A single TCPCL transfer results in a bundle (handled by the
convergence layer as opaque data) being exchanged from one node to convergence layer as opaque data) being exchanged from one node to
the other. In TCPCL a transfer is accomplished by dividing a single the other. In TCPCL a transfer is accomplished by dividing a single
bundle up into "segments" based on the receiving-side Segment MRU bundle up into "segments" based on the receiving-side Segment MRU
(see Section 4.1). (see Section 4.1).
A single transfer (and by extension a single segment) SHALL NOT A single transfer (and by extension a single segment) SHALL NOT
contain data of more than a single bundle. This requirement is contain data of more than a single bundle. This requirement is
imposed on the agent using the TCPCL rather than TCPCL itself. imposed on the agent using the TCPCL rather than TCPCL itself.
skipping to change at page 25, line 35 skipping to change at page 25, line 35
and with a distinct Transfer ID value. 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 receiving node SHOULD transmission of any other message. After sending a SHUTDOWN message,
acknowledge all received data segments before sending a SHUTDOWN the sender of the message MAY send further acknowledgments (XFER_ACK
message to end the session. A transmitting node SHALL treat a or XFER_REFUSE) but no further data messages (XFER_INIT or
SHUTDOWN message received mid-transfer (i.e. before the final XFER_SEGMENT). A receiving node SHOULD acknowledge all received data
acknowledgement) as a failure of the transfer. segments before sending a SHUTDOWN message to end the session. A
transmitting node SHALL treat a SHUTDOWN message received mid-
transfer (i.e. before the final acknowledgment) as a failure of the
transfer.
After transmitting a SHUTDOWN message, an node MAY immediately close After transmitting a SHUTDOWN message, an node MAY immediately close
the associated TCP connection. Once the SHUTDOWN message is sent, the associated TCP connection. Once the SHUTDOWN message is sent,
any further received data on the TCP connection SHOULD be ignored. any further received data on the TCP connection SHOULD be ignored.
Any delay between request to terminate the TCP connection and actual Any delay between request to terminate the TCP connection and actual
closing of the connection (a "half-closed" state) MAY be ignored by closing of the connection (a "half-closed" state) MAY be ignored by
the TCPCL node. the TCPCL node.
The format of the SHUTDOWN message is as follows: The format of the SHUTDOWN message is as follows:
skipping to change at page 27, line 22 skipping to change at page 27, line 22
| | | | | |
| Busy | The node is too busy to handle the current | | Busy | The node is too busy to handle the current |
| | session. | | | session. |
| | | | | |
| Contact | The node cannot interpret or negotiate contact | | Contact | The node cannot interpret or negotiate contact |
| Failure | header option. | | Failure | header option. |
| | | | | |
| TLS Failure | The node failed to negotiate TLS session and | | TLS Failure | The node failed to negotiate TLS session and |
| | cannot continue the session. | | | cannot continue the session. |
| | | | | |
| Resource | The node has run into some resoure limit and | | Resource | The node has run into some resource limit and |
| Exhaustion | cannot continue the session. | | Exhaustion | cannot continue the session. |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
Table 8: SHUTDOWN Reason Codes Table 8: 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 the message re-establishment. To do so, the node sets the 'D' bit in the message
flags and then transmits an 16-bit unsigned integer specifying the flags and then transmits an 16-bit unsigned integer specifying the
requested delay, in seconds, following the message header (and requested delay, in seconds, following the message header (and
skipping to change at page 28, line 14 skipping to change at page 28, line 14
flags and include a reconnection delay to indicate when the peer is flags and include a reconnection delay to indicate when the peer is
allowed to attempt another session setup. allowed to attempt another session setup.
If a session is to be terminated before a protocol message has If a session is to be terminated before a protocol message has
completed being sent, then the node MUST NOT transmit the SHUTDOWN completed being sent, then the node MUST NOT transmit the SHUTDOWN
message but still SHOULD close the TCP connection. Each TCPCL message but still SHOULD close the TCP connection. Each TCPCL
message is contiguous in the octet stream and has no ability to be message is contiguous in the octet stream and has no ability to be
cut short and/or preempted by an other message. This is particularly cut short and/or preempted by an other message. This is particularly
important when large segment sizes are being transmitted; either important when large segment sizes are being transmitted; either
entire XFER_SEGMENT is sent before a SHUTDOWN message or the entire XFER_SEGMENT is sent before a SHUTDOWN message or the
connection is simply termiated mid-XFER_SEGMENT. connection is simply terminated mid-XFER_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 TCPCL
data (other than KEEPALIVE messages) has been received for at least messages (other than KEEPALIVE messages) has been received for at
that amount of time, then either node MAY terminate the session by least that amount of time, then either node MAY terminate the session
transmitting a SHUTDOWN message indicating the reason code of 'Idle by transmitting a SHUTDOWN message indicating the reason code of
timeout' (as described in Table 8). 'Idle timeout' (as described in Table 8).
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 contact 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 would be able to obtain bundles that it otherwise would not identity would be able to obtain bundles that it otherwise would not
have. Therefore, a node SHALL NOT use the EID value of an unsecured have. Therefore, a node SHALL NOT use the EID value of an unsecured
contact header to derive a peer node's identity unless it can contact header to derive a peer node's identity unless it can
corroborate it via other means. When TCPCL session security is corroborate it via other means. When TCPCL session security mandated
mandatory, an endpoint SHALL transmit initial unsecured contact by a TCPCL peer, that peer SHALL transmit initial unsecured contact
header values indicated in Table 9 in order. These values avoid header values indicated in Table 9 in order. These values avoid
unnecessarily leaking endpoing parameters and will be ignored when unnecessarily leaking endpoing parameters and will be ignored when
secure contact header re-exchange occurs. secure contact header re-exchange occurs.
+--------------------+---------------------------------------------+ +--------------------+---------------------------------------------+
| Parameter | Value | | Parameter | Value |
+--------------------+---------------------------------------------+ +--------------------+---------------------------------------------+
| Flags | The USE_TLS flag is set. | | Flags | The USE_TLS flag is set. |
| | | | | |
| Keepalive Interval | Zero, indicating no keepalive. | | Keepalive Interval | Zero, indicating no keepalive. |
| | | | | |
| Segment MRU | Zero, indicating all segments are refused. | | Segment MRU | Zero, indicating all segments are refused. |
| | | | | |
| Transfer MRU | Zero, indicating all transfers are refused. | | Transfer MRU | Zero, indicating all transfers are refused. |
| | | | | |
| EID | Empty, indating lack of EID. | | EID | Empty, indicating lack of EID. |
+--------------------+---------------------------------------------+ +--------------------+---------------------------------------------+
Table 9: Recommended Unsecured Contact Header Table 9: 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
skipping to change at page 36, line 40 skipping to change at page 36, line 40
related messages (XFER_INIT, XFER_SEGMENT, XFER_ACK, XFER_REFUSE). related messages (XFER_INIT, XFER_SEGMENT, XFER_ACK, XFER_REFUSE).
o Use flags in XFER_ACK to mirror flags from XFER_SEGMENT. o Use flags in XFER_ACK to mirror flags from XFER_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 contact negotiation failure SHUTDOWN reason code.
o Added MSG_REJECT message to indicate an unknown or unhandled o Added MSG_REJECT message to indicate an unknown or unhandled
message was received. message 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
 End of changes. 27 change blocks. 
52 lines changed or deleted 66 lines changed or added

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