draft-ietf-dtn-tcpclv4-15.txt   draft-ietf-dtn-tcpclv4-16.txt 
Delay Tolerant Networking B. Sipos Delay Tolerant Networking B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Obsoletes: 7242 (if approved) M. Demmer Obsoletes: 7242 (if approved) M. Demmer
Intended status: Standards Track UC Berkeley Intended status: Standards Track UC Berkeley
Expires: April 18, 2020 J. Ott Expires: May 25, 2020 J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
October 16, 2019 November 22, 2019
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-15 draft-ietf-dtn-tcpclv4-16
Abstract Abstract
This document describes a revised protocol for the TCP-based This document describes a revised protocol for the TCP-based
convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The
protocol revision is based on implementation issues in the original protocol revision is based on implementation issues in the original
TCPCL Version 3 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 contents, encodings, and convergence layer requirements in Bundle
Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7
bundles as its service data unit being transported and provides a bundles as its service data unit being transported and provides a
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2020. This Internet-Draft will expire on May 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 5 2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 5
3. General Protocol Description . . . . . . . . . . . . . . . . 8 3. General Protocol Description . . . . . . . . . . . . . . . . 8
3.1. Convergence Layer Services . . . . . . . . . . . . . . . 8 3.1. Convergence Layer Services . . . . . . . . . . . . . . . 8
3.2. TCPCL Session Overview . . . . . . . . . . . . . . . . . 10 3.2. TCPCL Session Overview . . . . . . . . . . . . . . . . . 10
3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 12 3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 12
3.4. Transfer Segmentation Policies . . . . . . . . . . . . . 18 3.4. Transfer Segmentation Policies . . . . . . . . . . . . . 18
3.5. Example Message Exchange . . . . . . . . . . . . . . . . 19 3.5. Example Message Exchange . . . . . . . . . . . . . . . . 19
4. Session Establishment . . . . . . . . . . . . . . . . . . . . 21 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 20
4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 21 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 21
4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 22 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 22
4.3. Contact Validation and Negotiation . . . . . . . . . . . 23 4.3. Contact Validation and Negotiation . . . . . . . . . . . 23
4.4. Session Security . . . . . . . . . . . . . . . . . . . . 24 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 24
4.4.1. TLS Handshake . . . . . . . . . . . . . . . . . . . . 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.4.3. Example TLS Initiation . . . . . . . . . . . . . . . 27
4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 27 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 28
4.6. Session Initialization Message (SESS_INIT) . . . . . . . 28 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 30
4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 30 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 31
4.8. Session Extension Items . . . . . . . . . . . . . . . . . 31 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 32
5. Established Session Operation . . . . . . . . . . . . . . . . 32 5. Established Session Operation . . . . . . . . . . . . . . . . 33
5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 32 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 33
5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 32 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 34
5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 33 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 34
5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 34 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 35
5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 35 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 36
5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 35 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 36
5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 37 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 38
5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 38 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 39
5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 41 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 42
6. Session Termination . . . . . . . . . . . . . . . . . . . . . 43 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 44
6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 43 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 44
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 45 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 46
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 45 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 46
8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 47
9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 47 8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 47
9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 48 8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 47
9.3. Session Extension Types . . . . . . . . . . . . . . . . . 48 8.4. Threat: Transport Security Stripping . . . . . . . . . . 47
9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 49 8.5. Threat: Weak Ciphersuite Downgrade . . . . . . . . . . . 48
9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 50 8.6. Threat: Invalid Certificate Use . . . . . . . . . . . . . 48
9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 51 8.7. Threat: Symmetric Key Overuse . . . . . . . . . . . . . . 48
9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 52 8.8. Threat: BP Node Impersonation . . . . . . . . . . . . . . 48
9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 53 8.9. Threat: Denial of Service . . . . . . . . . . . . . . . . 49
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 8.10. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 50
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 8.10.1. TLS Without Authentication . . . . . . . . . . . . . 50
11.1. Normative References . . . . . . . . . . . . . . . . . . 54 8.10.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 50
11.2. Informative References . . . . . . . . . . . . . . . . . 55 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 56 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 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 1. Introduction
This document describes the TCP-based convergence-layer protocol for This document describes the TCP-based convergence-layer protocol for
Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to-
end architecture providing communications in and/or through highly end architecture providing communications in and/or through highly
stressed environments, including those with intermittent stressed environments, including those with intermittent
connectivity, long and/or variable delays, and high bit error rates. connectivity, long and/or variable delays, and high bit error rates.
More detailed descriptions of the rationale and capabilities of these More detailed descriptions of the rationale and capabilities of these
networks can be found in "Delay-Tolerant Network Architecture" networks can be found in "Delay-Tolerant Network Architecture"
skipping to change at page 4, line 46 skipping to change at page 5, line 10
(peers) within a network or across an internet. The mapping of (peers) within a network or across an internet. The mapping of
Node ID to potential CL protocol and network address is left to Node ID to potential CL protocol and network address is left to
implementation and configuration of the BP Agent and its various implementation and configuration of the BP Agent and its various
potential routing strategies. potential routing strategies.
o Logic for routing bundles along a path toward a bundle's endpoint. o Logic for routing bundles along a path toward a bundle's endpoint.
This CL protocol is involved only in transporting bundles between This CL protocol is involved only in transporting bundles between
adjacent nodes in a routing sequence. adjacent nodes in a routing sequence.
o Policies or mechanisms for assigning X.509 certificates, o Policies or mechanisms for assigning X.509 certificates,
provisioning or deploying certificates and private keys, or provisioning, deploying, or accessing certificates and private
configuring security parameters on an individual BP node or across keys, deploying or accessing certificate revocation lists (CRLs),
a network. 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 Any TCPCL implementation requires a BP agent to perform those above
listed functions in order to perform end-to-end bundle delivery. listed functions in order to perform end-to-end bundle delivery.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
skipping to change at page 5, line 47 skipping to change at page 6, line 15
These relationships are illustrated in Figure 2. For most TCPCL These relationships are illustrated in Figure 2. For most TCPCL
behavior within a session, the two entities are symmetric and behavior within a session, the two entities are symmetric and
there is no protocol distinction between them. Some specific there is no protocol distinction between them. Some specific
behavior, particularly during session establishment, distinguishes behavior, particularly during session establishment, distinguishes
between the active entity and the passive entity. For the between the active entity and the passive entity. For the
remainder of this document, the term "entity" without the prefix remainder of this document, the term "entity" without the prefix
"TCPCL" refers to a TCPCL entity. "TCPCL" refers to a TCPCL entity.
TCP Connection: The term Connection in this specification TCP Connection: The term Connection in this specification
exclusively refers to a TCP connection and any and all behaviors, 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 Session: A TCPCL session (as opposed to a TCP connection) is a
TCPCL communication relationship between two TCPCL entities. TCPCL communication relationship between two TCPCL entities.
Within a single TCPCL session there are two possible transfer Within a single TCPCL session there are two possible transfer
streams; one in each direction, with one stream from each entity streams; one in each direction, with one stream from each entity
being the outbound stream and the other being the inbound stream. being the outbound stream and the other being the inbound stream.
The lifetime of a TCPCL session is bound to the lifetime of an The lifetime of a TCPCL session is bound to the lifetime of an
underlying TCP connection. A TCPCL session is terminated when the underlying TCP connection. A TCPCL session is terminated when the
TCP connection ends, due either to one or both entities actively TCP connection ends, due either to one or both entities actively
closing the TCP connection or due to network errors causing a closing the TCP connection or due to network errors causing a
skipping to change at page 8, line 6 skipping to change at page 8, line 6
| | | | | | | | | | | |
| | +---------------------------------+ | | | | | | +---------------------------------+ | | | |
| +--->| Passively Inititated Session #n +-------->| | | | +--->| Passively Inititated Session #n +-------->| | |
| +---------------------------------+ | +----------------+ | | +---------------------------------+ | +----------------+ |
| | +-----------------+ | | +-----------------+
+--------------------------------------------+ +--------------------------------------------+
Figure 2: The relationships between TCPCL entities Figure 2: The relationships between TCPCL entities
+----------------------------+ +--------------------------+ +----------------------------+ +--------------------------+
| TCPCL Session | | TCPCL "Other" Session | | "Own" TCPCL Session | | "Other" TCPCL Session |
| | | | | | | |
| +-----------------------+ | | +---------------------+ | | +-----------------------+ | | +---------------------+ |
| | TCP Connection | | | | TCP Connection | | | | TCP Connection | | | | TCP Connection | |
| | | | | | | | | | | | | | | |
| | +-------------------+ | | | | +-----------------+ | | | | +-------------------+ | | | | +-----------------+ | |
| | | Optional Inbound | | | | | | Peer Outbound | | | | | | Optional Inbound | | | | | | Peer Outbound | | |
| | | Transfer Stream |<-[Seg]--[Seg]--[Seg]-| | Transfer Stream | | | | | | Transfer Stream |<-[Seg]--[Seg]--[Seg]-| | Transfer Stream | | |
| | | ----- | | | | | | ----- | | | | | | ----- |--[Ack]----[Ack]------->| ----- | | |
| | | RECEIVER | | | | | | SENDER | | | | | | RECEIVER | | | | | | SENDER | | |
| | +-------------------+ | | | | +-----------------+ | | | | +-------------------+ | | | | +-----------------+ | |
| | | | | | | | | | | | | | | |
| | +-------------------+ | | | | +-----------------+ | | | | +-------------------+ | | | | +-----------------+ | |
| | | Optional Outbound | | | | | | Peer Inbound | | | | | | Optional Outbound | | | | | | Peer Inbound | | |
| | | Transfer Stream |------[Seg]---[Seg]---->| Transfer Stream | | | | | | Transfer Stream |------[Seg]---[Seg]---->| Transfer Stream | | |
| | | ----- | | | | | | ----- | | | | | | ----- |<--[Ack]----[Ack]-[Ack]-| ----- | | |
| | | SENDER | | | | | | RECEIVER | | | | | | SENDER | | | | | | RECEIVER | | |
| | +-------------------+ | | | | +-----------------+ | | | | +-------------------+ | | | | +-----------------+ | |
| +-----------------------+ | | +---------------------+ | | +-----------------------+ | | +---------------------+ |
+----------------------------+ +--------------------------+ +----------------------------+ +--------------------------+
Figure 3: The relationship within a TCPCL Session of its two streams Figure 3: The relationship within a TCPCL Session of its two streams
3. General Protocol Description 3. General Protocol Description
The service of this protocol is the transmission of DTN bundles via The service of this protocol is the transmission of DTN bundles via
skipping to change at page 9, line 16 skipping to change at page 9, line 16
terminate an established TCPCL session with a peer entity. The terminate an established TCPCL session with a peer entity. The
terminate request is on a per-session basis. terminate request is on a per-session basis.
Session State Changed: The TCPCL supports indication when the Session State Changed: The TCPCL supports indication when the
session state changes. The top-level session states indicated session state changes. The top-level session states indicated
are: are:
Connecting: A TCP connection is being established. This state Connecting: A TCP connection is being established. This state
only applies to the active entity. 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. 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. (including possible TLS use) and session negotiation has begun.
Established: The session has been fully established and is ready Established: The session has been fully established and is ready
for its first transfer. for its first transfer.
Ending: The entity received a SESS_TERM message and is in the Ending: The entity received a SESS_TERM message and is in the
ending state. ending state.
Terminated: The session has finished normal termination Terminated: The session has finished normal termination
sequencing. sequencing.
skipping to change at page 10, line 6 skipping to change at page 10, line 6
BP agent to transmit bundle data over an established TCPCL BP agent to transmit bundle data over an established TCPCL
session. Transmission request is on a per-session basis, the CL session. Transmission request is on a per-session basis, the CL
does not necessarily perform any per-session or inter-session does not necessarily perform any per-session or inter-session
queueing. Any queueing of transmissions is the obligation of the queueing. Any queueing of transmissions is the obligation of the
BP agent. BP agent.
Transmission Success: The TCPCL supports positive indication when a Transmission Success: The TCPCL supports positive indication when a
bundle has been fully transferred to a peer entity. bundle has been fully transferred to a peer entity.
Transmission Intermediate Progress: The TCPCL supports positive 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 This intermediate progress is at the granularity of each
transferred segment. transferred segment.
Transmission Failure: The TCPCL supports positive indication of Transmission Failure: The TCPCL supports positive indication of
certain reasons for bundle transmission failure, notably when the certain reasons for bundle transmission failure, notably when the
peer entity rejects the bundle or when a TCPCL session ends before 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. transfer timeout.
Reception Initialized: The TCPCL supports indication to the reciver Reception Initialized: The TCPCL supports indication to the reciver
just before any transmssion data is sent. This corresponds to just before any transmssion data is sent. This corresponds to
reception of the XFER_SEGMENT message with the START flag of 1. reception of the XFER_SEGMENT message with the START flag of 1.
Interrupt Reception: The TCPCL allows a BP agent to interrupt an Interrupt Reception: The TCPCL allows a BP agent to interrupt an
individual transfer before it has fully completed (successfully or individual transfer before it has fully completed (successfully or
not). Interruption can occur any time after the reception is not). Interruption can occur any time after the reception is
initialized. initialized.
skipping to change at page 10, line 48 skipping to change at page 10, line 48
rejects an attempted transfer for some local policy reason or when rejects an attempted transfer for some local policy reason or when
a TCPCL session ends before transfer success. The TCPCL itself a TCPCL session ends before transfer success. The TCPCL itself
does not have a notion of transfer timeout. does not have a notion of transfer timeout.
3.2. TCPCL Session Overview 3.2. TCPCL Session Overview
First, one node establishes a TCPCL session to the other by First, one node establishes a TCPCL session to the other by
initiating a TCP connection in accordance with [RFC0793]. After initiating a TCP connection in accordance with [RFC0793]. After
setup of the TCP connection is complete, an initial contact header is setup of the TCP connection is complete, an initial contact header is
exchanged in both directions to establish a shared TCPCL version and exchanged in both directions to establish a shared TCPCL version and
possibly initiate TLS security. Once contact negotiation is negotiate the use of TLS security (as described in Section 4). Once
complete, TCPCL messaging is available and the session negotiation is contact negotiation is complete, TCPCL messaging is available and the
used to set parameters of the TCPCL session. One of these parameters session negotiation is used to set parameters of the TCPCL session.
is a Node ID of each TCPCL Entity. This is used to assist in routing One of these parameters is a Node ID of each TCPCL Entity. This is
and forwarding messages by the BP Agent and is part of the used to assist in routing and forwarding messages by the BP Agent and
authentication capability provided by TLS. is part of the authentication capability provided by TLS.
Once negotiated, the parameters of a TCPCL session cannot change and Once negotiated, the parameters of a TCPCL session cannot change and
if there is a desire by either peer to transfer data under different if there is a desire by either peer to transfer data under different
parameters then a new session must be established. This makes CL parameters then a new session must be established. This makes CL
logic simpler but relies on the assumption that establishing a TCP logic simpler but relies on the assumption that establishing a TCP
connection is lightweight enough that TCP connection overhead is connection is lightweight enough that TCP connection overhead is
negligable compared to TCPCL data sizes. negligable compared to TCPCL data sizes.
Once the TCPCL session is established and configured in this way, Once the TCPCL session is established and configured in this way,
bundles can be transferred in either direction. Each transfer is bundles can be transferred in either direction. Each transfer is
performed by an sequence of logical segments of data within performed by an sequence of logical segments of data within
XFER_SEGMENT messages. Multiple bundles can be transmitted XFER_SEGMENT messages. Multiple bundles can be transmitted
consecutively in a single direction on a single TCPCL connection. consecutively in a single direction on a single TCPCL connection.
Segments from different bundles are never interleaved. Bundle Segments from different bundles are never interleaved. Bundle
interleaving can be accomplished by fragmentation at the BP layer or interleaving can be accomplished by fragmentation at the BP layer or
by establishing multiple TCPCL sessions between the same peers. by establishing multiple TCPCL sessions between the same peers.
There is no fundamental limit on the number of TCPCL sessions which a 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 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 A feature of this protocol is for the receiving node to send
acknowledgment (XFER_ACK) messages as bundle data segments arrive. acknowledgment (XFER_ACK) messages as bundle data segments arrive.
The rationale behind these acknowledgments is to enable the sender The rationale behind these acknowledgments is to enable the sender
node to determine how much of the bundle has been received, so that node to determine how much of the bundle has been received, so that
in case the session is interrupted, it can perform reactive in case the session is interrupted, it can perform reactive
fragmentation to avoid re-sending the already transmitted part of the fragmentation to avoid re-sending the already transmitted part of the
bundle. In addition, there is no explicit flow control on the TCPCL bundle. In addition, there is no explicit flow control on the TCPCL
layer. layer.
skipping to change at page 13, line 28 skipping to change at page 13, line 28
| Negotiated | Negotiated
V V
+-------------+ +-------------+ +-------------+ +-------------+
| Established |----New Transfer---->| Established | | Established |----New Transfer---->| Established |
| Session | | Session | | Session | | Session |
| Idle |<---Transfers Done---| Live | | Idle |<---Transfers Done---| Live |
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
+------------------------------------+ +------------------------------------+
| |
[SESSTERM] Exchange
|
V V
+-------------+ +-------------+
| Established | +-------------+ | Established | +-------------+
| Session |----Transfers------>| TCP | | Session |----Transfers------>| TCP |
| Ending | Done | Terminating | | Ending | Done | Terminating |
+-------------+ +-------------+ +-------------+ +-------------+
| |
+----------TCP Close Message----------+ +----------TCP Close Message----------+
| |
V V
skipping to change at page 14, line 7 skipping to change at page 14, line 5
Notes on Established Session states: Notes on Established Session states:
Session "Live" means transmitting or reeiving over a transfer Session "Live" means transmitting or reeiving over a transfer
stream. stream.
Session "Idle" means no transmission/reception over a transfer Session "Idle" means no transmission/reception over a transfer
stream. stream.
Session "Ending" means no new transfers will be allowed. 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 directions and deriving a negotiated state from the two headers. The
contact negotiation sequencing is performed either as the active or 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 respectively which both share the data validation and analyze final
states of the "[PCH]" activity of Figure 7 and the "[TCPCLOSE]" states of the "[PCH]" activity of Figure 7 and the "[TCPCLOSE]"
activity which indicates TCP connection close. Successful activity which indicates TCP connection close. Successful
negotiation results in one of the Session Initiation "[SI]" 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 | | START |
+-------+ +-------+
| |
TCP Connecting TCP Connecting
V V
+-----------+ +-----------+
| TCP | +---------+ | TCP | +---------+
| Connected |--Send CH-->| Waiting |--Timeout-->[TCPCLOSE] | Connected |--Send CH-->| Waiting |--Timeout-->[TCPCLOSE]
+-----------+ +---------+ +-----------+ +---------+
| |
Recevied CH Recevied CH
V V
[PCH] [PCH]
Figure 5: Contact Initiation as Active peer Figure 5: Contact Initiation as Active Entity
+-----------+ +---------+ +-----------+ +---------+
| TCP |--Wait for-->| Waiting |--Timeout-->[TCPCLOSE] | TCP |--Wait for-->| Waiting |--Timeout-->[TCPCLOSE]
| Connected | CH +---------+ | Connected | CH +---------+
+-----------+ | +-----------+ |
Received CH Received CH
V V
+-----------------+ +-----------------+
| Preparing reply |--Send CH-->[PSI] | Preparing reply |--Send CH-->[PSI]
+-----------------+ +-----------------+
Figure 6: Contact Initiation as Passive peer Figure 6: Contact Initiation as Passive Entity
+-----------+ +-----------+
| Peer CH | | Peer CH |
| available | | available |
+-----------+ +-----------+
| |
Validate and Validate and
Negotiate Negotiate
V V
+------------+ +------------+
skipping to change at page 15, line 27 skipping to change at page 15, line 27
No TLS +----Negotiate---+ | No TLS +----Negotiate---+ |
V TLS | Failure V TLS | Failure
+-----------+ V | +-----------+ V |
| TCPCL | +---------------+ | TCPCL | +---------------+
| Messaging |<--Success--| TLS Finished | | Messaging |<--Success--| TLS Finished |
| Available | +---------------+ | Available | +---------------+
+-----------+ +-----------+
Figure 7: Processing of Contact Header [PCH] 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 (SESS_INIT) message in both directions and deriving a negotiated
state from the two messages. The session negotiation sequencing is state from the two messages. The session negotiation sequencing is
performed either as the active or passive peer, and is illustrated in performed either as the active or passive entity, and is illustrated
Figure 8 and Figure 9 respectively which both share the data in Figure 8 and Figure 9 respectively which both share the data
validation and analyze final states of Figure 10. The validation validation and analyze final states of Figure 10. The validation
here includes certificate validation and authentication when TLS is here includes certificate validation and authentication when TLS is
used for the session. used for the session.
+-----------+ +-----------+
| TCPCL | +---------+ | TCPCL | +---------+
| Messaging |--Send SESS_INIT-->| Waiting |--Timeout-->[SESSTERM] | Messaging |--Send SESS_INIT-->| Waiting |--Timeout-->[ST]
| Available | +---------+ | Available | +---------+
+-----------+ | +-----------+ |
Recevied SESS_INIT Recevied SESS_INIT
| |
V V
[PSI] [PSI]
Figure 8: Session Initiation [SI] as Active peer Figure 8: Session Initiation [SI] as Active Entity
+-----------+ +-----------+
| TCPCL | +---------+ | TCPCL | +---------+
| Messaging |----Wait for ---->| Waiting |--Timeout-->[SESSTERM] | Messaging |----Wait for ---->| Waiting |--Timeout-->[ST]
| Available | SESS_INIT +---------+ | Available | SESS_INIT +---------+
+-----------+ | +-----------+ |
Recevied SESS_INIT Recevied SESS_INIT
| |
+-----------------+ +-----------------+
| Preparing reply |--Send SESS_INIT-->[PSI] | 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 | | Peer SESS_INIT |
| available | | available |
+----------------+ +----------------+
| |
Validate and Validate and
Negotiate Negotiate
V V
+------------+ +------------+
| Negotiated |---Failure--->[SESSTERM] | Negotiated |---Failure--->[ST]
+------------+ +------------+
| |
Success Success
V V
+--------------+ +--------------+
| Established | | Established |
| Session Idle | | Session Idle |
+--------------+ +--------------+
Figure 10: Processing of Session Initiation [PSI] Figure 10: Processing of Session Initiation [PSI]
skipping to change at page 18, line 10 skipping to change at page 18, line 10
either entity, it is the sending of the SESS_TERM message which either entity, it is the sending of the SESS_TERM message which
transitions the session to the ending substate. While a session is transitions the session to the ending substate. While a session is
being terminated only in-progress transfers can be completed and no being terminated only in-progress transfers can be completed and no
new transfers can be started. new transfers can be started.
+-----------+ +---------+ +-----------+ +---------+
| Session |--Send SESS_TERM-->| Session | | Session |--Send SESS_TERM-->| Session |
| Live/Idle | | Ending | | Live/Idle | | Ending |
+-----------+ +---------+ +-----------+ +---------+
Figure 13: Session Termination [SESSTERM] from the Initiator Figure 13: Session Termination [ST] from the Initiator
+-----------+ +---------+ +-----------+ +---------+
| Session |--Send SESS_TERM-->| Session | | Session |--Send SESS_TERM-->| Session |
| Live/Idle | | Ending | | Live/Idle | | Ending |
+-----------+<------+ +---------+ +-----------+<------+ +---------+
| | | |
Receive SESS_TERM | Receive SESS_TERM |
| | | |
+-------------+ +-------------+
Figure 14: Session Termination [SESSTERM] from the Responder Figure 14: Session Termination [ST] from the Responder
3.4. Transfer Segmentation Policies 3.4. Transfer Segmentation Policies
Each TCPCL session allows a negotiated transfer segmentation polcy to Each TCPCL session allows a negotiated transfer segmentation polcy to
be applied in each transfer direction. A receiving node can set the be applied in each transfer direction. A receiving node can set the
Segment MRU in its contact header to determine the largest acceptable Segment MRU in its contact header to determine the largest acceptable
segment size, and a transmitting node can segment a transfer into any segment size, and a transmitting node can segment a transfer into any
sizes smaller than the receiver's Segment MRU. It is a network sizes smaller than the receiver's Segment MRU. It is a network
administration matter to determine an appropriate segmentation policy administration matter to determine an appropriate segmentation policy
for entities operating TCPCL, but guidance given here can be used to for entities operating TCPCL, but guidance given here can be used to
skipping to change at page 19, line 18 skipping to change at page 19, line 18
Dynamic Segmentation: Even after negotiation of a Segment MRU for Dynamic Segmentation: Even after negotiation of a Segment MRU for
each receiving node, the actual transfer segmentation only needs each receiving node, the actual transfer segmentation only needs
to guarantee than any individual segment is no larger than that to guarantee than any individual segment is no larger than that
MRU. In a situation where network "goodput" is dynamic, the MRU. In a situation where network "goodput" is dynamic, the
transfer segmentation size can also be dynamic in order to control transfer segmentation size can also be dynamic in order to control
message transmission duration. message transmission duration.
Many other policies can be established in a TCPCL network between the Many other policies can be established in a TCPCL network between the
two extremes of minimum overhead (large MRU, single-segment) and two extremes of minimum overhead (large MRU, single-segment) and
predictable message sizing (small MRU, highly segmented). Different 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 particular node. Additionally, future header and transfer extension
types can apply further nuance to transfer policies and policy types can apply further nuance to transfer policies and policy
negotiation. negotiation.
3.5. Example Message Exchange 3.5. Example Message Exchange
The following figure depicts the protocol exchange for a simple The following figure depicts the protocol exchange for a simple
session, showing the session establishment and the transmission of a session, showing the session establishment and the transmission of a
single bundle split into three data segments (of lengths "L1", "L2", single bundle split into three data segments (of lengths "L1", "L2",
and "L3") from Entity A to Entity B. and "L3") from Entity A to Entity B.
skipping to change at page 20, line 8 skipping to change at page 19, line 44
also possible to pipeline multiple XFER_SEGMENT messages for also possible to pipeline multiple XFER_SEGMENT messages for
different bundles without necessarily waiting for XFER_ACK messages different bundles without necessarily waiting for XFER_ACK messages
to be returned for each one. However, interleaving data segments to be returned for each one. However, interleaving data segments
from different bundles is not allowed. from different bundles is not allowed.
No errors or rejections are shown in this example. No errors or rejections are shown in this example.
Entity A Entity B Entity A Entity B
======== ======== ======== ========
+-------------------------+ +-------------------------+
| Open TCP Connnection | -> +-------------------------+
+-------------------------+ <- | Accept Connection |
+-------------------------+
+-------------------------+
| Contact Header | -> +-------------------------+ | Contact Header | -> +-------------------------+
+-------------------------+ <- | Contact Header | +-------------------------+ <- | Contact Header |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| SESS_INIT | -> +-------------------------+ | SESS_INIT | -> +-------------------------+
+-------------------------+ <- | SESS_INIT | +-------------------------+ <- | SESS_INIT |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| XFER_SEGMENT (start) | -> | XFER_SEGMENT (start) | ->
skipping to change at page 20, line 45 skipping to change at page 20, line 37
+-------------------------+ +-------------------------+
<- | XFER_ACK (end) | <- | XFER_ACK (end) |
| Transfer ID [I1] | | Transfer ID [I1] |
| Length [L1+L2+L3] | | Length [L1+L2+L3] |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| SESS_TERM | -> +-------------------------+ | SESS_TERM | -> +-------------------------+
+-------------------------+ <- | SESS_TERM | +-------------------------+ <- | SESS_TERM |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| TCP Close | -> <- | TCP Close |
+-------------------------+ +-------------------------+
Figure 15: An example of the flow of protocol messages on a single Figure 15: An example of the flow of protocol messages on a single
TCP Session between two entities TCP Session between two entities
4. Session Establishment 4. Session Establishment
For bundle transmissions to occur using the TCPCL, a TCPCL session For bundle transmissions to occur using the TCPCL, a TCPCL session
MUST first be established between communicating entities. It is up MUST first be established between communicating entities. It is up
to the implementation to decide how and when session setup is to the implementation to decide how and when session setup is
triggered. For example, some sessions MAY be opened proactively and triggered. For example, some sessions MAY be opened proactively and
skipping to change at page 21, line 41 skipping to change at page 21, line 32
connection failure. An entity MAY decide to re-attempt to establish connection failure. An entity MAY decide to re-attempt to establish
the connection. If it does so, it MUST NOT overwhelm its target with the connection. If it does so, it MUST NOT overwhelm its target with
repeated connection attempts. Therefore, the entity MUST retry the repeated connection attempts. Therefore, the entity MUST retry the
connection setup no earlier than some delay time from the last connection setup no earlier than some delay time from the last
attempt, and it SHOULD use a (binary) exponential back-off mechanism attempt, and it SHOULD use a (binary) exponential back-off mechanism
to increase this delay in case of repeated failures. The upper limit 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 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 longer than one minute before signaling to the BP agent that a
connection cannot be made. connection cannot be made.
Once a TCP connection is established, each entity MUST immediately Once a TCP connection is established, the active entity SHALL
transmit a contact header over the TCP connection. The format of the immediately transmit its contact header. Upon reception of a contact
contact header is described in Section 4.2. Because the TCPCL header, the passive entity SHALL transmit its contact header. If the
protocol version in use is part of the initial contact header, nodes passive entity does not receive a Contact Header after some
using TCPCL version 4 can coexist on a network with nodes using implementation-defined time duration after TCP connection is
earlier TCPCL versions (with some negotiation needed for established, the entity SHALL close the TCP connection. The ordering
interoperation as described in Section 4.3). 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 4.2. Contact Header
Once a TCP connection is established, both parties exchange a contact This section describes the format of the contact header and the
header. This section describes the format of the contact header and meaning of its fields.
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 Upon receipt of the contact header, both entities perform the
validation and negotiation procedures defined in Section 4.3. After validation and negotiation procedures defined in Section 4.3. After
receiving the contact header from the other entity, either entity MAY receiving the contact header from the other entity, either entity MAY
refuse the session by sending a SESS_TERM message with an appropriate refuse the session by sending a SESS_TERM message with an appropriate
reason code. reason code.
The format for the Contact Header is as follows: 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 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
skipping to change at page 23, line 31 skipping to change at page 23, line 31
If the magic string is not present or is not valid, the connection 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 MUST be terminated. The intent of the magic string is to provide
some protection against an inadvertent TCP connection by a different some protection against an inadvertent TCP connection by a different
protocol than the one described in this document. To prevent a flood protocol than the one described in this document. To prevent a flood
of repeated connections from a misconfigured application, an entity of repeated connections from a misconfigured application, an entity
MAY elect to hold an invalid connection open and idle for some time MAY elect to hold an invalid connection open and idle for some time
before ending it. before ending it.
The first negotiation is on the TCPCL protocol version to use. The The first negotiation is on the TCPCL protocol version to use. The
active node always sends its Contact Header first and waits for a active entity always sends its Contact Header first and waits for a
response from the passive node. The active node can repeatedly response from the passive entity. The active entity can repeatedly
attempt different protocol versions in descending order until the attempt different protocol versions in descending order until the
passive node accepts one with a corresponding Contact Header reply. passive entity accepts one with a corresponding Contact Header reply.
Only upon response of a Contact Header from the passive node is the Only upon response of a Contact Header from the passive entity is the
TCPCL protocol version established and parameter negotiation begun. TCPCL protocol version established and parameter negotiation begun.
During contact initiation, the active TCPCL node SHALL send the During contact initiation, the active TCPCL node SHALL send the
highest TCPCL protocol version on a first session attempt for a TCPCL highest TCPCL protocol version on a first session attempt for a TCPCL
peer. If the active node receives a Contact Header with a different peer. If the active entity receives a Contact Header with a
protocol version than the one sent earlier on the TCP connection, the different protocol version than the one sent earlier on the TCP
TCP connection SHALL be closed. If the active node receives a connection, the TCP connection SHALL be closed. If the active entity
SESS_TERM message with reason of "Version Mismatch", that node MAY receives a SESS_TERM message with reason of "Version Mismatch", that
attempt further TCPCL sessions with the peer using earlier protocol node MAY attempt further TCPCL sessions with the peer using earlier
version numbers in decreasing order. Managing multi-TCPCL-session protocol version numbers in decreasing order. Managing multi-TCPCL-
state such as this is an implementation matter. 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 that is greater than the current version of the TCPCL that the node
implements, then the node SHALL shutdown the session with a reason 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 header with a version that is lower than the version of the protocol
that the node implements, the node MAY either terminate the session that the node implements, the node MAY either terminate the session
(with a reason code of "Version mismatch") or the node MAY adapt its (with a reason code of "Version mismatch") or the node MAY adapt its
operation to conform to the older version of the protocol. The operation to conform to the older version of the protocol. The
decision of version fall-back is an implementation matter. decision of version fall-back is an implementation matter.
4.4. Session Security 4.4. Session Security
This version of the TCPCL supports establishing a Transport Layer This version of the TCPCL supports establishing a Transport Layer
Security (TLS) session within an existing TCP connection. When TLS Security (TLS) session within an existing TCP connection. When TLS
is used within the TCPCL it affects the entire session. Once is used within the TCPCL it affects the entire session. Once
established, there is no mechanism available to downgrade a TCPCL established, there is no mechanism available to downgrade a TCPCL
session to non-TLS operation. If this is desired, the entire TCPCL session to non-TLS operation. If this is desired, the entire TCPCL
session MUST be terminated and a new non-TLS-negotiated session session MUST be terminated and a new non-TLS-negotiated session
established. 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 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 Section 4.3. After negotiating an Enable TLS parameter of true, and
before any other TCPCL messages are sent within the session, the before any other TCPCL messages are sent within the session, the
session entities SHALL begin a TLS handshake in accordance with TLS 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 1.2 [RFC5246] or any successors that are compatible with TLS 1.2. By
convention, this protocol uses the node which initiated the convention, this protocol uses the node which initiated the
underlying TCP connection as the "client" role of the TLS handshake underlying TCP connection as the "client" role of the TLS handshake
request. request.
The TLS handshake, if it occurs, is considered to be part of the The TLS handshake, if it occurs, is considered to be part of the
contact negotiation before the TCPCL session itself is established. contact negotiation before the TCPCL session itself is established.
Specifics about sensitive data exposure are discussed in Section 8. Specifics about sensitive data exposure are discussed in Section 8.
The parameters within each TLS negotiation are implementation The parameters within each TLS negotiation are implementation
dependent but any TCPCL node SHALL follow all recommended practices 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 [RFC7525], or any updates or successors that become part
of BCP 195. Within each TLS handshake, the following requirements of BCP 195. Within each TLS handshake, the following requirements
apply (using the rough order in which they occur): apply (using the rough order in which they occur):
Client Hello: When a resolved host name was used to establish the Client Hello: When a resolved host name was used to establish the
TCP connection, the TLS ClientHello SHOULD include a Server Name 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 [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 within the TLS handshake to allow authentication of its side of
the session. When assigned a stable host name or address, the the session. When assigned a stable host name or address, the
passive peer certificate SHOULD contain a subjectAltName entry passive entity certificate SHOULD contain a subjectAltName entry
which authenticates that host name or address. The passive peer which authenticates that host name or address. The passive entity
certificate SHOULD contain a subjectAltName entry of type certificate SHOULD contain a subjectAltName entry of type
uniformResourceIdentifier which authenticates the Node ID of the 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 appropriate server-side certificate which authenticates that host
name and corresponding Node ID. 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. 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 chain within the TLS handshake to allow authentication of its side
of the session. When assigned a stable host name or address, the of the session. When assigned a stable host name or address, the
active peer certificate SHOULD contain a subjectAltName entry active entity certificate SHOULD contain a subjectAltName entry
which authenticates that host name or address. The active peer which authenticates that host name or address. The active entity
certificate SHOULD contain a subjectAltName entry of type certificate SHOULD contain a subjectAltName entry of type
uniformResourceIdentifier which authenticates the Node ID of the uniformResourceIdentifier which authenticates the Node ID of the
peer. peer.
All certificates supplied during TLS handshake SHALL conform with the All certificates supplied during TLS handshake SHALL conform with the
profile of [RFC5280], or any updates or successors to that profile. profile of [RFC5280], or any updates or successors to that profile.
When a certificate is supplied during TLS handshake, the full When a certificate is supplied during TLS handshake, the full
certification chain SHOULD be included unless security policy certification chain SHOULD be included unless security policy
indicates that is unnecessary. indicates that is unnecessary.
If a TLS handshake cannot negotiate a TLS session, both entities of If a TLS handshake cannot negotiate a TLS session, both entities of
the TCPCL session SHALL close the TCP connection. At this point the the TCPCL session SHALL close the TCP connection. At this point the
TCPCL session has not yet been established so there is no TCPCL TCPCL session has not yet been established so there is no TCPCL
session to terminate. This also avoids any potential security issues session to terminate. This also avoids any potential security issues
assoicated with further TCP communication with an untrusted peer. 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 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 4.4.2. TLS Authentication
Using X.509 certificates exchanged during the TLS handshake, each of Using X.509 certificates exchanged during the TLS handshake, each of
the entities can attempt to authenticate its peer at the network the entities can attempt to authenticate its peer at the network
layer (host name and address) and at the application layer (BP Node layer (host name and address) and at the application layer (BP Node
ID). The Node ID exchanged in the Session Initialization is likely ID). The Node ID exchanged in the Session Initialization is likely
to be used by the BP agent for making transfer and routing decisions, to be used by the BP agent for making transfer and routing decisions,
so attempting host name validation is optional while attempting Node so attempting host name validation is optional while attempting Node
ID validation is required. The logic for attempting validation is ID validation is required. The logic for attempting validation is
skipping to change at page 26, line 13 skipping to change at page 26, line 33
distinct Node IDs. When this "virtual host" behavior is used, the distinct Node IDs. When this "virtual host" behavior is used, the
host name is used as the indication of which BP Node the passive host name is used as the indication of which BP Node the passive
entity is attempting to communicate with. A virtual host CL entity entity is attempting to communicate with. A virtual host CL entity
can be authenticated by a certificate containing all of the host can be authenticated by a certificate containing all of the host
names and/or Node IDs being hosted or by several certificates each names and/or Node IDs being hosted or by several certificates each
authenticating a single host name and/or Node ID. authenticating a single host name and/or Node ID.
Any certificate received during TLS handshake SHALL be validated up Any certificate received during TLS handshake SHALL be validated up
to one or more trusted certificate authority (CA) certificates. If to one or more trusted certificate authority (CA) certificates. If
certificate validation fails or if security policy disallows a 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"). (with a reason code of "Contact Failure").
Immediately after the TLS handshake, each side of the TCP connection Either during or immediately after the TLS handshake, each side of
SHOULD perform host name validation of its peer in accordance with the TCP connection SHOULD perform host name validation of its peer in
[RFC6125] unless it is not needed by security policy. The active accordance with [RFC6125] unless it is not needed by security policy.
peer SHALL attempt to authenticate the host name (of the passive The active entity SHALL attempt to authenticate the host name (of the
peer) used to initiate the TCP connection. The active peer MAY passive entity) used to initiate the TCP connection. The active
attempt to authenticate the IP address of the other side of the TCP entity MAY attempt to authenticate the IP address of the other side
connection. The passive peer SHALL attempt to authenticate the IP of the TCP connection. The passive entity SHALL attempt to
address of the other side of the TCP connection. The passive peer authenticate the IP address of the other side of the TCP connection.
MAY use the IP address to resolve one or more host names of the The passive entity MAY use the IP address to resolve one or more host
active peer and attempt to authenticate those. If host name names of the active entity and attempt to authenticate those. If
validation fails (including failure because the certificate does not host name validation fails (including failure because the certificate
contain any DNS-ID), the entity SHOULD terminate the session (with a does not contain any DNS-ID) and security policy disallows an
reason code of "Contact Failure") unless security policy allows an unauthticated host, the entity SHALL terminate the session (with a
unauthticated host. reason code of "Contact Failure").
Immediately before Session Parameter Negotiation, each side of the Immediately before Session Parameter Negotiation, each side of the
session SHALL perform Node ID validation of its peer as described session SHALL perform Node ID validation of its peer as described
below. Node ID validation SHALL succeed if the associated below. Node ID validation SHALL succeed if the associated
certificate contains a subjectAltName entry of type certificate contains a subjectAltName entry of type
uniformResourceIdentifier whose value matches the Node ID of the uniformResourceIdentifier whose value matches the Node ID of the
TCPCL entity. Unless specified otherwise by the definition of the TCPCL entity. Unless specified otherwise by the definition of the
URI scheme being authenticated, URI matching of Node IDs SHALL use URI scheme being authenticated, URI matching of Node IDs SHALL use
the URI comparison logic of [RFC3986] and scheme-based normalization the URI comparison logic of [RFC3986] and scheme-based normalization
of those schemes specified in [I-D.ietf-dtn-bpbis]. This is similar 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 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 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 match" logic with rules about how Node IDs within that scheme are to
be compared with the certificate-authenticated URI. If Node ID be compared with the certificate-authenticated URI. If Node ID
validation fails (including failure because the certificate does not validation fails (including failure because the certificate does not
contain any subjectAltName URI), the entity SHOULD terminate the contain any subjectAltName URI) and security policy disallows an
session (with a reason code of "Contact Failure") unless security unauthticated Node ID, the entity SHALL terminate the session (with a
policy allows an unauthticated node. reason code of "Contact Failure").
4.4.3. Example TLS Initiation 4.4.3. Example TLS Initiation
A summary of a typical TLS use is shown in the sequence in Figure 17 A summary of a typical TLS use is shown in the sequence in Figure 17
below. below.
Entity A Entity B Entity A Entity B
active peer passive peer active peer passive peer
+-------------------------+ +-------------------------+
| Open TCP Connnection | -> | Open TCP Connnection | -> +-------------------------+
+-------------------------+ +-------------------------+ +-------------------------+ <- | Accept Connection |
<- | Accept Connection |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| Contact Header | -> | Contact Header | -> +-------------------------+
+-------------------------+ +-------------------------+ +-------------------------+ <- | Contact Header |
<- | Contact Header |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
| TLS Negotiation | -> <- | TLS Negotiation | | TLS Negotiation | -> <- | TLS Negotiation |
| (as client) | | (as server) | | (as client) | | (as server) |
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
Host name validation occurs. Host name validation occurs.
Secured TCPCL messaging can begin. Secured TCPCL messaging can begin.
+-------------------------+ +-------------------------+ +-------------------------+
| SESS_INIT | -> <- | SESS_INIT | | SESS_INIT | -> +-------------------------+
+-------------------------+ +-------------------------+ +-------------------------+ <- | SESS_INIT |
+-------------------------+
Node ID validation occurs. Node ID validation occurs.
Session is established, transfers can begin. 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 Figure 17: A simple visual example of TCPCL TLS Establishment between
two entities two entities
4.5. Message Header 4.5. Message Header
After the initial exchange of a contact header, all messages After the initial exchange of a contact header, all messages
transmitted over the session are identified by a one-octet header transmitted over the session are identified by a one-octet header
with the following structure: with the following structure:
skipping to change at page 28, line 20 skipping to change at page 29, line 20
Figure 18: Format of the Message Header Figure 18: Format of the Message Header
The message header fields are as follows: The message header fields are as follows:
Message Type: Indicates the type of the message as per Table 2 Message Type: Indicates the type of the message as per Table 2
below. Encoded values are listed in Section 9.5. below. Encoded values are listed in Section 9.5.
+--------------+------+---------------------------------------------+ +--------------+------+---------------------------------------------+
| Name | Code | Description | | Name | Code | Description |
+--------------+------+---------------------------------------------+ +--------------+------+---------------------------------------------+
| SESS_INIT | 0x07 | Contains the session parameter inputs from | | SESS_INIT | 0x07 | Contains the session parameter |
| | | one of the entities, as described in | | | | inputs from one of the entities, |
| | | Section 4.6. | | | | as described in Section 4.6. |
| | | | | | | |
| SESS_TERM | 0x05 | Indicates that one of the entities | | SESS_TERM | 0x05 | Indicates that one of the |
| | | participating in the session wishes to | | | | entities participating in the session |
| | | cleanly terminate the session, as described | | | | wishes to cleanly terminate the session, as |
| | | in Section 6. | | | | described in Section 6. |
| | | | | | | |
| XFER_SEGMENT | 0x01 | Indicates the transmission of a segment of | | XFER_SEGMENT | 0x01 | Indicates the transmission of |
| | | bundle data, as described in Section 5.2.2. | | | | a segment of bundle data, as described in |
| | | Section 5.2.2. |
| | | | | | | |
| XFER_ACK | 0x02 | Acknowledges reception of a data segment, | | XFER_ACK | 0x02 | Acknowledges reception of a |
| | | as described in Section 5.2.3. | | | | data segment, as described in |
| | | Section 5.2.3. |
| | | | | | | |
| XFER_REFUSE | 0x03 | Indicates that the transmission of the | | XFER_REFUSE | 0x03 | Indicates that the |
| | | current bundle SHALL be stopped, as | | | | transmission of the current bundle SHALL be |
| | | described in Section 5.2.4. | | | | stopped, as described in |
| | | Section 5.2.4. |
| | | | | | | |
| KEEPALIVE | 0x04 | Used to keep TCPCL session active, as | | KEEPALIVE | 0x04 | Used to keep TCPCL session |
| | | described in Section 5.1.1. | | | | active, as described in Section |
| | | 5.1.1. |
| | | | | | | |
| MSG_REJECT | 0x06 | Contains a TCPCL message rejection, as | | MSG_REJECT | 0x06 | Contains a TCPCL message |
| | | described in Section 5.1.2. | | | | rejection, as described in |
| | | Section 5.1.2. |
+--------------+------+---------------------------------------------+ +--------------+------+---------------------------------------------+
Table 2: TCPCL Message Types Table 2: TCPCL Message Types
4.6. Session Initialization Message (SESS_INIT) 4.6. Session Initialization Message (SESS_INIT)
Before a session is established and ready to transfer bundles, the Before a session is established and ready to transfer bundles, the
session parameters are negotiated between the connected entities. session parameters are negotiated between the connected entities.
The SESS_INIT message is used to convey the per-entity parameters The SESS_INIT message is used to convey the per-entity parameters
which are used together to negotiate the per-session parameters as which are used together to negotiate the per-session parameters as
skipping to change at page 30, line 20 skipping to change at page 31, line 26
to follow. A zero-length Node ID SHALL be used to indicate the 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 lack of Node ID rather than a truly empty Node ID. This case
allows an entity to avoid exposing Node ID information on an allows an entity to avoid exposing Node ID information on an
untrusted network. A non-zero-length Node ID Data SHALL contain 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 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 message. Every Node ID SHALL be a URI consistent with the
requirements of [RFC3986] and the URI schemes of requirements of [RFC3986] and the URI schemes of
[I-D.ietf-dtn-bpbis]. The Node ID itself can be authenticated as [I-D.ietf-dtn-bpbis]. The Node ID itself can be authenticated as
described in Section 4.4.2. described in Section 4.4.2.
Session Extension Length and Session Extension Items: Together these Session Extension Length and Session Extension Items:
fields represent protocol extension data not defined by this Together these fields represent protocol extension data not
specification. The Session Extension Length is the total number defined by this specification. The Session Extension Length is
of octets to follow which are used to encode the Session Extension the total number of octets to follow which are used to encode the
Item list. The encoding of each Session Extension Item is within Session Extension Item list. The encoding of each Session
a consistent data container as described in Section 4.8. The full Extension Item is within a consistent data container as described
set of Session Extension Items apply for the duration of the TCPCL in Section 4.8. The full set of Session Extension Items apply for
session to follow. The order and mulitplicity of these Session the duration of the TCPCL session to follow. The order and
Extension Items MAY be significant, as defined in the associated mulitplicity of these Session Extension Items MAY be significant,
type specification(s). as defined in the associated type specification(s).
4.7. Session Parameter Negotiation 4.7. Session Parameter Negotiation
An entity calculates the parameters for a TCPCL session by An entity calculates the parameters for a TCPCL session by
negotiating the values from its own preferences (conveyed by the negotiating the values from its own preferences (conveyed by the
contact header it sent to the peer) with the preferences of the peer contact header it sent to the peer) with the preferences of the peer
node (expressed in the contact header that it received from the node (expressed in the contact header that it received from the
peer). The negotiated parameters defined by this specification are peer). The negotiated parameters defined by this specification are
described in the following paragraphs. described in the following paragraphs.
Transfer MTU and Segment MTU: The maximum transmit unit (MTU) for Transfer MTU and Segment MTU: The maximum transmit unit (MTU) for
whole transfers and individual segments are idententical to the whole transfers and individual segments are idententical to the
Transfer MRU and Segment MRU, respectively, of the recevied Transfer MRU and Segment MRU, respectively, of the recevied
contact header. A transmitting peer can send individual segments contact header. A transmitting peer can send individual segments
with any size smaller than the Segment MTU, depending on local with any size smaller than the Segment MTU, depending on local
policy, dynamic network conditions, etc. Determining the size of 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 Session Keepalive: Negotiation of the Session Keepalive parameter is
performed by taking the minimum of this two contact headers' performed by taking the minimum of this two contact headers'
Keepalive Interval. The Session Keepalive interval is a parameter 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 Enable TLS: Negotiation of the Enable TLS parameter is performed by
taking the logical AND of the two contact headers' CAN_TLS flags. taking the logical AND of the two contact headers' CAN_TLS flags.
A local security policy is then applied to determine of the 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 reasonable security policy to both require or disallow the use of
TLS depending upon the desired network flows. Because this state TLS depending upon the desired network flows. Because this state
is negotiated over an unsecured medium, there is a risk of a TLS 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 Stripping as described in Section 8. If the Enable TLS state is
unacceptable, the node SHALL terminate the session with a reason unacceptable, the node SHALL terminate the session with a reason
code of "Contact Failure". Note that this contact failure reason code of "Contact Failure". Note that this contact failure reason
is different than a failure of TLS handshake or TLS authentication is different than a failure of TLS handshake or TLS authentication
after an agreed-upon and acceptable Enable TLS state. If the after an agreed-upon and acceptable Enable TLS state. If the
negotiated Enable TLS value is true and acceptable then TLS negotiated Enable TLS value is true and acceptable then TLS
negotiation feature (described in Section 4.4) begins immediately negotiation feature (described in Section 4.4) begins immediately
skipping to change at page 34, line 15 skipping to change at page 35, line 27
Reason Code: A one-octet refusal reason code interpreted according Reason Code: A one-octet refusal reason code interpreted according
to the descriptions in Table 4. to the descriptions in Table 4.
Rejected Message Header: The Rejected Message Header is a copy of Rejected Message Header: The Rejected Message Header is a copy of
the Message Header to which the MSG_REJECT message is sent as a the Message Header to which the MSG_REJECT message is sent as a
response. response.
+-------------+------+----------------------------------------------+ +-------------+------+----------------------------------------------+
| Name | Code | Description | | Name | Code | Description |
+-------------+------+----------------------------------------------+ +-------------+------+----------------------------------------------+
| Message | 0x01 | A message was received with a Message Type | | Message | 0x01 | A message was received with a |
| Type | | code unknown to the TCPCL node. | | Type | | Message Type code unknown to the TCPCL node. |
| Unknown | | | | Unknown | | |
| | | | | | | |
| Message | 0x02 | A message was received but the TCPCL node | | Message | 0x02 | A message was received but the |
| Unsupported | | cannot comply with the message contents. | | Unsupported | | TCPCL node cannot comply with the message |
| | | contents. |
| | | | | | | |
| Message | 0x03 | A message was received while the session is | | Message | 0x03 | A message was received while the |
| Unexpected | | in a state in which the message is not | | Unexpected | | session is in a state in which the message |
| | | expected. | | | | is not expected. |
+-------------+------+----------------------------------------------+ +-------------+------+----------------------------------------------+
Table 4: MSG_REJECT Reason Codes Table 4: MSG_REJECT Reason Codes
5.2. Bundle Transfer 5.2. Bundle Transfer
All of the messages in this section are directly associated with All of the messages in this section are directly associated with
transferring a bundle between TCPCL entities. transferring a bundle between TCPCL entities.
A single TCPCL transfer results in a bundle (handled by the A single TCPCL transfer results in a bundle (handled by the
convergence layer as opaque data) being exchanged from one node to convergence layer as opaque data) being exchanged from one node to
the other. In TCPCL a transfer is accomplished by dividing a single the other. In TCPCL a transfer is accomplished by dividing a single
bundle up into "segments" based on the receiving-side Segment MRU bundle up into "segments" based on the receiving-side Segment MRU
(see Section 4.2). The choice of the length to use for segments is (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 an implementation matter, but each segment MUST be no larger than the
receiving node's maximum receive unit (MRU) (see the field "Segment 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 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. the 'START' flag and the last segment is indicated by the 'END' flag.
A single transfer (and by extension a single segment) SHALL NOT A single transfer (and by extension a single segment) SHALL NOT
contain data of more than a single bundle. This requirement is contain data of more than a single bundle. This requirement is
imposed on the agent using the TCPCL rather than TCPCL itself. imposed on the agent using the TCPCL rather than TCPCL itself.
If multiple bundles are transmitted on a single TCPCL connection, If multiple bundles are transmitted on a single TCPCL connection,
they MUST be transmitted consecutively without interleaving of they MUST be transmitted consecutively without interleaving of
segments from multiple bundles. segments from multiple bundles.
skipping to change at page 36, line 37 skipping to change at page 37, line 37
The fields of the XFER_SEGMENT message are: The fields of the XFER_SEGMENT message are:
Message Flags: A one-octet field of single-bit flags, interpreted Message Flags: A one-octet field of single-bit flags, interpreted
according to the descriptions in Table 5. All reserved header 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 set to 0 by the sender. All reserved header
flag bits SHALL be ignored by the receiver. flag bits SHALL be ignored by the receiver.
Transfer ID: A 64-bit unsigned integer identifying the transfer Transfer ID: A 64-bit unsigned integer identifying the transfer
being made. being made.
Transfer Extension Length and Transfer Extension Items: Together Transfer Extension Length and Transfer Extension Items:
these fields represent protocol extension data for this Together these fields represent protocol extension data for this
specification. The Transfer Extension Length and Transfer specification. The Transfer Extension Length and Transfer
Extension Item fields SHALL only be present when the 'START' flag Extension Item fields SHALL only be present when the 'START' flag
is set to 1 on the message. The Transfer Extension Length is the 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 total number of octets to follow which are used to encode the
Transfer Extension Item list. The encoding of each Transfer Transfer Extension Item list. The encoding of each Transfer
Extension Item is within a consistent data container as described Extension Item is within a consistent data container as described
in Section 5.2.5. The full set of transfer extension items apply in Section 5.2.5. The full set of transfer extension items apply
only to the assoicated single transfer. The order and only to the assoicated single transfer. The order and
mulitplicity of these transfer extension items MAY be significant, mulitplicity of these transfer extension items MAY be significant,
as defined in the associated type specification(s). as defined in the associated type specification(s).
skipping to change at page 46, line 17 skipping to change at page 47, line 17
An example implementation of the this draft of TCPCLv4 has been An example implementation of the this draft of TCPCLv4 has been
created as a GitHub project [github-dtn-bpbis-tcpcl] and is intented 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 to use as a proof-of-concept and as a possible source of
interoperability testing. This example implementation uses D-Bus as interoperability testing. This example implementation uses D-Bus as
the CL-BP Agent interface, so it only runs on hosts which provide the the CL-BP Agent interface, so it only runs on hosts which provide the
Python "dbus" library. Python "dbus" library.
8. Security Considerations 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 TCPCL can be used to provide point-to-point transport security, but
does not provide security of data-at-rest and does not guarantee end- does not provide security of data-at-rest and does not guarantee end-
to-end bundle security. The bundle security mechanisms defined in to-end bundle security. The bundle security mechanisms defined in
[I-D.ietf-dtn-bpsec] are to be used instead. [I-D.ietf-dtn-bpsec] are to be used instead.
When negotating whether to use TLS security as part of the contact When used without TLS security, the TCPCL exposes all bundle data to
header exchange, it is possible for a man-in-the-middle attacker to passive eavesdroppers. This can be avoided by always using TLS, even
set the CAN_TLS flag to 0 on either side of the exchange. This leads if authentication is not available (see Section 8.10).
to the "SSL Stripping" attack described in [RFC7457]. If TLS is
desired for use on any TCPCL network, it is strongly encouraged that 8.3. Threat: TCPCL Version Downgrade
the security policy disallow use of TCPCL when "Enable TLS" is
negotiated to false. This requires that the TLS handshake occurs, When a TCPCL entity supports multiple versions of the protocol it is
regardless of the policy-driven parameters of the handshake and possible for a malicious or misconfigued peer to use an older version
policy-driven handling of the handshake outcome. 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 Even when using TLS to secure the TCPCL session, the actual
ciphersuite negotiated between the TLS peers MAY be insecure. TLS ciphersuite negotiated between the TLS peers can be insecure.
can be used to perform authentication without data confidentiality, Recommendations for ciphersuite use are included in BCP 195
for example. It is up to security policies within each TCPCL node to [RFC7525]. It is up to security policies within each TCPCL node to
ensure that the negotiated TLS ciphersuite meets transport security ensure that the negotiated TLS ciphersuite meets transport security
requirements. This is identical behavior to STARTTLS use in requirements.
[RFC2595].
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 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 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 valid certificate or that the certificate does not validate either
the host name or Node ID of the peer. Having a CA-validated the host name or Node ID of the peer. Having a CA-validated
certificate does not alone guarantee the identity of the network host certificate does not alone guarantee the identity of the network host
or BP node from which the certificate is provided; additional or BP node from which the certificate is provided; additional
validation procedures bind the host name or node ID based on the validation procedures in Section 4.4.1 bind the host name or node ID
contents of the certificate. The host name validation is a weaker based on the contents of the certificate.
form of authentication, because even if a peer is operating on an
authenticated network host name it can provide an invalid Node ID and The host name validation is a weaker form of authentication, because
cause bundles to be "leaked" to an invalid node. Especially in DTN even if a peer is operating on an authenticated network host name it
environments, network names and addresses of nodes can be time- can provide an invalid Node ID and cause bundles to be "leaked" to an
variable so binding a certificate to a Node ID is a more stable invalid node. Especially in DTN environments, network names and
identity. Node ID validation ensures that the peer to which a bundle addresses of nodes can be time-variable so binding a certificate to a
is transferred is in fact the node which the BP Agent expects it to Node ID is a more stable identity. Trusting an authenticated host
be. It is a reasonable policy to skip host name validation if 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 certificates can be guaranteed to validate the peer's Node ID. In
circumstances where certificates can only be issued to network host circumstances where certificates can only be issued to network host
names, Node ID validation is not possible but it could be reasonable 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 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 ID.
secured by a private CA but is not advisable on the Internet when
using a variety of public CAs.
Another consideration for this protocol relates to denial-of-service 8.9. Threat: 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 The behaviors described in this section all amount to a potential
to stop the flood of data by sending a XFER_REFUSE message, or denial-of-service to a TCPCL entity. The denial-of-service could be
forcibly terminate the session. This burden could cause denial of limited to an individual TCPCL session, could affect other well-
service on other, well-behaving sessions. There is also nothing to behaving sessions on an entity, or could affect all sessions on a
prevent a malicious entity from continually establishing sessions and host.
repeatedly trying to send copious amounts of bundle data. A
listening entity MAY take countermeasures such as ignoring TCP SYN A malicious entity can continually establish TCPCL sessions and delay
messages, closing TCP connections as soon as they are established, sending of protocol-required data to trigger timeouts. The victim
waiting before sending the contact header, sending a SESS_TERM entity can block TCP connections from network peers which are thought
message quickly or with a delay, etc. 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 9. IANA Considerations
Registration procedures referred to in this section are defined in Registration procedures referred to in this section are defined in
[RFC8126]. [RFC8126].
Some of the registries have been defined as version specific to Some of the registries have been defined as version specific to
TCPCLv4, and imports some or all codepoints from TCPCLv3. This was TCPCLv4, and imports some or all codepoints from TCPCLv3. This was
done to disambiguate the use of these codepoints between TCPCLv3 and done to disambiguate the use of these codepoints between TCPCLv3 and
TCPCLv4 while preserving the semantics of some of the codepoints. TCPCLv4 while preserving the semantics of some of the codepoints.
9.1. Port Number 9.1. Port Number
Port number 4556 has been previously assigned as the default port for Within the port registry of [IANA-PORTS], TCP port number 4556 has
the TCP convergence layer in [RFC7242]. This assignment is unchanged been previously assigned as the default port for the TCP convergence
by protocol version 4. Each TCPCL entity identifies its TCPCL layer in [RFC7242]. This assignment is unchanged by TCPCL version 4,
protocol version in its initial contact (see Section 9.2), so there but the assignment reference is updated to this specification. Each
is no ambiguity about what protocol is being used. 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 | | Parameter | Value |
+------------------------+-------------------------------------+ +------------------------+----------------------------------+
| Service Name: | dtn-bundle | | Service Name: | dtn-bundle |
| | | | | |
| Transport Protocol(s): | TCP | | Transport Protocol(s): | TCP |
| | | | | |
| Assignee: | Simon Perreault <simon@per.reau.lt> | | Assignee: | Brian Sipos <bsipos@rkf-eng.com> |
| | | | | |
| Contact: | Simon Perreault <simon@per.reau.lt> | | Contact: | Brian Sipos <bsipos@rkf-eng.com> |
| | | | | |
| Description: | DTN Bundle TCP CL Protocol | | Description: | DTN Bundle TCP CL Protocol |
| | | | | |
| Reference: | [RFC7242] | | Reference: | This specification. |
| | | | | |
| Port Number: | 4556 | | Port Number: | 4556 |
+------------------------+-------------------------------------+ +------------------------+----------------------------------+
9.2. Protocol Versions 9.2. Protocol Versions
IANA has created, under the "Bundle Protocol" registry, a sub- IANA has created, under the "Bundle Protocol" registry [IANA-BUNDLE],
registry titled "Bundle Protocol TCP Convergence-Layer Version a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version
Numbers" and initialize it with the following table. The Numbers". The version number table is updated to include this
registration procedure is RFC Required. specification. The registration procedure is RFC Required.
+-------+-------------+---------------------+ +-------+-------------+-----------------------------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------+---------------------+ +-------+-------------+-----------------------------------+
| 0 | Reserved | [RFC7242] | | 0 | Reserved | [RFC7242] |
| | | | | | | |
| 1 | Reserved | [RFC7242] | | 1 | Reserved | [RFC7242] |
| | | | | | | |
| 2 | Reserved | [RFC7242] | | 2 | Reserved | [RFC7242] |
| | | | | | | |
| 3 | TCPCL | [RFC7242] | | 3 | TCPCL | [RFC7242] |
| | | | | | | |
| 4 | TCPCLv4 | This specification. | | 4 | TCPCLv4 | This specification. |
| | | | | | | |
| 5-255 | Unassigned | | 5-255 | Unassigned |
+-------+-------------+---------------------+ +-------+-------------+-----------------------------------+
9.3. Session Extension Types 9.3. Session Extension Types
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE],
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version
Session Extension Types" and initialize it with the contents of 4 Session Extension Types" and initialize it with the contents of
Table 10. The registration procedure is Expert Review within the Table 10. The registration procedure is Expert Review within the
lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are
reserved for use on private networks for functions not published to reserved for use on private networks for functions not published to
the IANA. the IANA.
Specifications of new session extension types need to define the Specifications of new session extension types need to define the
encoding of the Item Value data as well as any meaning or restriction 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 on the number of or order of instances of the type within an
extension item list. Specifications need to define how the extension extension item list. Specifications need to define how the extension
functions when no instance of the new extension type is received functions when no instance of the new extension type is received
skipping to change at page 49, line 38 skipping to change at page 53, line 22
| 0x8000--0xFFFF | Private/Experimental Use | | 0x8000--0xFFFF | Private/Experimental Use |
+----------------+--------------------------+ +----------------+--------------------------+
Table 10: Session Extension Type Codes Table 10: Session Extension Type Codes
9.4. Transfer Extension Types 9.4. Transfer Extension Types
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE],
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version
Transfer Extension Types" and initialize it with the contents of 4 Transfer Extension Types" and initialize it with the contents of
Table 11. The registration procedure is Expert Review within the Table 11. The registration procedure is Expert Review within the
lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are
reserved for use on private networks for functions not published to reserved for use on private networks for functions not published to
the IANA. the IANA.
Specifications of new transfer extension types need to define the Specifications of new transfer extension types need to define the
encoding of the Item Value data as well as any meaning or restriction 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 on the number of or order of instances of the type within an
extension item list. Specifications need to define how the extension extension item list. Specifications need to define how the extension
functions when no instance of the new extension type is received in a functions when no instance of the new extension type is received in a
skipping to change at page 50, line 28 skipping to change at page 54, line 24
| 0x8000--0xFFFF | Private/Experimental Use | | 0x8000--0xFFFF | Private/Experimental Use |
+----------------+---------------------------+ +----------------+---------------------------+
Table 11: Transfer Extension Type Codes Table 11: Transfer Extension Type Codes
9.5. Message Types 9.5. Message Types
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE],
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version
Message Types" and initialize it with the contents of Table 12. The 4 Message Types" and initialize it with the contents of Table 12.
registration procedure is RFC Required within the lower range 0x01-- The registration procedure is RFC Required within the lower range
0xEF. Values in the range 0xF0--0xFF are reserved for use on private 0x01--0xEF. Values in the range 0xF0--0xFF are reserved for use on
networks for functions not published to the IANA. private networks for functions not published to the IANA.
Specifications of new message types need to define the encoding of Specifications of new message types need to define the encoding of
the message data as well as the purpose and relationship of the new the message data as well as the purpose and relationship of the new
message to existing session/transfer state within the baseline message to existing session/transfer state within the baseline
message sequencing. The use of new message types need to be message sequencing. The use of new message types need to be
negotiated between TCPCL entities within a session (using the session negotiated between TCPCL entities within a session (using the session
extension mechanism) so that the receving entity can properly decode extension mechanism) so that the receving entity can properly decode
all message types used in the session. all message types used in the session.
Expert(s) are encouraged to favor new session/transfer extension Expert(s) are encouraged to favor new session/transfer extension
skipping to change at page 51, line 36 skipping to change at page 55, line 36
| 0xF0--0xFF | Private/Experimental Use | | 0xF0--0xFF | Private/Experimental Use |
+------------+--------------------------+ +------------+--------------------------+
Table 12: Message Type Codes Table 12: Message Type Codes
9.6. XFER_REFUSE Reason Codes 9.6. XFER_REFUSE Reason Codes
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE],
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version
XFER_REFUSE Reason Codes" and initialize it with the contents of 4 XFER_REFUSE Reason Codes" and initialize it with the contents of
Table 13. The registration procedure is Specification Required Table 13. The registration procedure is Specification Required
within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF
are reserved for use on private networks for functions not published are reserved for use on private networks for functions not published
to the IANA. to the IANA.
Specifications of new XFER_REFUSE reason codes need to define the Specifications of new XFER_REFUSE reason codes need to define the
meaning of the reason and disambiguate it with pre-exisiting reasons. meaning of the reason and disambiguate it with pre-exisiting reasons.
Each refusal reason needs to be usable by the receving BP Agent to Each refusal reason needs to be usable by the receving BP Agent to
make retransmission or re-routing decisions. make retransmission or re-routing decisions.
skipping to change at page 52, line 30 skipping to change at page 56, line 30
| 0xF0--0xFF | Private/Experimental Use | | 0xF0--0xFF | Private/Experimental Use |
+------------+--------------------------+ +------------+--------------------------+
Table 13: XFER_REFUSE Reason Codes Table 13: XFER_REFUSE Reason Codes
9.7. SESS_TERM Reason Codes 9.7. SESS_TERM Reason Codes
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE],
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version
SESS_TERM Reason Codes" and initialize it with the contents of 4 SESS_TERM Reason Codes" and initialize it with the contents of
Table 14. The registration procedure is Specification Required Table 14. The registration procedure is Specification Required
within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF
are reserved for use on private networks for functions not published are reserved for use on private networks for functions not published
to the IANA. to the IANA.
Specifications of new SESS_TERM reason codes need to define the Specifications of new SESS_TERM reason codes need to define the
meaning of the reason and disambiguate it with pre-exisiting reasons. meaning of the reason and disambiguate it with pre-exisiting reasons.
Each termination reason needs to be usable by the receving BP Agent Each termination reason needs to be usable by the receving BP Agent
to make re-connection decisions. to make re-connection decisions.
skipping to change at page 53, line 32 skipping to change at page 57, line 32
| 0xF0--0xFF | Private/Experimental Use | | 0xF0--0xFF | Private/Experimental Use |
+------------+--------------------------+ +------------+--------------------------+
Table 14: SESS_TERM Reason Codes Table 14: SESS_TERM Reason Codes
9.8. MSG_REJECT Reason Codes 9.8. MSG_REJECT Reason Codes
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE],
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version
MSG_REJECT Reason Codes" and initialize it with the contents of 4 MSG_REJECT Reason Codes" and initialize it with the contents of
Table 15. The registration procedure is Specification Required Table 15. The registration procedure is Specification Required
within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF
are reserved for use on private networks for functions not published are reserved for use on private networks for functions not published
to the IANA. to the IANA.
Specifications of new MSG_REJECT reason codes need to define the Specifications of new MSG_REJECT reason codes need to define the
meaning of the reason and disambiguate it with pre-exisiting reasons. meaning of the reason and disambiguate it with pre-exisiting reasons.
Each rejection reason needs to be usable by the receving TCPCL Entity Each rejection reason needs to be usable by the receving TCPCL Entity
to make message sequencing and/or session termination decisions. to make message sequencing and/or session termination decisions.
skipping to change at page 54, line 34 skipping to change at page 58, line 34
This specification is based on comments on implementation of This specification is based on comments on implementation of
[RFC7242] provided from Scott Burleigh. [RFC7242] provided from Scott Burleigh.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
Version 7", draft-ietf-dtn-bpbis-14 (work in progress), Version 7", draft-ietf-dtn-bpbis-17 (work in progress),
August 2019. October 2019.
[IANA-BUNDLE]
IANA, "Bundle Protocol",
<https://www.iana.org/assignments/bundle/>.
[IANA-PORTS]
IANA, "Service Name and Transport Protocol Port Number
Registry", <https://www.iana.org/assignments/service-
names-port-numbers/>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
skipping to change at page 55, line 48 skipping to change at page 60, line 9
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
11.2. Informative References 11.2. Informative References
[AEAD-LIMITS]
Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", August 2017,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[github-dtn-bpbis-tcpcl] [github-dtn-bpbis-tcpcl]
Sipos, B., "TCPCL Example Implementation", Sipos, B., "TCPCL Example Implementation",
<https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/tree/ <https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/>.
develop>.
[I-D.ietf-dtn-bpsec] [I-D.ietf-dtn-bpsec]
Birrane, E. and K. McKeever, "Bundle Protocol Security Birrane, E. and K. McKeever, "Bundle Protocol Security
Specification", draft-ietf-dtn-bpsec-12 (work in Specification", draft-ietf-dtn-bpsec-12 (work in
progress), September 2019. progress), September 2019.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, DOI 10.17487/RFC2595, June 1999, RFC 2595, DOI 10.17487/RFC2595, June 1999,
<https://www.rfc-editor.org/info/rfc2595>. <https://www.rfc-editor.org/info/rfc2595>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511,
DOI 10.17487/RFC4511, June 2006,
<https://www.rfc-editor.org/info/rfc4511>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>. April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for
Transport Layer Security (TLS)", RFC 5489,
DOI 10.17487/RFC5489, March 2009,
<https://www.rfc-editor.org/info/rfc5489>.
[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,
<https://www.rfc-editor.org/info/rfc7122>.
[RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant
Networking TCP Convergence-Layer Protocol", RFC 7242, Networking TCP Convergence-Layer Protocol", RFC 7242,
DOI 10.17487/RFC7242, June 2014, DOI 10.17487/RFC7242, June 2014,
<https://www.rfc-editor.org/info/rfc7242>. <https://www.rfc-editor.org/info/rfc7242>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>. February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
 End of changes. 104 change blocks. 
288 lines changed or deleted 515 lines changed or added

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