--- 1/draft-ietf-dtn-tcpclv4-15.txt 2019-11-22 14:13:12.416266431 -0800 +++ 2/draft-ietf-dtn-tcpclv4-16.txt 2019-11-22 14:13:12.544269701 -0800 @@ -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: April 18, 2020 J. Ott +Expires: May 25, 2020 J. Ott Aalto University S. Perreault - October 16, 2019 + November 22, 2019 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 - draft-ietf-dtn-tcpclv4-15 + draft-ietf-dtn-tcpclv4-16 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 April 18, 2020. + This Internet-Draft will expire on May 25, 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 @@ -61,62 +61,74 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 5 3. General Protocol Description . . . . . . . . . . . . . . . . 8 3.1. Convergence Layer Services . . . . . . . . . . . . . . . 8 3.2. TCPCL Session Overview . . . . . . . . . . . . . . . . . 10 3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 12 3.4. Transfer Segmentation Policies . . . . . . . . . . . . . 18 3.5. Example Message Exchange . . . . . . . . . . . . . . . . 19 - 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 21 + 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 20 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 21 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 22 4.3. Contact Validation and Negotiation . . . . . . . . . . . 23 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 24 4.4.1. TLS Handshake . . . . . . . . . . . . . . . . . . . . 24 - 4.4.2. TLS Authentication . . . . . . . . . . . . . . . . . 25 + 4.4.2. TLS Authentication . . . . . . . . . . . . . . . . . 26 4.4.3. Example TLS Initiation . . . . . . . . . . . . . . . 27 - 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 27 - 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 28 - 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 30 - 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 31 - 5. Established Session Operation . . . . . . . . . . . . . . . . 32 - 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 32 - 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 32 - 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 33 - 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 34 - 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 35 - 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 35 - 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 37 - 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 38 - 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 41 - 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 43 - 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 . . . . . . . . . . . . . . . . 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 + 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 28 + 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 30 + 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 31 + 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 32 + 5. Established Session Operation . . . . . . . . . . . . . . . . 33 + 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 33 + 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 34 + 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 34 + 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 35 + 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 36 + 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 36 + 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 38 + 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 39 + 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 42 + 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 44 + 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 44 + 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 46 + 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 46 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 + 8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 47 + 8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 47 + 8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 47 + 8.4. Threat: Transport Security Stripping . . . . . . . . . . 47 + 8.5. Threat: Weak Ciphersuite Downgrade . . . . . . . . . . . 48 + 8.6. Threat: Invalid Certificate Use . . . . . . . . . . . . . 48 + 8.7. Threat: Symmetric Key Overuse . . . . . . . . . . . . . . 48 + 8.8. Threat: BP Node Impersonation . . . . . . . . . . . . . . 48 + 8.9. Threat: Denial of Service . . . . . . . . . . . . . . . . 49 + 8.10. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 50 + 8.10.1. TLS Without Authentication . . . . . . . . . . . . . 50 + 8.10.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 50 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 + 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 51 + 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 51 + 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 52 + 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 53 + 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 54 + 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 55 + 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 56 + 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 57 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 58 + 11.2. Informative References . . . . . . . . . . . . . . . . . 60 + Appendix A. Significant changes from RFC7242 . . . . . . . . . . 61 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 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" @@ -177,23 +189,28 @@ (peers) within a network or across an internet. The mapping of Node ID to potential CL protocol and network address is left to implementation and configuration of the BP Agent and its various potential routing strategies. o Logic for routing bundles along a path toward a bundle's endpoint. This CL protocol is involved only in transporting bundles between adjacent nodes in a routing sequence. o Policies or mechanisms for assigning X.509 certificates, - provisioning or deploying certificates and private keys, or - configuring security parameters on an individual BP node or across - a network. + provisioning, deploying, or accessing certificates and private + keys, deploying or accessing certificate revocation lists (CRLs), + or configuring security parameters on an individual entity or + across a network. + + o Uses of TLS which are not based on X.509 certificate + authentication (see Section 8.10.2) or in which authentication is + not available (see Section 8.10.1). Any TCPCL implementation requires a BP agent to perform those above listed functions in order to perform end-to-end bundle delivery. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all @@ -226,21 +243,21 @@ These relationships are illustrated in Figure 2. For most TCPCL behavior within a session, the two entities are symmetric and there is no protocol distinction between them. Some specific behavior, particularly during session establishment, distinguishes between the active entity and the passive entity. For the remainder of this document, the term "entity" without the prefix "TCPCL" refers to a TCPCL entity. TCP Connection: The term Connection in this specification exclusively refers to a TCP connection and any and all behaviors, - sessions, and other states association with that TCP connection. + sessions, and other states associated 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 closing the TCP connection or due to network errors causing a @@ -305,36 +322,36 @@ | | | | | | | | +---------------------------------+ | | | | | +--->| Passively Inititated Session #n +-------->| | | | +---------------------------------+ | +----------------+ | | | +-----------------+ +--------------------------------------------+ Figure 2: The relationships between TCPCL entities +----------------------------+ +--------------------------+ -| TCPCL Session | | TCPCL "Other" Session | +| "Own" TCPCL Session | | "Other" TCPCL Session | | | | | | +-----------------------+ | | +---------------------+ | | | TCP Connection | | | | TCP Connection | | | | | | | | | | | | +-------------------+ | | | | +-----------------+ | | | | | Optional Inbound | | | | | | Peer Outbound | | | | | | Transfer Stream |<-[Seg]--[Seg]--[Seg]-| | Transfer Stream | | | -| | | ----- | | | | | | ----- | | | +| | | ----- |--[Ack]----[Ack]------->| ----- | | | | | | RECEIVER | | | | | | SENDER | | | | | +-------------------+ | | | | +-----------------+ | | | | | | | | | | | | +-------------------+ | | | | +-----------------+ | | | | | Optional Outbound | | | | | | Peer Inbound | | | | | | Transfer Stream |------[Seg]---[Seg]---->| Transfer Stream | | | -| | | ----- | | | | | | ----- | | | +| | | ----- |<--[Ack]----[Ack]-[Ack]-| ----- | | | | | | SENDER | | | | | | RECEIVER | | | | | +-------------------+ | | | | +-----------------+ | | | +-----------------------+ | | +---------------------+ | +----------------------------+ +--------------------------+ Figure 3: The relationship within a TCPCL Session of its two streams 3. General Protocol Description The service of this protocol is the transmission of DTN bundles via @@ -361,24 +378,24 @@ terminate an established TCPCL session with a peer entity. The terminate request is on a per-session basis. Session State Changed: The TCPCL supports indication when the session state changes. The top-level session states indicated are: Connecting: A TCP connection is being established. This state only applies to the active entity. - Contact Negotating: A TCP connection has been made (as either + Contact Negotiating: A TCP connection has been made (as either active or passive entity) and contact negotiation has begun. - Session Negotiating: Contact negotation has been completed + Session Negotiating: Contact negotiation has been completed (including possible TLS use) and session negotiation has begun. Established: The session has been fully established and is ready for its first transfer. Ending: The entity received a SESS_TERM message and is in the ending state. Terminated: The session has finished normal termination sequencing. @@ -400,28 +417,28 @@ BP agent to transmit bundle data over an established TCPCL session. Transmission request is on a per-session basis, the CL does not necessarily perform any per-session or inter-session queueing. Any queueing of transmissions is the obligation of the BP agent. Transmission Success: The TCPCL supports positive indication when a bundle has been fully transferred to a peer entity. Transmission Intermediate Progress: The TCPCL supports positive - indication of intermediate progress of transferr to a peer entity. + indication of intermediate progress of transfer to a peer entity. This intermediate progress is at the granularity of each 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 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 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. @@ -442,45 +459,45 @@ rejects an attempted transfer for some local policy reason or when a TCPCL session ends before transfer success. The TCPCL itself does not have a notion of transfer timeout. 3.2. TCPCL Session Overview First, one node establishes a TCPCL session to the other by initiating a TCP connection in accordance with [RFC0793]. After setup of the TCP connection is complete, an initial contact header is exchanged in both directions to establish a shared TCPCL version and - possibly initiate TLS security. Once contact negotiation is - complete, TCPCL messaging is available and the session negotiation is - used to set parameters of the TCPCL session. One of these parameters - is a Node ID of each TCPCL Entity. This is used to assist in routing - and forwarding messages by the BP Agent and is part of the - authentication capability provided by TLS. + negotiate the use of TLS security (as described in Section 4). Once + contact negotiation is complete, TCPCL messaging is available and the + session negotiation is used to set parameters of the TCPCL session. + One of these parameters is a Node ID of each TCPCL Entity. This is + used to assist in routing and forwarding messages by the BP Agent and + is part of the authentication capability provided by TLS. Once negotiated, the parameters of a TCPCL session cannot change and if there is a desire by either peer to transfer data under different parameters then a new session must be established. This makes CL logic simpler but relies on the assumption that establishing a TCP connection is lightweight enough that TCP connection overhead is negligable compared to TCPCL data sizes. Once the TCPCL session is established and configured in this way, bundles can be transferred in either direction. Each transfer is performed by an sequence of logical segments of data within XFER_SEGMENT messages. Multiple bundles can be transmitted consecutively in a single direction on a single TCPCL connection. Segments from different bundles are never interleaved. Bundle interleaving can be accomplished by fragmentation at the BP layer or by establishing multiple TCPCL sessions between the same peers. There is no fundamental limit on the number of TCPCL sessions which a single node can establish beyond the limit imposed by the number of - available (ephemeral) TCP ports of the passive peer. + available (ephemeral) TCP ports of the passive entity. A feature of this protocol is for the receiving node to send acknowledgment (XFER_ACK) messages as bundle data segments arrive. The rationale behind these acknowledgments is to enable the sender node to determine how much of the bundle has been received, so that in case the session is interrupted, it can perform reactive fragmentation to avoid re-sending the already transmitted part of the bundle. In addition, there is no explicit flow control on the TCPCL layer. @@ -538,22 +555,20 @@ | Negotiated V +-------------+ +-------------+ | Established |----New Transfer---->| Established | | Session | | Session | | Idle |<---Transfers Done---| Live | +-------------+ +-------------+ | | +------------------------------------+ | - [SESSTERM] Exchange - | V +-------------+ | Established | +-------------+ | Session |----Transfers------>| TCP | | Ending | Done | Terminating | +-------------+ +-------------+ | +----------TCP Close Message----------+ | V @@ -566,58 +581,60 @@ Notes on Established Session states: Session "Live" means transmitting or reeiving over a transfer stream. Session "Idle" means no transmission/reception over a transfer stream. Session "Ending" means no new transfers will be allowed. - Contact negotation involves exchanging a Contact Header (CH) in both + Contact negotiation involves exchanging a Contact Header (CH) in both directions and deriving a negotiated state from the two headers. The contact negotiation sequencing is performed either as the active or - passive peer, and is illustrated in Figure 5 and Figure 6 + passive entity, and is illustrated in Figure 5 and Figure 6 respectively which both share the data validation and analyze final states of the "[PCH]" activity of Figure 7 and the "[TCPCLOSE]" activity which indicates TCP connection close. Successful negotiation results in one of the Session Initiation "[SI]" - activities being performed. + activities being performed. To avoid data loss, a Session + Termination "[ST]" exchange allows cleanly finishing transfers before + a session is ended. +-------+ | START | +-------+ | TCP Connecting V +-----------+ | TCP | +---------+ | Connected |--Send CH-->| Waiting |--Timeout-->[TCPCLOSE] +-----------+ +---------+ | Recevied CH V [PCH] - Figure 5: Contact Initiation as Active peer + Figure 5: Contact Initiation as Active Entity +-----------+ +---------+ | TCP |--Wait for-->| Waiting |--Timeout-->[TCPCLOSE] | Connected | CH +---------+ +-----------+ | Received CH V +-----------------+ | Preparing reply |--Send CH-->[PSI] +-----------------+ - Figure 6: Contact Initiation as Passive peer + Figure 6: Contact Initiation as Passive Entity +-----------+ | Peer CH | | available | +-----------+ | Validate and Negotiate V +------------+ @@ -627,64 +644,64 @@ No TLS +----Negotiate---+ | V TLS | Failure +-----------+ V | | TCPCL | +---------------+ | Messaging |<--Success--| TLS Finished | | Available | +---------------+ +-----------+ Figure 7: Processing of Contact Header [PCH] - Session negotation involves exchanging a session initialization + Session negotiation involves exchanging a session initialization (SESS_INIT) message in both directions and deriving a negotiated state from the two messages. The session negotiation sequencing is - performed either as the active or passive peer, and is illustrated in - Figure 8 and Figure 9 respectively which both share the data + performed either as the active or passive entity, and is illustrated + in Figure 8 and Figure 9 respectively which both share the data validation and analyze final states of Figure 10. The validation here includes certificate validation and authentication when TLS is used for the session. +-----------+ | TCPCL | +---------+ - | Messaging |--Send SESS_INIT-->| Waiting |--Timeout-->[SESSTERM] + | Messaging |--Send SESS_INIT-->| Waiting |--Timeout-->[ST] | Available | +---------+ +-----------+ | Recevied SESS_INIT | V [PSI] - Figure 8: Session Initiation [SI] as Active peer + Figure 8: Session Initiation [SI] as Active Entity +-----------+ | TCPCL | +---------+ - | Messaging |----Wait for ---->| Waiting |--Timeout-->[SESSTERM] + | Messaging |----Wait for ---->| Waiting |--Timeout-->[ST] | Available | SESS_INIT +---------+ +-----------+ | Recevied SESS_INIT | +-----------------+ | Preparing reply |--Send SESS_INIT-->[PSI] +-----------------+ - Figure 9: Session Initiation [SI] as Passive peer + Figure 9: Session Initiation [SI] as Passive Entity +----------------+ | Peer SESS_INIT | | available | +----------------+ | Validate and Negotiate V +------------+ - | Negotiated |---Failure--->[SESSTERM] + | Negotiated |---Failure--->[ST] +------------+ | Success V +--------------+ | Established | | Session Idle | +--------------+ Figure 10: Processing of Session Initiation [PSI] @@ -736,32 +753,32 @@ either entity, it is the sending of the SESS_TERM message which transitions the session to the ending substate. While a session is being terminated only in-progress transfers can be completed and no new transfers can be started. +-----------+ +---------+ | Session |--Send SESS_TERM-->| Session | | Live/Idle | | Ending | +-----------+ +---------+ - Figure 13: Session Termination [SESSTERM] from the Initiator + Figure 13: Session Termination [ST] from the Initiator +-----------+ +---------+ | Session |--Send SESS_TERM-->| Session | | Live/Idle | | Ending | +-----------+<------+ +---------+ | | Receive SESS_TERM | | | +-------------+ - Figure 14: Session Termination [SESSTERM] from the Responder + Figure 14: Session Termination [ST] from the Responder 3.4. Transfer Segmentation Policies Each TCPCL session allows a negotiated transfer segmentation polcy to be applied in each transfer direction. A receiving node can set the Segment MRU in its contact header to determine the largest acceptable segment size, and a transmitting node can segment a transfer into any sizes smaller than the receiver's Segment MRU. It is a network administration matter to determine an appropriate segmentation policy for entities operating TCPCL, but guidance given here can be used to @@ -793,21 +810,21 @@ Dynamic Segmentation: Even after negotiation of a Segment MRU for each receiving node, the actual transfer segmentation only needs to guarantee than any individual segment is no larger than that MRU. In a situation where network "goodput" is dynamic, the transfer segmentation size can also be dynamic in order to control message transmission duration. Many other policies can be established in a TCPCL network between the two extremes of minimum overhead (large MRU, single-segment) and predictable message sizing (small MRU, highly segmented). Different - policies can be applied to each transfer stream to and from from any + policies can be applied to each transfer stream to and from any particular node. Additionally, future header and transfer extension types can apply further nuance to transfer policies and policy negotiation. 3.5. Example Message Exchange The following figure depicts the protocol exchange for a simple session, showing the session establishment and the transmission of a single bundle split into three data segments (of lengths "L1", "L2", and "L3") from Entity A to Entity B. @@ -819,20 +836,24 @@ also possible to pipeline multiple XFER_SEGMENT messages for different bundles without necessarily waiting for XFER_ACK messages to be returned for each one. However, interleaving data segments from different bundles is not allowed. No errors or rejections are shown in this example. Entity A Entity B ======== ======== +-------------------------+ + | Open TCP Connnection | -> +-------------------------+ + +-------------------------+ <- | Accept Connection | + +-------------------------+ + +-------------------------+ | Contact Header | -> +-------------------------+ +-------------------------+ <- | Contact Header | +-------------------------+ +-------------------------+ | SESS_INIT | -> +-------------------------+ +-------------------------+ <- | SESS_INIT | +-------------------------+ +-------------------------+ | XFER_SEGMENT (start) | -> @@ -856,20 +877,23 @@ +-------------------------+ <- | XFER_ACK (end) | | Transfer ID [I1] | | Length [L1+L2+L3] | +-------------------------+ +-------------------------+ | SESS_TERM | -> +-------------------------+ +-------------------------+ <- | SESS_TERM | +-------------------------+ + +-------------------------+ +-------------------------+ + | TCP Close | -> <- | TCP Close | + +-------------------------+ +-------------------------+ Figure 15: An example of the flow of protocol messages on a single TCP Session between two entities 4. Session Establishment For bundle transmissions to occur using the TCPCL, a TCPCL session MUST first be established between communicating entities. It is up to the implementation to decide how and when session setup is triggered. For example, some sessions MAY be opened proactively and @@ -896,33 +920,49 @@ connection failure. An entity MAY decide to re-attempt to establish the connection. If it does so, it MUST NOT overwhelm its target with repeated connection attempts. Therefore, the entity MUST retry the connection setup no earlier than some delay time from the last attempt, and it SHOULD use a (binary) exponential back-off mechanism to increase this delay in case of repeated failures. The upper limit on a re-attempt back-off is implementation defined but SHOULD be no longer than one minute before signaling to the BP agent that a connection cannot be made. - Once a TCP connection is established, each entity MUST immediately - transmit a contact header over the TCP connection. The format of the - contact header is described in Section 4.2. Because the TCPCL - protocol version in use is part of the initial contact header, nodes - using TCPCL version 4 can coexist on a network with nodes using - earlier TCPCL versions (with some negotiation needed for - interoperation as described in Section 4.3). + Once a TCP connection is established, the active entity SHALL + immediately transmit its contact header. Upon reception of a contact + header, the passive entity SHALL transmit its contact header. If the + passive entity does not receive a Contact Header after some + implementation-defined time duration after TCP connection is + established, the entity SHALL close the TCP connection. The ordering + of the contact header exchange allows the passive entity to avoid + allocating resources to a potential TCPCL session until after a valid + contact header has been received from the passive entity. This + ordering also allows the passive peer to adapt to alternate TCPCL + protocol versions. + + The format of the contact header is described in Section 4.2. + Because the TCPCL protocol version in use is part of the initial + contact header, nodes using TCPCL version 4 can coexist on a network + with nodes using earlier TCPCL versions (with some negotiation needed + for interoperation as described in Section 4.3). 4.2. Contact Header - Once a TCP connection is established, both parties exchange a contact - header. This section describes the format of the contact header and - the meaning of its fields. + This section describes the format of the contact header and the + meaning of its fields. + + If an entity is capable of exchanging messages according to TLS 1.2 + [RFC5246] or any successors [RFC8446] that are compatible with TLS + 1.2, the CAN_TLS flag within its contanct header SHALL be set to 1. + This behavor prefers the use of TLS when possible, even if security + policy does not allow or require authentication. This follows the + opportunistic security model of [RFC7435]. Upon receipt of the contact header, both entities perform the validation and negotiation procedures defined in Section 4.3. After receiving the contact header from the other entity, either entity MAY refuse the session by sending a SESS_TERM message with an appropriate reason code. The format for the Contact Header is as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 @@ -971,122 +1011,139 @@ 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 ending it. 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 + active entity always sends its Contact Header first and waits for a + response from the passive entity. The active entity 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 + passive entity accepts one with a corresponding Contact Header reply. + Only upon response of a Contact Header from the passive entity 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 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. + peer. If the active entity receives a Contact Header with a + different protocol version than the one sent earlier on the TCP + connection, the TCP connection SHALL be closed. If the active entity + 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 + If the passive entity 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 + code of "Version mismatch". If the passive 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. 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. + Once established, the lifetime of a TLS session SHALL be bound to the + lifetime of the underlying TCP connection. Immediately prior to + actively ending a TLS session after TCPCL session termination, the + peer which sent the original (non-reply) SESS_TERM message SHOULD + follow the Closure Alert procedure of [RFC5246] to cleanly terminate + the TLS session. Because each TCPCL message is either fixed-length + or self-indicates its length, the lack of a TLS Closure Alert will + not cause data truncation or corruption. + + Subsequent TCPCL session attempts to the same passive entity MAY + attempt use the TLS session resumption feature. There is no + guarantee that the passive entity will accept the request to resume a + TLS session, and the active entity cannot assume any resumption + outcome. + 4.4.1. TLS Handshake - The use of TLS is negotated using the Contact Header as described in + The use of TLS is negotiated 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 TLS 1.2 [RFC5246] or any successors that are compatible with TLS 1.2. 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. 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. Within each TLS handshake, the following requirements apply (using the rough order in which they occur): Client Hello: When a resolved host name was used to establish the TCP connection, the TLS ClientHello SHOULD include a Server Name - Indication (SNI) from the active peer in accordance with + Indication (SNI) from the active entity in accordance with [RFC6066]. When present, the SNI SHALL contain the same host name - used to establish the TCP connection. + used to establish the TCP connection. Note: The SNI text is the + network-layer name for the passive entity, which is not the Node + ID of that entity. - Server Certificate: The passive peer SHOULD supply a certificate + Server Certificate: The passive entity SHALL supply a certificate within the TLS handshake to allow authentication of its side of the session. When assigned a stable host name or address, the - passive peer certificate SHOULD contain a subjectAltName entry - which authenticates that host name or address. The passive peer + passive entity certificate SHOULD contain a subjectAltName entry + which authenticates that host name or address. The passive entity certificate SHOULD contain a subjectAltName entry of type uniformResourceIdentifier which authenticates the Node ID of the - peer. The passive peer MAY use the SNI host name to choose an + peer. The passive entity MAY use the SNI host name to choose an appropriate server-side certificate which authenticates that host name and corresponding Node ID. - Certificate Request: During TLS handshake, the passive peer SHALL + Certificate Request: During TLS handshake, the passive entity SHALL request a client-side certificate. - Client Certificate: The active peer SHOULD supply a certificate + Client Certificate: The active entity SHALL supply a certificate chain within the TLS handshake to allow authentication of its side of the session. When assigned a stable host name or address, the - active peer certificate SHOULD contain a subjectAltName entry - which authenticates that host name or address. The active peer + active entity certificate SHOULD contain a subjectAltName entry + which authenticates that host name or address. The active entity certificate SHOULD contain a subjectAltName entry of type uniformResourceIdentifier which authenticates the Node ID of the peer. 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 + After a TLS session is successfully established, the active entity SHALL send a SESS_INIT message to begin session negotiation. This - session negotation and all subsequent messaging are secured. + session negotiation and all subsequent messaging are secured. 4.4.2. TLS Authentication Using X.509 certificates exchanged during the TLS handshake, each of the entities can attempt to authenticate its peer at the network layer (host name and address) and at the application layer (BP Node ID). The Node ID exchanged in the Session Initialization is likely to be used by the BP agent for making transfer and routing decisions, so attempting host name validation is optional while attempting Node ID validation is required. The logic for attempting validation is @@ -1098,93 +1155,99 @@ distinct Node IDs. When this "virtual host" behavior is used, the host name is used as the indication of which BP Node the passive entity is attempting to communicate with. A virtual host CL entity can be authenticated by a certificate containing all of the host names and/or Node IDs being hosted or by several certificates each authenticating a single host name and/or Node ID. Any certificate received during TLS handshake SHALL be validated up to one or more trusted certificate authority (CA) certificates. If certificate validation fails or if security policy disallows a - certificate for any reason, the entity SHOULD terminate the session + certificate for any reason, the entity SHALL terminate the session (with a reason code of "Contact Failure"). - Immediately after the TLS handshake, each side of the TCP connection - SHOULD perform host name validation of its peer in accordance with - [RFC6125] unless it is not needed by security policy. The active - peer SHALL attempt to authenticate the host name (of the passive - peer) used to initiate the TCP connection. The active peer MAY - attempt to authenticate the IP address of the other side of the TCP - connection. The passive peer SHALL attempt to authenticate the IP - address of the other side of the TCP connection. The passive peer - MAY use the IP address to resolve one or more host names of the - active peer and attempt to authenticate those. If host name - 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. + Either during or immediately after the TLS handshake, each side of + the TCP connection SHOULD perform host name validation of its peer in + accordance with [RFC6125] unless it is not needed by security policy. + The active entity SHALL attempt to authenticate the host name (of the + passive entity) used to initiate the TCP connection. The active + entity MAY attempt to authenticate the IP address of the other side + of the TCP connection. The passive entity SHALL attempt to + authenticate the IP address of the other side of the TCP connection. + The passive entity MAY use the IP address to resolve one or more host + names of the active entity and attempt to authenticate those. If + host name validation fails (including failure because the certificate + does not contain any DNS-ID) and security policy disallows an + unauthticated host, the entity SHALL terminate the session (with a + reason code of "Contact Failure"). 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. 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. + contain any subjectAltName URI) and security policy disallows an + unauthticated Node ID, the entity SHALL terminate the session (with a + reason code of "Contact Failure"). 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 +-------------------------+ - | Open TCP Connnection | -> - +-------------------------+ +-------------------------+ - <- | Accept Connection | + | Open TCP Connnection | -> +-------------------------+ + +-------------------------+ <- | Accept Connection | +-------------------------+ - +-------------------------+ - | Contact Header | -> - +-------------------------+ +-------------------------+ - <- | Contact Header | + | Contact Header | -> +-------------------------+ + +-------------------------+ <- | Contact Header | +-------------------------+ +-------------------------+ +-------------------------+ | TLS Negotiation | -> <- | TLS Negotiation | | (as client) | | (as server) | +-------------------------+ +-------------------------+ Host name validation occurs. Secured TCPCL messaging can begin. - +-------------------------+ +-------------------------+ - | SESS_INIT | -> <- | SESS_INIT | - +-------------------------+ +-------------------------+ + +-------------------------+ + | SESS_INIT | -> +-------------------------+ + +-------------------------+ <- | SESS_INIT | + +-------------------------+ Node ID validation occurs. Session is established, transfers can begin. + +-------------------------+ + | SESS_TERM | -> +-------------------------+ + +-------------------------+ <- | SESS_TERM | + +-------------------------+ + +-------------------------+ + | TLS Closure Alert | -> +-------------------------+ + +-------------------------+ <- | TLS Closure Alert | + +-------------------------+ +-------------------------+ +-------------------------+ - | SESS_TERM | -> <- | SESS_TERM | + | TCP Close | -> <- | TCP Close | +-------------------------+ +-------------------------+ Figure 17: A simple visual example of TCPCL TLS Establishment between two entities 4.5. Message Header After the initial exchange of a contact header, all messages transmitted over the session are identified by a one-octet header with the following structure: @@ -1197,44 +1260,49 @@ Figure 18: Format of the Message Header The message header fields are as follows: Message Type: Indicates the type of the message as per Table 2 below. Encoded values are listed in Section 9.5. +--------------+------+---------------------------------------------+ | Name | Code | Description | +--------------+------+---------------------------------------------+ - | SESS_INIT | 0x07 | Contains the session parameter inputs from | - | | | one of the entities, as described in | - | | | Section 4.6. | + | SESS_INIT | 0x07 | Contains the session parameter | + | | | inputs from one of the entities, | + | | | as described in Section 4.6. | | | | | - | SESS_TERM | 0x05 | Indicates that one of the entities | - | | | participating in the session wishes to | - | | | cleanly terminate the session, as described | - | | | in Section 6. | + | SESS_TERM | 0x05 | Indicates that one of the | + | | | entities participating in the session | + | | | wishes to cleanly terminate the session, as | + | | | described in Section 6. | | | | | - | XFER_SEGMENT | 0x01 | Indicates the transmission of a segment of | - | | | bundle data, as described in Section 5.2.2. | + | XFER_SEGMENT | 0x01 | Indicates the transmission of | + | | | a segment of bundle data, as described in | + | | | Section 5.2.2. | | | | | - | XFER_ACK | 0x02 | Acknowledges reception of a data segment, | - | | | as described in Section 5.2.3. | + | XFER_ACK | 0x02 | Acknowledges reception of a | + | | | data segment, as described in | + | | | Section 5.2.3. | | | | | - | XFER_REFUSE | 0x03 | Indicates that the transmission of the | - | | | current bundle SHALL be stopped, as | - | | | described in Section 5.2.4. | + | XFER_REFUSE | 0x03 | Indicates that the | + | | | transmission of the current bundle SHALL be | + | | | stopped, as described in | + | | | Section 5.2.4. | | | | | - | KEEPALIVE | 0x04 | Used to keep TCPCL session active, as | - | | | described in Section 5.1.1. | + | KEEPALIVE | 0x04 | Used to keep TCPCL session | + | | | active, as described in Section | + | | | 5.1.1. | | | | | - | MSG_REJECT | 0x06 | Contains a TCPCL message rejection, as | - | | | described in Section 5.1.2. | + | MSG_REJECT | 0x06 | Contains a TCPCL message | + | | | rejection, as described in | + | | | Section 5.1.2. | +--------------+------+---------------------------------------------+ Table 2: TCPCL Message Types 4.6. Session Initialization Message (SESS_INIT) Before a session is established and ready to transfer bundles, the session parameters are negotiated between the connected entities. The SESS_INIT message is used to convey the per-entity parameters which are used together to negotiate the per-session parameters as @@ -1294,57 +1362,61 @@ to follow. A zero-length Node ID SHALL be used to indicate the lack of Node ID rather than a truly empty Node ID. This case allows an entity to avoid exposing Node ID information on an untrusted network. A non-zero-length Node ID Data SHALL contain the UTF-8 encoded Node ID of the Entity which sent the SESS_INIT message. Every Node ID SHALL be a URI consistent with the requirements of [RFC3986] and the URI schemes of [I-D.ietf-dtn-bpbis]. The Node ID itself can be authenticated as described in Section 4.4.2. - Session Extension Length and Session Extension Items: Together these - fields represent protocol extension data not defined by this - specification. The Session Extension Length is the total number - of octets to follow which are used to encode the Session Extension - Item list. The encoding of each Session Extension Item is within - a consistent data container as described in Section 4.8. The full - set of Session Extension Items apply for the duration of the TCPCL - session to follow. The order and mulitplicity of these Session - Extension Items MAY be significant, as defined in the associated - type specification(s). + Session Extension Length and Session Extension Items: + Together these fields represent protocol extension data not + defined by this specification. The Session Extension Length is + the total number of octets to follow which are used to encode the + Session Extension Item list. The encoding of each Session + Extension Item is within a consistent data container as described + in Section 4.8. The full set of Session Extension Items apply for + the duration of the TCPCL session to follow. The order and + mulitplicity of these Session Extension Items MAY be significant, + as defined in the associated type specification(s). 4.7. Session Parameter Negotiation An entity calculates the parameters for a TCPCL session by negotiating the values from its own preferences (conveyed by the contact header it sent to the peer) with the preferences of the peer node (expressed in the contact header that it received from the peer). The negotiated parameters defined by this specification are described in the following paragraphs. Transfer MTU and Segment MTU: The maximum transmit unit (MTU) for whole transfers and individual segments are idententical to the Transfer MRU and Segment MRU, respectively, of the recevied contact header. A transmitting peer can send individual segments with any size smaller than the Segment MTU, depending on local policy, dynamic network conditions, etc. Determining the size of - each transmitted segment is an implementation matter. + each transmitted segment is an implementation matter. If the + either Transfer MRU or Segment MRU is unacceptable, the node SHALL + terminate the session with a reason code of "Contact Failure". Session Keepalive: Negotiation of the Session Keepalive parameter is performed by taking the minimum of this two contact headers' Keepalive Interval. The Session Keepalive interval is a parameter - for the behavior described in Section 5.1.1. + for the behavior described in Section 5.1.1. If the Session + Keepalive interval is unacceptable, the node SHALL terminate the + session with a reason code of "Contact Failure". Enable TLS: Negotiation of the Enable TLS parameter is performed by taking the logical AND of the two contact headers' CAN_TLS flags. A local security policy is then applied to determine of the - negotated value of Enable TLS is acceptable. It can be a + negotiated value of Enable TLS is acceptable. It can be a reasonable security policy to both require or disallow the use of TLS depending upon the desired network flows. Because this state is negotiated over an unsecured medium, there is a risk of a TLS Stripping as described in Section 8. If the Enable TLS state is unacceptable, the node SHALL terminate the session with a reason code of "Contact Failure". Note that this contact failure reason is different than a failure of TLS handshake or TLS authentication after an agreed-upon and acceptable Enable TLS state. If the negotiated Enable TLS value is true and acceptable then TLS negotiation feature (described in Section 4.4) begins immediately @@ -1481,47 +1552,48 @@ Reason Code: A one-octet refusal reason code interpreted according to the descriptions in Table 4. Rejected Message Header: The Rejected Message Header is a copy of the Message Header to which the MSG_REJECT message is sent as a response. +-------------+------+----------------------------------------------+ | Name | Code | Description | +-------------+------+----------------------------------------------+ - | Message | 0x01 | A message was received with a Message Type | - | Type | | code unknown to the TCPCL node. | + | Message | 0x01 | A message was received with a | + | Type | | Message Type code unknown to the TCPCL node. | | Unknown | | | | | | | - | Message | 0x02 | A message was received but the TCPCL node | - | Unsupported | | cannot comply with the message contents. | + | Message | 0x02 | A message was received but the | + | Unsupported | | TCPCL node cannot comply with the message | + | | | contents. | | | | | - | Message | 0x03 | A message was received while the session is | - | Unexpected | | in a state in which the message is not | - | | | expected. | + | Message | 0x03 | A message was received while the | + | Unexpected | | session is in a state in which the message | + | | | is not expected. | +-------------+------+----------------------------------------------+ Table 4: MSG_REJECT Reason Codes 5.2. Bundle Transfer 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 is indicated by + receiving node's maximum receive unit (MRU) (see the field Segment + 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. @@ -1579,22 +1651,22 @@ 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 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 + 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 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). @@ -2013,147 +2085,258 @@ An example implementation of the this draft of TCPCLv4 has been created as a GitHub project [github-dtn-bpbis-tcpcl] and is intented to use as a proof-of-concept and as a possible source of interoperability testing. This example implementation uses D-Bus as the CL-BP Agent interface, so it only runs on hosts which provide the Python "dbus" library. 8. Security Considerations + This section separates security considerations into threat categories + based on guidance of BCP 72 [RFC3552]. + +8.1. Threat: Passive Leak of Node Data + + When used without TLS security, the TCPCL exposes the Node ID and + other configuration data to passive eavesdroppers. This occurs even + when no transfers occur within a TCPCL session. This can be avoided + by always using TLS, even if authentication is not available (see + Section 8.10). + +8.2. Threat: Passive Leak of Bundle Data + 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 - 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. + When used without TLS security, the TCPCL exposes all bundle data to + passive eavesdroppers. This can be avoided by always using TLS, even + if authentication is not available (see Section 8.10). + +8.3. Threat: TCPCL Version Downgrade + + When a TCPCL entity supports multiple versions of the protocol it is + possible for a malicious or misconfigued peer to use an older version + of TCPCL which does not support transport security. It is up to + security policies within each TCPCL node to ensure that the TCPCL + version in use meets transport security requirements. + +8.4. Threat: Transport Security Stripping + + When security policy allows non-TLS sessions, TCPCL does not protect + against active network attackers. It is possible for a man-in-the- + middle attacker to set the CAN_TLS flag to 0 on either side of the + Contact Header exchange. This leads to the "SSL Stripping" attack + described in [RFC7457]. + + The purpose of the CAN_TLS flag is to allow the use of TCPCL on + entities which simply do not have a TLS implementation available. + When TLS is available on an entity, it is strongly encouraged that + the security policy disallow non-TLS sessions. This requires that + the TLS handshake occurs, regardless of the policy-driven parameters + of the handshake and policy-driven handling of the handshake outcome. + + The negotiated use of TLS is identical behavior to STARTTLS use in + [RFC2595] and [RFC4511]. + +8.5. Threat: Weak Ciphersuite Downgrade 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 + ciphersuite negotiated between the TLS peers can be insecure. + Recommendations for ciphersuite use are included in BCP 195 + [RFC7525]. 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]. + requirements. + +8.6. Threat: Invalid Certificate Use + + There are many reasons, described in [RFC5280], why a certificate can + fail to validate, including using the certificate outside of its + valid time interval, using purposes for which it was not authorized, + or using it after it has been revoked by its CA. Validating a + certificate is a complex task and may require network connectivity if + a mechanism such as the Online Certificate Status Protocol (OCSP) is + used by the CA. The configuration and use of particular certificate + validation methods are outside of the scope of this document. + +8.7. Threat: Symmetric Key Overuse + + Even with a secure block cipher and securely-established session + keys, there are limits to the amount of plaintext which can be safely + encrypted with a given set of keys as described in [AEAD-LIMITS]. + When permitted by the negotiated TLS version (see [RFC8446]), it is + advisable to take advantage of session key updates to avoid those + limits. When key updates are not possible, establishing new TCPCL/ + TLS session is an alternative to limit session key use. + +8.8. Threat: BP Node Impersonation The certificates exchanged by TLS enable authentication of peer host name and Node ID, but it is possible that a peer either not provide a valid certificate or that the certificate does not validate either the host name or Node ID of the peer. Having a CA-validated certificate does not alone guarantee the identity of the network host or BP node from which the certificate is provided; additional - validation procedures bind the host name or node ID based on the - contents of the certificate. The host name validation is a weaker - form of authentication, because even if a peer is operating on an - authenticated network host name it can provide an invalid Node ID and - cause bundles to be "leaked" to an invalid node. Especially in DTN - environments, network names and addresses of nodes can be time- - variable so binding a certificate to a Node ID is a more stable - identity. Node ID validation ensures that the peer to which a bundle - is transferred is in fact the node which the BP Agent expects it to - be. It is a reasonable policy to skip host name validation if + validation procedures in Section 4.4.1 bind the host name or node ID + based on the contents of the certificate. + + The host name validation is a weaker form of authentication, because + even if a peer is operating on an authenticated network host name it + can provide an invalid Node ID and cause bundles to be "leaked" to an + invalid node. Especially in DTN environments, network names and + addresses of nodes can be time-variable so binding a certificate to a + Node ID is a more stable identity. Trusting an authenticated host + name can be feasable on a network secured by a private CA but is not + advisable on the Internet when using a variety of public CAs. + + Node ID validation ensures that the peer to which a bundle is + transferred is in fact the node which the BP Agent expects it to be. + It is a reasonable policy to skip host name validation if certificates can be guaranteed to validate the peer's Node ID. In circumstances where certificates can only be issued to network host names, Node ID validation is not possible but it could be reasonable to assume that a trusted host is not going to present an invalid Node - ID. Trusting an authenticated host name can be feasable on a network - secured by a private CA but is not advisable on the Internet when - using a variety of public CAs. + ID. - Another consideration for this protocol relates to denial-of-service - attacks. An entity MAY send a large amount of data over a TCPCL - session, requiring the receiving entity to handle the data, attempt - to stop the flood of data by sending a XFER_REFUSE message, or - forcibly terminate the session. This burden could cause denial of - service on other, well-behaving sessions. There is also nothing to - prevent a malicious entity from continually establishing sessions and - repeatedly trying to send copious amounts of bundle data. A - listening entity MAY take countermeasures such as ignoring TCP SYN - messages, closing TCP connections as soon as they are established, - waiting before sending the contact header, sending a SESS_TERM - message quickly or with a delay, etc. +8.9. Threat: Denial of Service + + The behaviors described in this section all amount to a potential + denial-of-service to a TCPCL entity. The denial-of-service could be + limited to an individual TCPCL session, could affect other well- + behaving sessions on an entity, or could affect all sessions on a + host. + + A malicious entity can continually establish TCPCL sessions and delay + sending of protocol-required data to trigger timeouts. The victim + entity can block TCP connections from network peers which are thought + to be incorrectly behaving within TCPCL. + + An entity can send a large amount of data over a TCPCL session, + requiring the receiving entity to handle the data. The victim entity + can attempt to stop the flood of data by sending an XFER_REFUSE + message, or forcibly terminate the session. + + There is the possibility of a "data dribble" attack in which an + entity presents a very small Segment MRU which causes transfers to be + split among an large number of very small segments and causes the + segmentation overhead to overwhelm the network througput. Similarly, + an entity can present a very small Transfer MRU which will cause + resources to be wasted on establishing and upkeeping a TCPCL session + over which a bundle could never be transferred. The victim entity + can terminate the session during the negotiation of Section 4.7 if + the MRUs are unacceptable. + + The keepalive mechanism can be abused to waste throughput within a + network link which would otherwise be usable for bundle + transmissions. Due to the quantization of the Keepalive Interval + parameter the smallest Session Keepalive is one second, which should + be long enough to not flood the link. The victim entity can + terminate the session during the negotiation of Section 4.7 if the + Keepalive Interval is unacceptable. + +8.10. Alternate Uses of TLS + + This specification makes use of public key infrastructure (PKI) + certificate validation and authentication within TLS. There are + alternate uses of TLS which are not necessarily incompatible with the + security goals of this specification, but are outside of the scope of + this document. + +8.10.1. TLS Without Authentication + + In environments where PKI is available but there are restrictions on + the issuance of certificates (including the contents of + certificates), it may be possible to make use of TLS in a way which + authenticates only the passive entity of a TCPCL session or which + does not authenticate either entity. Using TLS in a way which does + not authenticate both peer entities of each TCPCL session is outside + of the scope of this document. + +8.10.2. Non-Certificate TLS Use + + In environments where PKI is unavailable, alternate uses of TLS which + do not require certificates such as [RFC5489] are available and can + be used to ensure confidentality within TCPCL. Using non-PKI node + authentication methods is outside of the scope of this document. 9. IANA Considerations Registration procedures referred to in this section are defined in [RFC8126]. Some of the registries have been defined as version specific to TCPCLv4, and imports some or all codepoints from TCPCLv3. This was done to disambiguate the use of these codepoints between TCPCLv3 and TCPCLv4 while preserving the semantics of some of the codepoints. 9.1. Port Number - Port number 4556 has been previously assigned as the default port for - the TCP convergence layer in [RFC7242]. This assignment is unchanged - by protocol version 4. Each TCPCL entity identifies its TCPCL - protocol version in its initial contact (see Section 9.2), so there - is no ambiguity about what protocol is being used. + Within the port registry of [IANA-PORTS], TCP port number 4556 has + been previously assigned as the default port for the TCP convergence + layer in [RFC7242]. This assignment is unchanged by TCPCL version 4, + but the assignment reference is updated to this specification. Each + TCPCL entity identifies its TCPCL protocol version in its initial + contact (see Section 9.2), so there is no ambiguity about what + protocol is being used. The related assignments for UDP and DCCP + port 4556 (both registered by [RFC7122]) are unchanged. - +------------------------+-------------------------------------+ + +------------------------+----------------------------------+ | Parameter | Value | - +------------------------+-------------------------------------+ + +------------------------+----------------------------------+ | Service Name: | dtn-bundle | | | | | Transport Protocol(s): | TCP | | | | - | Assignee: | Simon Perreault | + | Assignee: | Brian Sipos | | | | - | Contact: | Simon Perreault | + | Contact: | Brian Sipos | | | | | Description: | DTN Bundle TCP CL Protocol | | | | - | Reference: | [RFC7242] | + | Reference: | This specification. | | | | | Port Number: | 4556 | - +------------------------+-------------------------------------+ + +------------------------+----------------------------------+ 9.2. Protocol Versions - IANA has created, under the "Bundle Protocol" registry, a sub- - registry titled "Bundle Protocol TCP Convergence-Layer Version - Numbers" and initialize it with the following table. The - registration procedure is RFC Required. + IANA has created, under the "Bundle Protocol" registry [IANA-BUNDLE], + a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version + Numbers". The version number table is updated to include this + specification. The registration procedure is RFC Required. - +-------+-------------+---------------------+ + +-------+-------------+-----------------------------------+ | Value | Description | Reference | - +-------+-------------+---------------------+ + +-------+-------------+-----------------------------------+ | 0 | Reserved | [RFC7242] | | | | | | 1 | Reserved | [RFC7242] | | | | | | 2 | Reserved | [RFC7242] | | | | | | 3 | TCPCL | [RFC7242] | | | | | | 4 | TCPCLv4 | This specification. | | | | | | 5-255 | Unassigned | - +-------+-------------+---------------------+ + +-------+-------------+-----------------------------------+ 9.3. Session Extension Types 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 - Session Extension Types" and initialize it with the contents of + IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], + 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 @@ -2173,23 +2356,23 @@ | 0x8000--0xFFFF | Private/Experimental Use | +----------------+--------------------------+ Table 10: Session Extension Type Codes 9.4. Transfer Extension Types 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 - Transfer Extension Types" and initialize it with the contents of + IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], + 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 @@ -2211,26 +2394,26 @@ | 0x8000--0xFFFF | Private/Experimental Use | +----------------+---------------------------+ Table 11: Transfer Extension Type Codes 9.5. Message Types 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. + IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], + 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. The use of new message types need to be negotiated between TCPCL entities within a session (using the session extension mechanism) so that the receving entity can properly decode all message types used in the session. Expert(s) are encouraged to favor new session/transfer extension @@ -2264,23 +2447,23 @@ | 0xF0--0xFF | Private/Experimental Use | +------------+--------------------------+ Table 12: Message Type Codes 9.6. XFER_REFUSE Reason Codes 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 - XFER_REFUSE Reason Codes" and initialize it with the contents of + IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], + 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. @@ -2306,23 +2489,23 @@ | 0xF0--0xFF | Private/Experimental Use | +------------+--------------------------+ Table 13: XFER_REFUSE Reason Codes 9.7. SESS_TERM Reason Codes 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 - SESS_TERM Reason Codes" and initialize it with the contents of + IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], + 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. @@ -2350,23 +2533,23 @@ | 0xF0--0xFF | Private/Experimental Use | +------------+--------------------------+ Table 14: 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- - registry titled "Bundle Protocol TCP Convergence-Layer Version 4 - MSG_REJECT Reason Codes" and initialize it with the contents of + IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], + 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. @@ -2396,22 +2579,31 @@ This specification is based on comments on implementation of [RFC7242] provided from Scott Burleigh. 11. References 11.1. Normative References [I-D.ietf-dtn-bpbis] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol - Version 7", draft-ietf-dtn-bpbis-14 (work in progress), - August 2019. + Version 7", draft-ietf-dtn-bpbis-17 (work in progress), + October 2019. + + [IANA-BUNDLE] + IANA, "Bundle Protocol", + . + + [IANA-PORTS] + IANA, "Service Name and Transport Protocol Port Number + Registry", . [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, . @@ -2456,46 +2648,80 @@ [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + 11.2. Informative References + [AEAD-LIMITS] + Luykx, A. and K. Paterson, "Limits on Authenticated + Encryption Use in TLS", August 2017, + . + [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-12 (work in progress), September 2019. [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999, . + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, + DOI 10.17487/RFC3552, July 2003, + . + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, + DOI 10.17487/RFC4511, June 2006, + . + [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, . + [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for + Transport Layer Security (TLS)", RFC 5489, + DOI 10.17487/RFC5489, March 2009, + . + + [RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram + Convergence Layers for the Delay- and Disruption-Tolerant + Networking (DTN) Bundle Protocol and Licklider + Transmission Protocol (LTP)", RFC 7122, + DOI 10.17487/RFC7122, March 2014, + . + [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol", RFC 7242, DOI 10.17487/RFC7242, June 2014, . + [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection + Most of the Time", RFC 7435, DOI 10.17487/RFC7435, + December 2014, . + [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, .