--- 1/draft-ietf-dtn-tcpclv4-13.txt 2019-09-19 11:13:38.063021447 -0700 +++ 2/draft-ietf-dtn-tcpclv4-14.txt 2019-09-19 11:13:38.183024469 -0700 @@ -1,22 +1,22 @@ Delay Tolerant Networking B. Sipos Internet-Draft RKF Engineering Obsoletes: 7242 (if approved) M. Demmer Intended status: Standards Track UC Berkeley -Expires: February 21, 2020 J. Ott +Expires: March 22, 2020 J. Ott Aalto University S. Perreault - August 20, 2019 + September 19, 2019 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 - draft-ietf-dtn-tcpclv4-13 + draft-ietf-dtn-tcpclv4-14 Abstract This document describes a revised protocol for the TCP-based convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The protocol revision is based on implementation issues in the original TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol contents, encodings, and convergence layer requirements in Bundle Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides a @@ -32,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 21, 2020. + This Internet-Draft will expire on March 22, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -94,29 +94,29 @@ 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 43 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 45 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 45 8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 47 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 48 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 48 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 49 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 50 - 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 50 - 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 51 - 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 52 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 53 - 11.2. Informative References . . . . . . . . . . . . . . . . . 54 - Appendix A. Significant changes from RFC7242 . . . . . . . . . . 55 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 + 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 51 + 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 52 + 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 53 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 54 + 11.2. Informative References . . . . . . . . . . . . . . . . . 55 + Appendix A. Significant changes from RFC7242 . . . . . . . . . . 56 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 1. Introduction This document describes the TCP-based convergence-layer protocol for Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- end architecture providing communications in and/or through highly stressed environments, including those with intermittent connectivity, long and/or variable delays, and high bit error rates. More detailed descriptions of the rationale and capabilities of these networks can be found in "Delay-Tolerant Network Architecture" @@ -236,21 +236,21 @@ sessions, and other states association with that TCP connection. TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a TCPCL communication relationship between two TCPCL entities. Within a single TCPCL session there are two possible transfer streams; one in each direction, with one stream from each entity being the outbound stream and the other being the inbound stream. The lifetime of a TCPCL session is bound to the lifetime of an underlying TCP connection. A TCPCL session is terminated when the TCP connection ends, due either to one or both entities actively - terminating the TCP connection or due to network errors causing a + closing the TCP connection or due to network errors causing a failure of the TCP connection. For the remainder of this document, the term "session" without the prefix "TCPCL" refers to a TCPCL session. Session parameters: These are a set of values used to affect the operation of the TCPCL for a given session. The manner in which these parameters are conveyed to the bundle entity and thereby to the TCPCL is implementation dependent. However, the mechanism by which two entities exchange and negotiate the values to be used for a given session is described in Section 4.3. @@ -412,21 +412,21 @@ transferred segment. Transmission Failure: The TCPCL supports positive indication of certain reasons for bundle transmission failure, notably when the peer entity rejects the bundle or when a TCPCL session ends before transferr success. The TCPCL itself does not have a notion of transfer timeout. Reception Initialized: The TCPCL supports indication to the reciver just before any transmssion data is sent. This corresponds to - reception of the XFER_SEGMENT message with the START flag set. + reception of the XFER_SEGMENT message with the START flag of 1. Interrupt Reception: The TCPCL allows a BP agent to interrupt an individual transfer before it has fully completed (successfully or not). Interruption can occur any time after the reception is initialized. Reception Success: The TCPCL supports positive indication when a bundle has been fully transferred from a peer entity. Reception Intermediate Progress: The TCPCL supports positive @@ -494,23 +494,27 @@ bundles. For sessions that are idle, a KEEPALIVE message is sent at a negotiated interval. This is used to convey node live-ness information during otherwise message-less time intervals. A SESS_TERM message is used to start the ending of a TCPCL session (see Section 6.1). During shutdown sequencing, in-progress transfers can be completed but no new transfers can be initiated. A SESS_TERM message can also be used to refuse a session setup by a peer (see - Section 4.3). It is an implementation matter to determine whether or - not to close a TCPCL session while there are no transfers queued or - in-progress. + Section 4.3). Regardless of the reason, session termination is + initiated by one of the entities and responded-to by the other as + illustrated by Figure 13 and Figure 14. Even when there are no + transfers queued or in-progress, the session termination procedure + allows each entity to distinguish between a clean end to a session + and the TCP connection being closed because of some underlying + network issue. Once a session is established, TCPCL is a symmetric protocol between the peers. Both 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 start sending data segments on its own. Hence, the protocol allows for a bi-directional mode of communication. Note that in the case of concurrent bidirectional transmission, acknowledgment segments MAY be interleaved with data segments. 3.3. TCPCL States and Transitions @@ -938,21 +942,21 @@ magic: A four-octet field that always contains the octet sequence 0x64 0x74 0x6E 0x21, i.e., the text string "dtn!" in US-ASCII (and UTF-8). Version: A one-octet field value containing the value 4 (current version of the TCPCL). Flags: A one-octet field of single-bit flags, interpreted according to the descriptions in Table 1. All reserved header flag bits - SHALL be not set by the sender. All reserved header flag bits + SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver. +----------+--------+-----------------------------------------------+ | Name | Code | Description | +----------+--------+-----------------------------------------------+ | CAN_TLS | 0x01 | If bit is set, indicates that the sending | | | | peer is capable of TLS security. | | | | | | Reserved | others | +----------+--------+-----------------------------------------------+ @@ -978,21 +982,21 @@ response from the passive node. The active node can repeatedly attempt different protocol versions in descending order until the passive node accepts one with a corresponding Contact Header reply. Only upon response of a Contact Header from the passive node is the TCPCL protocol version established and parameter negotiation begun. During contact initiation, the active TCPCL node SHALL send the highest TCPCL protocol version on a first session attempt for a TCPCL peer. If the active node receives a Contact Header with a different protocol version than the one sent earlier on the TCP connection, the - TCP connection SHALL be terminated. If the active node receives a + TCP connection SHALL be closed. If the active node receives a SESS_TERM message with reason of "Version Mismatch", that node MAY attempt further TCPCL sessions with the peer using earlier protocol version numbers in decreasing order. Managing multi-TCPCL-session state such as this is an implementation matter. If the passive node receives a contact header containing a version that is greater than the current version of the TCPCL that the node implements, then the node SHALL shutdown the session with a reason code of "Version mismatch". If the passive node receives a contact header with a version that is lower than the version of the protocol @@ -1022,31 +1026,35 @@ underlying TCP connection as the "client" role of the TLS handshake request. The TLS handshake, if it occurs, is considered to be part of the contact negotiation before the TCPCL session itself is established. Specifics about sensitive data exposure are discussed in Section 8. The parameters within each TLS negotiation are implementation dependent but any TCPCL node SHALL follow all recommended practices of BCP 195 [RFC7525], or any updates or successors that become part - of BCP 195. The TLS handshake SHOULD include a Server Name - Indication from the active peer. The TLS handshake SHALL request a - client-side certificate to allow authentication of the active peer. - The passive peer SHOULD supply a certificate within the TLS handshake - to allow authentication of its side of the session. The active peer - SHOULD supply a certificate within the TLS handshake to allow - authentication of its side of the session. All certificates supplied - during TLS handshake SHALL conform with the profile of [RFC5280]. - When a certificate is supplied during TLS handshake, the full - certification chain SHOULD be included unless security policy - indicates that is unnecessary. + of BCP 195. When possible, the TLS handshake SHOULD include a Server + Name Indication (SNI) from the active peer in accordance with + [RFC6066]. The SNI SHALL contain the same host name used to + establish the TCP connection. The passive peer MAY use the SNI host + name to choose an appropriate server-side certificate. The TLS + handshake SHALL request a client-side certificate to allow + authentication of the active peer. The passive peer SHOULD supply a + certificate within the TLS handshake to allow authentication of its + side of the session. The active peer SHOULD supply a certificate + within the TLS handshake to allow authentication of its side of the + session. All certificates supplied during TLS handshake SHALL + conform with the profile of [RFC5280], or any updates or successors + to that profile. When a certificate is supplied during TLS + handshake, the full certification chain SHOULD be included unless + security policy indicates that is unnecessary. If a TLS handshake cannot negotiate a TLS session, both entities of the TCPCL session SHALL close the TCP connection. At this point the TCPCL session has not yet been established so there is no TCPCL session to terminate. This also avoids any potential security issues assoicated with further TCP communication with an untrusted peer. After a TLS session is successfully established, the active peer SHALL send a SESS_INIT message to begin session negotiation. This session negotation and all subsequent messaging are secured. @@ -1082,29 +1090,32 @@ validation fails (including failure because the certificate does not contain any DNS-ID), the entity SHOULD terminate the session (with a reason code of "Contact Failure") unless security policy allows an unauthticated host. Immediately before Session Parameter Negotiation, each side of the session SHALL perform Node ID validation of its peer as described below. Node ID validation SHALL succeed if the associated certificate contains a subjectAltName entry of type uniformResourceIdentifier whose value matches the Node ID of the - TCPCL entity. URI matching of Node IDs SHALL use the URI comparison - logic of [RFC3986] and scheme-based normalization of those schemes - specified in [I-D.ietf-dtn-bpbis]. This is similar to the URI-ID of - - [RFC6125] but does not require any structure to the scheme-specific- - part of the URI. If Node ID validation fails (including failure - because the certificate does not contain any subjectAltName URI), the - entity SHOULD terminate the session (with a reason code of "Contact - Failure") unless security policy allows an unauthticated node. + TCPCL entity. Unless specified otherwise by the definition of the + URI scheme being authenticated, URI matching of Node IDs SHALL use + the URI comparison logic of [RFC3986] and scheme-based normalization + of those schemes specified in [I-D.ietf-dtn-bpbis]. This is similar + to the URI-ID of [RFC6125] but does not require any structure to the + scheme-specific-part of the URI. A URI scheme can refine this "exact + match" logic with rules about how Node IDs within that scheme are to + be compared with the certificate-authenticated URI. If Node ID + validation fails (including failure because the certificate does not + contain any subjectAltName URI), the entity SHOULD terminate the + session (with a reason code of "Contact Failure") unless security + policy allows an unauthticated node. 4.4.3. Example TLS Initiation A summary of a typical TLS use is shown in the sequence in Figure 17 below. Entity A Entity B active peer passive peer +-------------------------+ @@ -1202,23 +1213,23 @@ +-----------------------------+ | Message Header | +-----------------------------+ | Keepalive Interval (U16) | +-----------------------------+ | Segment MRU (U64) | +-----------------------------+ | Transfer MRU (U64) | +-----------------------------+ - | EID Length (U16) | + | Node ID Length (U16) | +-----------------------------+ - | EID Data (variable) | + | Node ID Data (variable) | +-----------------------------+ | Session Extension | | Items Length (U32) | +-----------------------------+ | Session Extension | | Items (var.) | +-----------------------------+ Figure 19: SESS_INIT Format @@ -1316,27 +1327,27 @@ 4.8. Session Extension Items Each of the Session Extension Items SHALL be encoded in an identical Type-Length-Value (TLV) container form as indicated in Figure 20. The fields of the Session Extension Item are: Flags: A one-octet field containing generic bit flags about the Item, which are listed in Table 3. All reserved header flag bits - SHALL be not set by the sender. All reserved header flag bits + SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver. If a TCPCL entity receives a Session Extension Item with an unknown Item Type and the CRITICAL - flag set, the entity SHALL close the TCPCL session with SESS_TERM - reason code of "Contact Failure". If the CRITICAL flag is not - set, an entity SHALL skip over and ignore any item with an unknown - Item Type. + flag of 1, the entity SHALL close the TCPCL session with SESS_TERM + reason code of "Contact Failure". If the CRITICAL flag is 0, an + entity SHALL skip over and ignore any item with an unknown Item + Type. Item Type: A 16-bit unsigned integer field containing the type of the extension item. This specification does not define any extension types directly, but does allocate an IANA registry for such codes (see Section 9.3). Item Length: A 16-bit unsigned integer field containing the number of Item Value octets to follow. Item Value: A variable-length data field which is interpreted @@ -1465,23 +1476,22 @@ All of the messages in this section are directly associated with transferring a bundle between TCPCL entities. A single TCPCL transfer results in a bundle (handled by the convergence layer as opaque data) being exchanged from one node to the other. In TCPCL a transfer is accomplished by dividing a single bundle up into "segments" based on the receiving-side Segment MRU (see Section 4.2). The choice of the length to use for segments is an implementation matter, but each segment MUST be no larger than the receiving node's maximum receive unit (MRU) (see the field "Segment - MRU" of Section 4.2). The first segment for a bundle MUST set the - 'START' flag, and the last one MUST set the 'end' flag in the - XFER_SEGMENT message flags. + MRU" of Section 4.2). The first segment for a bundle is indicated by + the 'START' flag and the last segment is indicated by the 'END' flag. 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. If multiple bundles are transmitted on a single TCPCL connection, they MUST be transmitted consecutively without interleaving of segments from multiple bundles. 5.2.1. Bundle Transfer ID @@ -1532,35 +1542,35 @@ +------------------------------+ | Data contents (octet string) | +------------------------------+ Figure 22: Format of XFER_SEGMENT Messages The fields of the XFER_SEGMENT message are: Message Flags: A one-octet field of single-bit flags, interpreted according to the descriptions in Table 5. All reserved header - flag bits SHALL be not set by the sender. All reserved header + flag bits SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver. Transfer ID: A 64-bit unsigned integer identifying the transfer being made. Transfer Extension Length and Transfer Extension Items: Together these fields represent protocol extension data for this specification. The Transfer Extension Length and Transfer Extension Item fields SHALL only be present when the 'START' flag - is set on the message. The Transfer Extension Length is the total - number of octets to follow which are used to encode the Transfer - Extension Item list. The encoding of each Transfer Extension Item - is within a consistent data container as described in - Section 5.2.5. The full set of transfer extension items apply + is set to 1 on the message. The Transfer Extension Length is the + total number of octets to follow which are used to encode the + Transfer Extension Item list. The encoding of each Transfer + Extension Item is within a consistent data container as described + in Section 5.2.5. The full set of transfer extension items apply only to the assoicated single transfer. The order and mulitplicity of these transfer extension items MAY be significant, as defined in the associated type specification(s). Data length: A 64-bit unsigned integer indicating the number of octets in the Data contents to follow. Data contents: The variable-length data payload of the message. +----------+--------+-----------------------------------------------+ @@ -1572,29 +1582,29 @@ | START | 0x02 | If bit is set, indicates that this is the | | | | first segment of the transfer. | | | | | | Reserved | others | +----------+--------+-----------------------------------------------+ Table 5: XFER_SEGMENT Flags The flags portion of the message contains two optional values in the two low-order bits, denoted 'START' and 'END' in Table 5. The - 'START' bit MUST be set to one if it precedes the transmission of the - first segment of a transfer. The 'END' bit MUST be set to one when - transmitting the last segment of a transfer. In the case where an - entire transfer is accomplished in a single segment, both the 'START' - and 'END' bits MUST be set to one. + 'START' flag SHALL be set to 1 when transmitting the first segment of + a transfer. The 'END' flag SHALL be set to 1 when transmitting the + last segment of a transfer. In the case where an entire transfer is + accomplished in a single segment, both the 'START' and 'END' flags + SHALL be set to 1. Once a transfer of a bundle has commenced, the node MUST only send segments containing sequential portions of that bundle until it sends - a segment with the 'END' bit set. No interleaving of multiple + a segment with the 'END' flag set to 1. No interleaving of multiple transfers from the same node is possible within a single TCPCL session. Simultaneous transfers between two entities MAY be achieved using multiple TCPCL sessions. 5.2.3. Data Acknowledgments (XFER_ACK) Although the TCP transport provides reliable transfer of data between transport peers, the typical BSD sockets interface provides no means to inform a sending application of when the receiving application has processed some amount of transmitted data. Thus, after transmitting @@ -1615,21 +1625,21 @@ +-----------------------------+ | Acknowledged length (U64) | +-----------------------------+ Figure 23: Format of XFER_ACK Messages The fields of the XFER_ACK message are: Message Flags: A one-octet field of single-bit flags, interpreted according to the descriptions in Table 5. All reserved header - flag bits SHALL be not set by the sender. All reserved header + flag bits SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver. Transfer ID: A 64-bit unsigned integer identifying the transfer being acknowledged. Acknowledged length: A 64-bit unsigned integer indicating the total number of octets in the transfer which are being acknowledged. A receiving TCPCL node SHALL send an XFER_ACK message in response to each received XFER_SEGMENT message. The flags portion of the @@ -1724,41 +1734,41 @@ 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 subsequently. Note, however, that this requirement does not ensure that an entity will not receive another XFER_SEGMENT for the same bundle after transmitting a XFER_REFUSE message since messages MAY cross on the wire; if this happens, subsequent segments of the bundle SHALL also be refused with a XFER_REFUSE message. Note: If a bundle transmission is aborted in this way, the receiver - MAY not receive a segment with the 'END' flag set to '1' for the + MAY not receive a segment with the 'END' flag set to 1 for the aborted bundle. The beginning of the next bundle is identified by - the 'START' bit set to '1', indicating the start of a new transfer, + the 'START' flag set to 1, indicating the start of a new transfer, and with a distinct Transfer ID value. 5.2.5. Transfer Extension Items Each of the Transfer Extension Items SHALL be encoded in an identical Type-Length-Value (TLV) container form as indicated in Figure 25. The fields of the Transfer Extension Item are: Flags: A one-octet field containing generic bit flags about the Item, which are listed in Table 7. All reserved header flag bits - SHALL be not set by the sender. All reserved header flag bits + SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver. If a TCPCL node receives a Transfer Extension Item with an unknown Item Type and the CRITICAL - flag set, the node SHALL refuse the transfer with an XFER_REFUSE - reason code of "Extension Failure". If the CRITICAL flag is not - set, an entity SHALL skip over and ignore any item with an unknown - Item Type. + flag is 1, the node SHALL refuse the transfer with an XFER_REFUSE + reason code of "Extension Failure". If the CRITICAL flag is 0, an + entity SHALL skip over and ignore any item with an unknown Item + Type. Item Type: A 16-bit unsigned integer field containing the type of the extension item. This specification allocates an IANA registry for such codes (see Section 9.4). Item Length: A 16-bit unsigned integer field containing the number of Item Value octets to follow. Item Value: A variable-length data field which is interpreted according to the associated Item Type. This specification places @@ -1794,21 +1804,21 @@ preemptively refuse bundles that would exceed their resources or to prepare storage on the receiving node for the upcoming bundle data. Multiple Transfer Length extension items SHALL NOT occur within the same transfer. The lack of a Transfer Length extension item in any transfer SHALL NOT imply anything about the potential length of the transfer. The Transfer Length extension SHALL be assigned transfer extension type ID 0x0001. If a transfer occupies exactly one segment (i.e. both START and END - bits are set) the Transfer Length extension SHOULD NOT be present. + flags are 1) the Transfer Length extension SHOULD NOT be present. The extension does not provide any additional information for single- segment transfers. The format of the Transfer Length data is as follows in Figure 26. +----------------------+ | Total Length (U64) | +----------------------+ Figure 26: Format of Transfer Length data @@ -1824,64 +1834,64 @@ 6. Session Termination This section describes the procedures for ending a TCPCL session. 6.1. Session Termination Message (SESS_TERM) To cleanly shut down a session, a SESS_TERM message SHALL be transmitted by either node at any point following complete transmission of any other message. When sent to initiate a - termination, the REPLY bit of a SESS_TERM message SHALL NOT be set. - Upon receiving a SESS_TERM message after not sending a SESS_TERM - message in the same session, an entity SHALL send an acknowledging - SESS_TERM message. When sent to acknowledge a termination, a - SESS_TERM message SHALL have identical data content from the message - being acknowledged except for the REPLY bit, which is set to indicate + termination, the REPLY flag of a SESS_TERM message SHALL be 0. Upon + receiving a SESS_TERM message after not sending a SESS_TERM message + in the same session, an entity SHALL send an acknowledging SESS_TERM + message. When sent to acknowledge a termination, a SESS_TERM message + SHALL have identical data content from the message being acknowledged + except for the REPLY flag, which is set to 1 to indicate acknowledgement. After sending a SESS_TERM message, an entity MAY continue a possible in-progress transfer in either direction. After sending a SESS_TERM message, an entity SHALL NOT begin any new outgoing transfer for the remainder of the session. After receving a SESS_TERM message, an entity SHALL NOT accept any new incoming transfer for the remainder of the session. Instead of following a clean shutdown sequence, after transmitting a SESS_TERM message an entity MAY immediately close the associated TCP connection. When performing an unclean shutdown, a receiving node SHOULD acknowledge all received data segments before closing the TCP connection. Not acknowledging received segments can result in unnecessary retransmission. When performing an unclean shutodwn, a transmitting node SHALL treat either sending or receiving a SESS_TERM message (i.e. before the final acknowledgment) as a failure of the - transfer. Any delay between request to terminate the TCP connection - and actual closing of the connection (a "half-closed" state) MAY be + transfer. Any delay between request to close the TCP connection and + actual closing of the connection (a "half-closed" state) MAY be ignored by the TCPCL node. The format of the SESS_TERM message is as follows in Figure 27. +-----------------------------+ | Message Header | +-----------------------------+ | Message Flags (U8) | +-----------------------------+ | Reason Code (U8) | +-----------------------------+ Figure 27: Format of SESS_TERM Messages The fields of the SESS_TERM message are: Message Flags: A one-octet field of single-bit flags, interpreted according to the descriptions in Table 8. All reserved header - flag bits SHALL be not set by the sender. All reserved header + flag bits SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver. Reason Code: A one-octet refusal reason code interpreted according to the descriptions in Table 9. +----------+--------+-----------------------------------------------+ | Name | Code | Description | +----------+--------+-----------------------------------------------+ | REPLY | 0x01 | If bit is set, indicates that this message is | | | | an acknowledgement of an earlier SESS_TERM | @@ -1979,27 +1989,27 @@ 8. Security Considerations 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- to-end bundle security. The bundle security mechanisms defined in [I-D.ietf-dtn-bpsec] are to be used instead. When negotating whether to use TLS security as part of the contact header exchange, it is possible for a man-in-the-middle attacker to - unset the CAN_TLS flag on either side of the exchange. This leads to - the "SSL Stripping" attack described in [RFC7457]. If TLS is desired - for use on any TCPCL network, it is strongly encouraged that the - security policy disallow use of TCPCL when "Enable TLS" is negotiated - to false. This requires that the TLS handshake occurs, regardless of - the policy-driven parameters of the handshake and policy-driven - handling of the handshake outcome. + set the CAN_TLS flag to 0 on either side of the exchange. This leads + to the "SSL Stripping" attack described in [RFC7457]. If TLS is + desired for use on any TCPCL network, it is strongly encouraged that + the security policy disallow use of TCPCL when "Enable TLS" is + negotiated to false. This requires that the TLS handshake occurs, + regardless of the policy-driven parameters of the handshake and + policy-driven handling of the handshake outcome. Even when using TLS to secure the TCPCL session, the actual ciphersuite negotiated between the TLS peers MAY be insecure. TLS can be used to perform authentication without data confidentiality, for example. It is up to security policies within each TCPCL node to ensure that the negotiated TLS ciphersuite meets transport security requirements. This is identical behavior to STARTTLS use in [RFC2595]. The certificates exchanged by TLS enable authentication of peer host @@ -2104,20 +2114,31 @@ specification. IANA will create, under the "Bundle Protocol" registry, a sub- registry titled "Bundle Protocol TCP Convergence-Layer Version 4 Session Extension Types" and initialize it with the contents of Table 10. The registration procedure is Expert Review within the lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are reserved for use on private networks for functions not published to the IANA. + Specifications of new session extension types need to define the + encoding of the Item Value data as well as any meaning or restriction + on the number of or order of instances of the type within an + extension item list. Specifications need to define how the extension + functions when no instance of the new extension type is received + during session negotiation. + + Expert(s) are encouraged to be biased towards approving registrations + unless they are abusive, frivolous, or actively harmful (not merely + aesthetically displeasing, or architecturally dubious). + +----------------+--------------------------+ | Code | Session Extension Type | +----------------+--------------------------+ | 0x0000 | Reserved | | | | | 0x0001--0x7FFF | Unassigned | | | | | 0x8000--0xFFFF | Private/Experimental Use | +----------------+--------------------------+ @@ -2129,20 +2150,31 @@ specification. IANA will create, under the "Bundle Protocol" registry, a sub- registry titled "Bundle Protocol TCP Convergence-Layer Version 4 Transfer Extension Types" and initialize it with the contents of Table 11. The registration procedure is Expert Review within the lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are reserved for use on private networks for functions not published to the IANA. + Specifications of new transfer extension types need to define the + encoding of the Item Value data as well as any meaning or restriction + on the number of or order of instances of the type within an + extension item list. Specifications need to define how the extension + functions when no instance of the new extension type is received in a + transfer. + + Expert(s) are encouraged to be biased towards approving registrations + unless they are abusive, frivolous, or actively harmful (not merely + aesthetically displeasing, or architecturally dubious). + +----------------+---------------------------+ | Code | Transfer Extension Type | +----------------+---------------------------+ | 0x0000 | Reserved | | | | | 0x0001 | Transfer Length Extension | | | | | 0x0002--0x7FFF | Unassigned | | | | | 0x8000--0xFFFF | Private/Experimental Use | @@ -2155,20 +2187,32 @@ EDITOR NOTE: sub-registry to-be-created upon publication of this specification. IANA will create, under the "Bundle Protocol" registry, a sub- registry titled "Bundle Protocol TCP Convergence-Layer Version 4 Message Types" and initialize it with the contents of Table 12. The registration procedure is RFC Required within the lower range 0x01-- 0xEF. Values in the range 0xF0--0xFF are reserved for use on private networks for functions not published to the IANA. + Specifications of new message types need to define the encoding of + the message data as well as the purpose and relationship of the new + message to existing session/transfer state within the baseline + message sequencing. + + Expert(s) are encouraged to favor new session/transfer extension + types over new message types. TCPCL messages are not self- + delimiting, so care must be taken in introducing new message types. + If an entity receives an unknown message type the only thing that can + be done is to send a MSG_REJECT and close the TCP connection; not + even a clean termination can be done at that point. + +------------+--------------------------+ | Code | Message Type | +------------+--------------------------+ | 0x00 | Reserved | | | | | 0x01 | XFER_SEGMENT | | | | | 0x02 | XFER_ACK | | | | | 0x03 | XFER_REFUSE | @@ -2194,20 +2238,29 @@ specification. IANA will create, under the "Bundle Protocol" registry, a sub- registry titled "Bundle Protocol TCP Convergence-Layer Version 4 XFER_REFUSE Reason Codes" and initialize it with the contents of Table 13. The registration procedure is Specification Required within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF are reserved for use on private networks for functions not published to the IANA. + Specifications of new XFER_REFUSE reason codes need to define the + meaning of the reason and disambiguate it with pre-exisiting reasons. + Each refusal reason needs to be usable by the receving BP Agent to + make retransmission or re-routing decisions. + + Expert(s) are encouraged to be biased towards approving registrations + unless they are abusive, frivolous, or actively harmful (not merely + aesthetically displeasing, or architecturally dubious). + +------------+--------------------------+ | Code | Refusal Reason | +------------+--------------------------+ | 0x00 | Unknown | | | | | 0x01 | Extension Failure | | | | | 0x02 | Completed | | | | | 0x03 | No Resources | @@ -2227,20 +2280,29 @@ specification. IANA will create, under the "Bundle Protocol" registry, a sub- registry titled "Bundle Protocol TCP Convergence-Layer Version 4 SESS_TERM Reason Codes" and initialize it with the contents of Table 14. The registration procedure is Specification Required within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF are reserved for use on private networks for functions not published to the IANA. + Specifications of new SESS_TERM reason codes need to define the + meaning of the reason and disambiguate it with pre-exisiting reasons. + Each termination reason needs to be usable by the receving BP Agent + to make re-connection decisions. + + Expert(s) are encouraged to be biased towards approving registrations + unless they are abusive, frivolous, or actively harmful (not merely + aesthetically displeasing, or architecturally dubious). + +------------+--------------------------+ | Code | Termination Reason | +------------+--------------------------+ | 0x00 | Unknown | | | | | 0x01 | Idle timeout | | | | | 0x02 | Version mismatch | | | | | 0x03 | Busy | @@ -2262,20 +2324,29 @@ specification. IANA will create, under the "Bundle Protocol" registry, a sub- registry titled "Bundle Protocol TCP Convergence-Layer Version 4 MSG_REJECT Reason Codes" and initialize it with the contents of Table 15. The registration procedure is Specification Required within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF are reserved for use on private networks for functions not published to the IANA. + Specifications of new MSG_REJECT reason codes need to define the + meaning of the reason and disambiguate it with pre-exisiting reasons. + Each rejection reason needs to be usable by the receving TCPCL Entity + to make message sequencing and/or session termination decisions. + + Expert(s) are encouraged to be biased towards approving registrations + unless they are abusive, frivolous, or actively harmful (not merely + aesthetically displeasing, or architecturally dubious). + +------------+--------------------------+ | Code | Rejection Reason | +------------+--------------------------+ | 0x00 | reserved | | | | | 0x01 | Message Type Unknown | | | | | 0x02 | Message Unsupported | | | | | 0x03 | Message Unexpected | @@ -2324,20 +2395,25 @@ (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . + [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) + Extensions: Extension Definitions", RFC 6066, + DOI 10.17487/RFC6066, January 2011, + . + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security @@ -2355,22 +2431,22 @@ 11.2. Informative References [github-dtn-bpbis-tcpcl] Sipos, B., "TCPCL Example Implementation", . [I-D.ietf-dtn-bpsec] Birrane, E. and K. McKeever, "Bundle Protocol Security - Specification", draft-ietf-dtn-bpsec-10 (work in - progress), April 2019. + Specification", draft-ietf-dtn-bpsec-12 (work in + progress), September 2019. [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999, . [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, .