--- 1/draft-ietf-dtn-tcpclv4-09.txt 2018-11-06 17:21:41.767058085 -0800 +++ 2/draft-ietf-dtn-tcpclv4-10.txt 2018-11-06 17:21:41.875060695 -0800 @@ -1,29 +1,29 @@ Delay Tolerant Networking B. Sipos Internet-Draft RKF Engineering Obsoletes: 7242 (if approved) M. Demmer Intended status: Standards Track UC Berkeley -Expires: December 26, 2018 J. Ott +Expires: May 9, 2019 J. Ott Aalto University S. Perreault - June 24, 2018 + November 5, 2018 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 - draft-ietf-dtn-tcpclv4-09 + draft-ietf-dtn-tcpclv4-10 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 + 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 reliable transport of such bundles. Several new IANA registries are defined for TCPCLv4 which define some behaviors inherited from TCPCLv3 but with updated encodings and/or semantics. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -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 December 26, 2018. + This Internet-Draft will expire on May 9, 2019. Copyright Notice Copyright (c) 2018 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 @@ -83,35 +83,35 @@ 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 28 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 29 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 30 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 30 5.2.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 31 5.2.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 34 5.2.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 35 5.2.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 36 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 38 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 38 - 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 40 + 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 41 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 43 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 43 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 44 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 44 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 45 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 46 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 47 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 48 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 48 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 49 11.2. Informative References . . . . . . . . . . . . . . . . . 49 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 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 @@ -888,56 +888,68 @@ negotiate values for the session parameters. If the magic string is not present or is not valid, the connection MUST be terminated. The intent of the magic string is to provide some protection against an inadvertent TCP connection by a different protocol than the one described in this document. To prevent a flood of repeated connections from a misconfigured application, an entity MAY elect to hold an invalid connection open and idle for some time before closing it. - A connecting TCPCL node SHALL send the highest TCPCL protocol version - on a first session attempt for a TCPCL peer. If a connecting 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. + The first negotiation is on the TCPCL protocol version to use. The + active node always sends its Contact Header first and waits for a + 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. - If an entity receives a contact header containing a version that is - greater than the current version of the protocol that the node - implements, then the node SHALL shutdown the session with a reason - code of "Version mismatch". If an entity receives a contact header - with a version that is lower than the version of the protocol that - the node implements, the node MAY either terminate the session (with - a reason code of "Version mismatch") or the node MAY adapt its - operation to conform to the older version of the protocol. The - decision of version fall-back is an implementation matter. + 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 + 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 protocol 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 that the node implements, the node MAY either terminate the + session (with a reason code of "Version mismatch") or the node MAY + adapt its operation to conform to the older version of the protocol. + The decision of version fall-back is an implementation matter. 4.4. Session Security This version of the TCPCL supports establishing a Transport Layer Security (TLS) session within an existing TCP connection. When TLS is used within the TCPCL it affects the entire session. Once established, there is no mechanism available to downgrade a TCPCL session to non-TLS operation. If this is desired, the entire TCPCL session MUST be terminated and a new non-TLS-negotiated session established. The use of TLS is negotated using the Contact Header as described in Section 4.3. After negotiating an Enable TLS parameter of true, and before any other TCPCL messages are sent within the session, the session entities SHALL begin a TLS handshake in accordance with [RFC5246]. The parameters within each TLS negotiation are - implementation dependent but any TCPCL node SHOULD follow all - recommended best practices of [RFC7525]. By convention, this - protocol uses the node which initiated the underlying TCP connection - as the "client" role of the TLS handshake request. + implementation dependent but any TCPCL node SHALL follow all + recommended practices of [BCP195], or any updates or successors that + become part of [BCP195]. By convention, this protocol uses the node + which initiated the 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. 4.4.1. TLS Handshake Result If a TLS handshake cannot negotiate a TLS session, both entities of the TCPCL session SHALL terminate the TCP connection. At this point the TCPCL session has not yet been established so there is no TCPCL @@ -1231,23 +1243,26 @@ is dependent on the measured RTT for the TCP connection so that KEEPALIVE messages MAY experience noticeable latency. 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 sides SHOULD send a KEEPALIVE message whenever the negotiated interval has elapsed with no transmission of any message (KEEPALIVE or other). If no message (KEEPALIVE or other) has been received in a session - after some implementation-defined time duration, then the node MAY + after some implementation-defined time duration, then the node SHOULD terminate the session by transmitting a SESS_TERM message (as - described in Section 6.1) with reason code "Idle Timeout. + described in Section 6.1) with reason code "Idle Timeout". If + configurable, the idle timeout duration SHOULD be no shorter than + twice the keepalive interval. If not configurable, the idle timeout + duration SHOULD be exactly twice the keepout interval. 5.1.2. Message Rejection (MSG_REJECT) If a TCPCL node receives a message which is unknown to it (possibly due to an unhandled protocol mismatch) or is inappropriate for the current session state (e.g. a KEEPALIVE message received after contact header negotiation has disabled that feature), there is a protocol-level message to signal this condition in the form of a MSG_REJECT reply. @@ -1652,24 +1667,28 @@ and with a distinct Transfer ID value. 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. Upon receiving a SESS_TERM - message after not sending a SESS_TERM message in the same session, an - entity SHOULD send a confirmation SESS_TERM message with identical - content to the SESS_TERM for which it is confirming. + 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 SHOULD 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 + 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 (i.e. send an XFER_INIT message) 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 @@ -1677,59 +1696,55 @@ SHOULD acknowledge all received data segments before closing the TCP connection. 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 ignored by the TCPCL node. The format of the SESS_TERM message is as follows in Figure 25. - +-----------------------------------+ + +-----------------------------+ | Message Header | - +-----------------------------------+ + +-----------------------------+ | Message Flags (U8) | - +-----------------------------------+ - | Reason Code (optional U8) | - +-----------------------------------+ + +-----------------------------+ + | Reason Code (U8) | + +-----------------------------+ Figure 25: 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. Reason Code: A one-octet refusal reason code interpreted according - to the descriptions in Table 9. The Reason Code is present or - absent as indicated by one of the flags. + to the descriptions in Table 9. +----------+--------+-----------------------------------------------+ | Name | Code | Description | +----------+--------+-----------------------------------------------+ - | R | 0x02 | If bit is set, indicates that a Reason Code | - | | | field is present. | + | REPLY | 0x01 | If bit is set, indicates that this message is | + | | | an acknowledgement of an earlier SESS_TERM | + | | | message. | | | | | | Reserved | others | +----------+--------+-----------------------------------------------+ Table 8: SESS_TERM Flags - It is possible for an entity to convey optional information regarding - the reason for session termination. To do so, the node MUST set the - 'R' bit in the message flags and transmit a one-octet reason code - immediately following the message header. The specified values of - the reason code are: - +---------------+---------------------------------------------------+ | Name | Description | +---------------+---------------------------------------------------+ + | Unknown | A termination reason is not available. | + | | | | Idle timeout | The session is being closed due to idleness. | | | | | Version | The node cannot conform to the specified TCPCL | | mismatch | protocol version. | | | | | Busy | The node is too busy to handle the current | | | session. | | | | | Contact | The node cannot interpret or negotiate contact | | Failure | header option. | @@ -2041,31 +2056,33 @@ 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 15. The registration procedure is RFC Required. +------------+---------------------+ | Code | Shutdown Reason | +------------+---------------------+ - | 0x00 | Idle timeout | + | 0x00 | Unknown | | | | - | 0x01 | Version mismatch | + | 0x01 | Idle timeout | | | | - | 0x02 | Busy | + | 0x02 | Version mismatch | | | | - | 0x03 | Contact Failure | + | 0x03 | Busy | | | | - | 0x04 | Resource Exhaustion | + | 0x04 | Contact Failure | | | | - | 0x05--0xFF | Unassigned | + | 0x05 | Resource Exhaustion | + | | | + | 0x06--0xFF | Unassigned | +------------+---------------------+ Table 15: SESS_TERM Reason Codes 9.8. MSG_REJECT Reason Codes EDITOR NOTE: sub-registry to-be-created upon publication of this specification. IANA will create, under the "Bundle Protocol" registry, a sub- @@ -2091,66 +2108,65 @@ 10. Acknowledgments This specification is based on comments on implementation of [RFC7242] provided from Scott Burleigh. 11. References 11.1. Normative References + [BCP195] 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. + [I-D.ietf-dtn-bpbis] - Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol - Version 7", draft-ietf-dtn-bpbis-11 (work in progress), - May 2018. + Fall, K. and E. Birrane, "Bundle Protocol Version 7", + draft-ietf-dtn-bpbis-11 (work in progress), May 2018. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . - [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, . - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . 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-06 (work in - progress), October 2017. + Specification", draft-ietf-dtn-bpsec-08 (work in + progress), October 2018. [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, .