draft-ietf-dtn-tcpclv4-20.txt   draft-ietf-dtn-tcpclv4-21.txt 
Delay Tolerant Networking B. Sipos Delay-Tolerant Networking B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Intended status: Standards Track M. Demmer Intended status: Standards Track M. Demmer
Expires: November 14, 2020 UC Berkeley Expires: December 11, 2020 UC Berkeley
J. Ott J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
May 13, 2020 June 9, 2020
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-20 draft-ietf-dtn-tcpclv4-21
Abstract Abstract
This document describes a TCP-based convergence layer (TCPCL) for This document describes a TCP-based convergence layer (TCPCL) for
Delay-Tolerant Networking (DTN). This version of the TCPCL protocol Delay-Tolerant Networking (DTN). This version of the TCPCL protocol
resolves implementation issues in the earlier TCPCL Version 3 of resolves implementation issues in the earlier TCPCL Version 3 of
RFC7242 and updates to the Bundle Protocol (BP) contents, encodings, RFC7242 and updates to the Bundle Protocol (BP) contents, encodings,
and convergence layer requirements in BP Version 7. Specifically, and convergence layer requirements in BP Version 7. Specifically,
the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit
being transported and provides a reliable transport of such bundles. being transported and provides a reliable transport of such bundles.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 November 14, 2020. This Internet-Draft will expire on December 11, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . 9 3. General Protocol Description . . . . . . . . . . . . . . . . 9
3.1. Convergence Layer Services . . . . . . . . . . . . . . . 9 3.1. Convergence Layer Services . . . . . . . . . . . . . . . 9
3.2. TCPCL Session Overview . . . . . . . . . . . . . . . . . 11 3.2. TCPCL Session Overview . . . . . . . . . . . . . . . . . 11
3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 13 3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 13
3.4. Transfer Segmentation Policies . . . . . . . . . . . . . 19 3.4. PKIX Environments and CA Policy . . . . . . . . . . . . . 19
3.5. Example Message Exchange . . . . . . . . . . . . . . . . 20 3.5. Session Keeping Policies . . . . . . . . . . . . . . . . 20
4. Session Establishment . . . . . . . . . . . . . . . . . . . . 21 3.6. Transfer Segmentation Policies . . . . . . . . . . . . . 21
4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 22 3.7. Example Message Exchange . . . . . . . . . . . . . . . . 22
4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 23 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 23
4.3. Contact Validation and Negotiation . . . . . . . . . . . 24 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 24
4.4. Session Security . . . . . . . . . . . . . . . . . . . . 25 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 25
4.4.1. Entity Identification . . . . . . . . . . . . . . . . 26 4.3. Contact Validation and Negotiation . . . . . . . . . . . 26
4.4.2. TLS Handshake . . . . . . . . . . . . . . . . . . . . 27 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 27
4.4.3. TLS Authentication . . . . . . . . . . . . . . . . . 28 4.4.1. Entity Identification . . . . . . . . . . . . . . . . 28
4.4.4. Example TLS Initiation . . . . . . . . . . . . . . . 30 4.4.2. TLS Handshake . . . . . . . . . . . . . . . . . . . . 29
4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 31 4.4.3. TLS Authentication . . . . . . . . . . . . . . . . . 30
4.6. Session Initialization Message (SESS_INIT) . . . . . . . 32 4.4.4. Example TLS Initiation . . . . . . . . . . . . . . . 31
4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 34 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 32
4.8. Session Extension Items . . . . . . . . . . . . . . . . . 35 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 34
5. Established Session Operation . . . . . . . . . . . . . . . . 36 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 35
5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 36 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 36
5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 36 5. Established Session Operation . . . . . . . . . . . . . . . . 37
5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 37 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 37
5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 38 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 37
5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 39 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 38
5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 39 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 39
5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 41 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 40
5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 42 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 40
5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 45 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 42
6. Session Termination . . . . . . . . . . . . . . . . . . . . . 47 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 43
6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 47 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 46
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 50 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 48
6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 48
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 50 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 51
8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 51
8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 51 8. Security Considerations . . . . . . . . . . . . . . . . . . . 51
8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 51 8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 52
8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 51 8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 52
8.4. Threat: Transport Security Stripping . . . . . . . . . . 51 8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 52
8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 52 8.4. Threat: Transport Security Stripping . . . . . . . . . . 52
8.6. Threat: Certificate Validation Vulnerabilities . . . . . 52 8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 53
8.7. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 52 8.6. Threat: Certificate Validation Vulnerabilities . . . . . 53
8.8. Threat: BP Node Impersonation . . . . . . . . . . . . . . 52 8.7. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 53
8.9. Threat: Denial of Service . . . . . . . . . . . . . . . . 53 8.8. Threat: BP Node Impersonation . . . . . . . . . . . . . . 53
8.10. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 54 8.9. Threat: Denial of Service . . . . . . . . . . . . . . . . 54
8.10.1. TLS Without Authentication . . . . . . . . . . . . . 54 8.10. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 55
8.10.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 54 8.10.1. TLS Without Authentication . . . . . . . . . . . . . 55
8.11. Predictability of Transfer IDs . . . . . . . . . . . . . 54 8.10.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 55
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 8.11. Predictability of Transfer IDs . . . . . . . . . . . . . 55
9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 55 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 55 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 56
9.3. Session Extension Types . . . . . . . . . . . . . . . . . 56 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 56
9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 57 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 57
9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 58 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 58
9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 59 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 59
9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 60 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 60
9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 61 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 61
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 62 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 62
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63
11.1. Normative References . . . . . . . . . . . . . . . . . . 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 63
11.2. Informative References . . . . . . . . . . . . . . . . . 64 11.1. Normative References . . . . . . . . . . . . . . . . . . 63
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 65 11.2. Informative References . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
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 5, line 11 skipping to change at page 5, line 15
o Mechanisms for locating or identifying other bundle entities o Mechanisms for locating or identifying other bundle entities
(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 convergence layer (CL) protocol and network Node ID to potential convergence layer (CL) protocol and network
address is left to implementation and configuration of the BP address is left to implementation and configuration of the BP
Agent and its various potential routing strategies. Agent and its various 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 creating X.509 certificates; o Policies or mechanisms for issuing Public Key Infrastructure Using
provisioning, deploying, or accessing certificates and private X.509 (PKIX) certificates; provisioning, deploying, or accessing
keys; deploying or accessing certificate revocation lists (CRLs); certificates and private keys; deploying or accessing certificate
or configuring security parameters on an individual entity or revocation lists (CRLs); or configuring security parameters on an
across a network. individual entity or across a network.
o Uses of TLS which are not based on X.509 certificate o Uses of TLS which are not based on PKIX certificate authentication
authentication (see Section 8.10.2) or in which authentication of (see Section 8.10.2) or in which authentication of both entities
both entities is not possible (see Section 8.10.1). is not possible (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 19, line 23 skipping to change at page 19, line 23
| 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 [ST] from the Responder Figure 14: Session Termination [ST] from the Responder
3.4. Transfer Segmentation Policies 3.4. PKIX Environments and CA Policy
This specification gives requirements about how to use PKIX
certificates issued by a Certificate Authority (CA), but does not
define any mechanisms for how those certificates come to be. The
requirements about TCPCL certificate use are broad to support two
quite different PKIX environments:
DTN-Aware CAs: In the ideal case, the CA(s) issuing certificates for
TCPCL entities are aware of the end use of the certificate, have a
mechanism for verifying ownership of a Node ID, and are issuing
certificates directly for that Node ID. In this environment, the
ability to authenticate a peer entity Node ID directly avoids the
need to authenticate a network name or address and then implicitly
trust Node ID of the peer. The TCPCL authenticates the Node ID
whenever possible and this is preferred over lower-level PKIX
identifiers.
DTN-Ignorant CAs: It is expected that Internet-scale "public" CAs
will continue to focus on DNS names as the preferred PKIX
identifier. There are large infrastructures already in-place for
managing network-level authentication and protocols to manage
identity verification in those environments [RFC8555]. The TCPCL
allows for this type of environment by authenticating a lower-
level identifier for a peer and requiring the entity to trust that
the Node ID given by the peer (during session initialization) is
valid. This situation not ideal, as it allows vulnerabilities
described in Section 8.8, but still provides some amount of mutual
authentication to take place for a TCPCL session.
Even within a single TCPCL session, each entity may operate within
different PKI environments and with different identifier limitations.
The requirements related to identifiers in in a PKIX certificate are
in Section 4.4.1.
It is important for interoperability that a TCPCL entity have its own
security policy tailored to accommodate the peers with which it is
expected to operate. A strict TLS security policy is appropriate for
a private network with a single shared CA. Operation on the Internet
(such as inter-site BP gateways) could trade more lax TCPCL security
with the use of encrypted bundle encapsulation [I-D.ietf-dtn-bibect]
to ensure strong bundle security.
3.5. Session Keeping Policies
This specification gives requirements about how to initiate, sustain,
and terminate a TCPCL session but does not impose any requirements on
how sessions need to be managed by a BP agent. It is a network
administration matter to determine an appropriate session keeping
policy, but guidance given here can be used to steer policy toward
performance goals.
Persistent Session: This policy preemptively establishes a single
session to known entities in the network and keeps the session
active using KEEPALIVEs. Benefits of this policy include reducing
the total amount of TCP data needing to be exchanged for a set of
transfers (assuming KEEPALIVE size is significantly smaller than
transfer size), and allowing the session state to indicate peer
connectivity. Drawbacks include wasted network resources when a
session is mostly idle or when the network connectivity is
inconsistent (which requires re-establishing failed sessions), and
potential queueing issues when multiple transfers are requested
simultaneously. This policy assumes that there is agreement
between pairs of entities as to which of the peers will initiate
sessions; if there is no such agreement, there is potential for
duplicate sessions to be established between peers.
Ephemeral Sessions: This policy only establishes a session when an
outgoing transfer is needed to be sent. Benefits of this policy
include not wasting network resources on sessions which are idle
for long periods of time, and avoids queueing issues of a
persistent session. Drawbacks include the TCP and TLS overhead of
establish a new session for each transfer. This policy assumes
that each entity can function in a passive role to listen for
session requests from any peer which needs to send a transfer;
when that is not the case the Polling behavior below needs to
happen. This policy can be augmented to keep the session
established as long as any transfers are queued.
Active-Only Polling Sessions: When naming and/or addressing of one
entity is variable (i.e. dynamically assigned IP address or domain
name) or when firewall or routing rules prevent incoming TCP
connections, that entity can only function in the active role. In
these cases, sessions also need to be established when an incoming
transfer is expected from a peer or based on a periodic schedule.
This polling behavior causes inefficiencies compared to as-needed
ephemeral sessions.
Many other policies can be established in a TCPCL network between the
two extremes of single persistent sessions and only ephemeral
sessions. Different policies can be applied to each peer entity and
to each bundle as it needs to be transferred (e.g for quality of
service). Additionally, future session extension types can apply
further nuance to session policies and policy negotiation.
3.6. 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 SESS_INIT message to determine the largest Segment MRU in its SESS_INIT message to determine the largest
acceptable segment size, and a transmitting node can segment a acceptable segment size, and a transmitting node can segment a
transfer into any sizes smaller than the receiver's Segment MRU. It transfer into any sizes smaller than the receiver's Segment MRU. It
is a network administration matter to determine an appropriate is a network administration matter to determine an appropriate
segmentation policy for entities operating TCPCL, but guidance given segmentation policy for entities operating TCPCL, but guidance given
here can be used to steer policy toward performance goals. It is here can be used to steer policy toward performance goals. It is
also advised to consider the Segment MRU in relation to chunking/ also advised to consider the Segment MRU in relation to chunking/
skipping to change at page 20, line 20 skipping to change at page 22, line 18
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 TCP throughput is dynamic, the transfer MRU. In a situation where TCP throughput is dynamic, the transfer
segmentation size can also be dynamic in order to control message segmentation size can also be dynamic in order to control message
transmission duration. 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 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 session extension and transfer
types can apply further nuance to transfer policies and policy extension types can apply further nuance to transfer policies and
negotiation. policy negotiation.
3.5. Example Message Exchange 3.7. 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.
Note that the sending node can transmit multiple XFER_SEGMENT Note that the sending node can transmit multiple XFER_SEGMENT
messages without waiting for the corresponding XFER_ACK responses. messages without waiting for the corresponding XFER_ACK responses.
This enables pipelining of messages on a transfer stream. Although This enables pipelining of messages on a transfer stream. Although
this example only demonstrates a single bundle transmission, it is this example only demonstrates a single bundle transmission, it is
skipping to change at page 22, line 40 skipping to change at page 24, line 39
longer than one minute (60 seconds) before signaling to the BP agent longer than one minute (60 seconds) before signaling to the BP agent
that a connection cannot be made. that a connection cannot be made.
Once a TCP connection is established, the active entity SHALL Once a TCP connection is established, the active entity SHALL
immediately transmit its Contact Header. Once a TCP connection is immediately transmit its Contact Header. Once a TCP connection is
established, the passive entity SHALL wait for the peer's Contact established, the passive entity SHALL wait for the peer's Contact
Header. If the passive entity does not receive a Contact Header Header. If the passive entity does not receive a Contact Header
after some implementation-defined time duration after TCP connection after some implementation-defined time duration after TCP connection
is established, the entity SHALL close the TCP connection. Entities is established, the entity SHALL close the TCP connection. Entities
SHOULD choose a Contact Header reception timeout interval no longer SHOULD choose a Contact Header reception timeout interval no longer
than 10 minutes (600 seconds). Upon reception of a Contact Header, than one minute (60 seconds). Upon reception of a Contact Header,
the passive entity SHALL transmit its Contact Header. The ordering the passive entity SHALL transmit its Contact Header. The ordering
of the Contact Header exchange allows the passive entity to avoid of the Contact Header exchange allows the passive entity to avoid
allocating resources to a potential TCPCL session until after a valid allocating resources to a potential TCPCL session until after a valid
Contact Header has been received from the active entity. This Contact Header has been received from the active entity. This
ordering also allows the passive peer to adapt to alternate TCPCL ordering also allows the passive peer to adapt to alternate TCPCL
protocol versions. protocol versions.
The format of the Contact Header is described in Section 4.2. The format of the Contact Header is described in Section 4.2.
Because the TCPCL protocol version in use is part of the initial Because the TCPCL protocol version in use is part of the initial
Contact Header, nodes using TCPCL version 4 can coexist on a network Contact Header, nodes using TCPCL version 4 can coexist on a network
skipping to change at page 26, line 13 skipping to change at page 28, line 9
will not cause data truncation or corruption. will not cause data truncation or corruption.
Subsequent TCPCL session attempts to the same passive entity MAY Subsequent TCPCL session attempts to the same passive entity MAY
attempt use the TLS connection resumption feature. There is no attempt use the TLS connection resumption feature. There is no
guarantee that the passive entity will accept the request to resume a guarantee that the passive entity will accept the request to resume a
TLS session, and the active entity cannot assume any resumption TLS session, and the active entity cannot assume any resumption
outcome. outcome.
4.4.1. Entity Identification 4.4.1. Entity Identification
The TCPCL uses the TLS for certificate exchange in both directions to The TCPCL uses TLS for certificate exchange in both directions to
identify each entity and to allow each entity to authenticate its identify each entity and to allow each entity to authenticate its
peer. Each certificate can potentially identify multiple entities peer. Each certificate can potentially identify multiple entities
and there is no problem using such a certificate as long as the and there is no problem using such a certificate as long as the
identifiers are sufficient to meet authentication policy (as identifiers are sufficient to meet authentication policy (as
described in later sections) for the entity which presents it. described in later sections) for the entity which presents it.
The public key infrastructure (PKI) Certificate Authority (CA) or Because the PKIX environment of each TCPCL entity are likely not
authorities available within a network are likely not controlled by controlled by the certificate end users (see Section 3.4), the TCPCL
the certificate end users and CA policies vary widely between
networks and PKI management tools. For this reason, the TCPCL
defines a prioritized list of what a certificate can identify about a defines a prioritized list of what a certificate can identify about a
TCPCL entity: TCPCL entity:
Node ID: The ideal certificate identity is the Node ID of the entity Node ID: The ideal certificate identity is the Node ID of the entity
using the NODE-ID definition below. When the Node ID is using the NODE-ID definition below. When the Node ID is
identified, there is no need for any lower-level identification to identified, there is no need for any lower-level identification to
take place. take place.
Host Name: If CA policy forbids a certificate to contain an DNS Name: If CA policy forbids a certificate to contain an arbitrary
arbitrary NODE-ID but allows a DNS-ID to be identified then one or NODE-ID but allows a DNS-ID to be identified then one or more
more stable host names can be identified in the certificate. The stable host names can be identified in the certificate. The use
use of wildcard DNS-ID is discouraged due to the complex rules for of wildcard DNS-ID is discouraged due to the complex rules for
matching and dependence on implementation support for wildcard matching and dependence on implementation support for wildcard
matching. matching (see Section 6.4.3 of [RFC6125]).
Network Address: If no stable host name is available but a stable Network Address: If no stable host name is available but a stable
network address is available and CA policy allows a certificate to network address is available and CA policy allows a certificate to
contain a NETWORK-ID (as defined below) then one or more network contain a NETWORK-ID (as defined below) then one or more network
addresses can be identified in the certificate. There is no addresses can be identified in the certificate.
wildcard-type address matching defined, so this is the least
robust
When only a DNS-ID or NETWORK-ID can be identified by a certificate, When only a DNS-ID or NETWORK-ID can be identified by a certificate,
it is implied that an entity which authenticates using that it is implied that an entity which authenticates using that
certificate is trusted to provide a valid Node ID in its SESS_INIT; certificate is trusted to provide a valid Node ID in its SESS_INIT;
the certificate itself does not actually authenticate that Node ID. the certificate itself does not actually authenticate that Node ID.
The RECOMMENDED security policy of an entity is to validate a peer The RECOMMENDED security policy of an entity is to validate a peer
which authenticates its Node ID regardless of an authenticated host which authenticates its Node ID regardless of an authenticated host
name or address, and only consider the host/address authentication in name or address, and only consider the host/address authentication in
the absence of an authenticated Node ID. the absence of an authenticated Node ID.
skipping to change at page 28, line 47 skipping to change at page 30, line 38
of the TCPCL session SHALL close the TCP connection. At this point of the TCPCL session SHALL close the TCP connection. At this point
the TCPCL session has not yet been established so there is no TCPCL the TCPCL session has not yet been established so there is no TCPCL
session to terminate. session to terminate.
After a TLS connection is successfully established, the active entity After a TLS connection 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 negotiation and all subsequent messaging are secured. session negotiation and all subsequent messaging are secured.
4.4.3. TLS Authentication 4.4.3. TLS Authentication
Using X.509 certificates exchanged during the TLS handshake, each of Using PKIX certificates exchanged during the TLS handshake, each of
the entities can attempt to authenticate its peer Node ID directly or the entities can attempt to authenticate its peer Node ID directly or
authenticate the peer host name or network address. The Node ID authenticate the peer host name or network address. The Node ID
exchanged in the Session Initialization is likely to be used by the exchanged in the Session Initialization is likely to be used by the
BP agent for making transfer and routing decisions, so attempting BP agent for making transfer and routing decisions, so attempting
Node ID validation is required while attempting host name validation Node ID validation is required while attempting host name validation
is optional. The logic for attempting validation is separate from is optional. The logic for attempting validation is separate from
the logic for handling the result of validation, which is based on the logic for handling the result of validation, which is based on
local security policy. local security policy.
By using the SNI host name (see Section 4.4.2) a single passive By using the SNI host name (see Section 4.4.2) a single passive
skipping to change at page 34, line 21 skipping to change at page 35, line 31
Session Extension Length and Session Extension Items: Session Extension Length and Session Extension Items:
Together these fields represent protocol extension data not Together these fields represent protocol extension data not
defined by this specification. The Session Extension Length is defined by this specification. The Session Extension Length is
the total number of octets to follow which are used to encode the the total number of octets to follow which are used to encode the
Session Extension Item list. The encoding of each Session Session Extension Item list. The encoding of each Session
Extension Item is within a consistent data container as described Extension Item is within a consistent data container as described
in Section 4.8. The full set of Session Extension Items apply for in Section 4.8. The full set of Session Extension Items apply for
the duration of the TCPCL session to follow. The order and the duration of the TCPCL session to follow. The order and
multiplicity of these Session Extension Items is significant, as multiplicity of these Session Extension Items is significant, as
defined in the associated type specification(s). defined in the associated type specification(s). If the content
of the Session Extension Items data disagrees with the Session
Extension Length (e.g., the last Item claims to use more octets
than are present in the Session Extension Length), the reception
of the SESS_INIT is considered to have failed.
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
SESS_INIT it sent to the peer) with the preferences of the peer node SESS_INIT it sent to the peer) with the preferences of the peer node
(expressed in the SESS_INIT that it received from the peer). The (expressed in the SESS_INIT that it received from the peer). The
negotiated parameters defined by this specification are described in negotiated parameters defined by this specification are described in
the following paragraphs. the following paragraphs.
skipping to change at page 40, line 48 skipping to change at page 41, line 48
Together 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 associated single transfer. The order and only to the associated single transfer. The order and
multiplicity of these transfer extension items is significant, as multiplicity of these transfer extension items is significant, as
defined in the associated type specification(s). defined in the associated type specification(s). If the content
of the Transfer Extension Items data disagrees with the Transfer
Extension Length (e.g., the last Item claims to use more octets
than are present in the Transfer Extension Length), the reception
of the XFER_SEGMENT is considered to have failed.
Data length: A 64-bit unsigned integer indicating the number of Data length: A 64-bit unsigned integer indicating the number of
octets in the Data contents to follow. octets in the Data contents to follow.
Data contents: The variable-length data payload of the message. Data contents: The variable-length data payload of the message.
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| Name | Code | Description | | Name | Code | Description |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| END | 0x01 | If bit is set, indicates that this is the | | END | 0x01 | If bit is set, indicates that this is the |
skipping to change at page 49, line 28 skipping to change at page 50, line 28
| | | | | | | |
| Contact | 0x04 | The node cannot interpret or negotiate a | | Contact | 0x04 | The node cannot interpret or negotiate a |
| Failure | | Contact Header or SESS_INIT option. | | Failure | | Contact Header or SESS_INIT option. |
| | | | | | | |
| Resource | 0x05 | The node has run into some resource limit | | Resource | 0x05 | The node has run into some resource limit |
| Exhaustion | | and cannot continue the session. | | Exhaustion | | and cannot continue the session. |
+--------------+------+---------------------------------------------+ +--------------+------+---------------------------------------------+
Table 9: SESS_TERM Reason Codes Table 9: SESS_TERM Reason Codes
A session termination MAY occur immediately after transmission of a The earliest a TCPCL session termination MAY occur is immediately
Contact Header (and prior to any further message transmit). This after transmission of a Contact Header (and prior to any further
can, for example, be used to notify that the entity is currently not message transmit). This can, for example, be used to notify that the
able or willing to communicate. However, an entity MUST always send entity is currently not able or willing to communicate. However, an
the Contact Header to its peer before sending a SESS_TERM message. entity MUST always send the Contact Header to its peer before sending
a SESS_TERM message.
If reception of the Contact Header itself somehow fails (e.g., an Termination of the TCP connection MAY occur prior to receiving the
invalid "magic string" is received), an entity SHALL close the TCP Contact header as discussed in Section 4.1. If reception of the
connection without sending a SESS_TERM message. If the content of Contact Header itself somehow fails (e.g., an invalid "magic string"
the Session Extension Items data disagrees with the Session Extension is received), an entity SHALL close the TCP connection without
Length (i.e., the last Item claims to use more octets than are sending a SESS_TERM message.
present in the Session Extension Length), the reception of the
SESS_INIT is considered to have failed.
If a session is to be terminated before a protocol message has If a session is to be terminated before a protocol message has
completed being sent, then the entity MUST NOT transmit the SESS_TERM completed being sent, then the entity MUST NOT transmit the SESS_TERM
message but still SHALL close the TCP connection. Each TCPCL message message but still SHALL close the TCP connection. Each TCPCL message
is contiguous in the octet stream and has no ability to be cut short is contiguous in the octet stream and has no ability to be cut short
and/or preempted by an other message. This is particularly important and/or preempted by an other message. This is particularly important
when large segment sizes are being transmitted; either entire when large segment sizes are being transmitted; either entire
XFER_SEGMENT is sent before a SESS_TERM message or the connection is XFER_SEGMENT is sent before a SESS_TERM message or the connection is
simply terminated mid-XFER_SEGMENT. simply terminated mid-XFER_SEGMENT.
skipping to change at page 52, line 48 skipping to change at page 53, line 48
advisable to take advantage of session key updates to avoid those advisable to take advantage of session key updates to avoid those
limits. When key updates are not possible, renegotiation of the TLS limits. When key updates are not possible, renegotiation of the TLS
connection or establishing new TCPCL/TLS session are alternatives to connection or establishing new TCPCL/TLS session are alternatives to
limit session key use. limit session key use.
8.8. Threat: BP Node Impersonation 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 (see Section 3.4). Having a CA-
certificate does not alone guarantee the identity of the network host validated certificate does not alone guarantee the identity of the
or BP node from which the certificate is provided; additional network host or BP node from which the certificate is provided;
validation procedures in Section 4.4.2 bind the host name or node ID additional validation procedures in Section 4.4.2 bind the host name
based on the contents of the certificate. or node ID based on the contents of the certificate.
The host name validation is a weaker form of authentication, because The host name validation is a weaker form of authentication, because
even if a peer is operating on an authenticated network host name it even if a peer is operating on an authenticated network host name it
can provide an invalid Node ID and cause bundles to be "leaked" to an can provide an invalid Node ID and cause bundles to be "leaked" to an
invalid node. Especially in DTN environments, network names and invalid node. Especially in DTN environments, network names and
addresses of nodes can be time-variable so binding a certificate to a addresses of nodes can be time-variable so binding a certificate to a
Node ID is a more stable identity. Trusting an authenticated host Node ID is a more stable identity.
name can be feasible 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 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. 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 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. Determining of when a host name authentication can be trusted to ID. Determining of when a host name authentication can be trusted to
validate a Node ID is also a policy matter outside the scope of this validate a Node ID is also a policy matter outside the scope of this
skipping to change at page 54, line 20 skipping to change at page 55, line 17
terminate the session during the negotiation of Section 4.7 if the terminate the session during the negotiation of Section 4.7 if the
Keepalive Interval is unacceptable. Keepalive Interval is unacceptable.
Finally, an attacker or a misconfigured entity can cause issues at Finally, an attacker or a misconfigured entity can cause issues at
the TCP connection which will cause unnecessary TCP retransmissions the TCP connection which will cause unnecessary TCP retransmissions
or connection resets, effectively denying the use of the overlying or connection resets, effectively denying the use of the overlying
TCPCL session. TCPCL session.
8.10. Alternate Uses of TLS 8.10. Alternate Uses of TLS
This specification makes use of X.509 PKI certificate validation and This specification makes use of PKIX certificate validation and
authentication within TLS. There are alternate uses of TLS which are authentication within TLS. There are alternate uses of TLS which are
not necessarily incompatible with the security goals of this not necessarily incompatible with the security goals of this
specification, but are outside of the scope of this document. The specification, but are outside of the scope of this document. The
following subsections give examples of alternate TLS uses. following subsections give examples of alternate TLS uses.
8.10.1. TLS Without Authentication 8.10.1. TLS Without Authentication
In environments where PKI is available but there are restrictions on In environments where PKI is available but there are restrictions on
the issuance of certificates (including the contents of the issuance of certificates (including the contents of
certificates), it may be possible to make use of TLS in a way which certificates), it may be possible to make use of TLS in a way which
skipping to change at page 62, line 34 skipping to change at page 63, 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-24 (work in progress), Version 7", draft-ietf-dtn-bpbis-25 (work in progress),
March 2020. May 2020.
[IANA-BUNDLE] [IANA-BUNDLE]
IANA, "Bundle Protocol", IANA, "Bundle Protocol",
<https://www.iana.org/assignments/bundle/>. <https://www.iana.org/assignments/bundle/>.
[IANA-PORTS] [IANA-PORTS]
IANA, "Service Name and Transport Protocol Port Number IANA, "Service Name and Transport Protocol Port Number
Registry", <https://www.iana.org/assignments/service- Registry", <https://www.iana.org/assignments/service-
names-port-numbers/>. names-port-numbers/>.
skipping to change at page 64, line 20 skipping to change at page 65, line 20
[AEAD-LIMITS] [AEAD-LIMITS]
Luykx, A. and K. Paterson, "Limits on Authenticated Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", August 2017, Encryption Use in TLS", August 2017,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. <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/>. <https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/>.
[I-D.ietf-dtn-bibect]
Burleigh, S., "Bundle-in-Bundle Encapsulation", draft-
ietf-dtn-bibect-03 (work in progress), February 2020.
[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-22 (work in Specification", draft-ietf-dtn-bpsec-22 (work in
progress), March 2020. progress), March 2020.
[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 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
skipping to change at page 65, line 37 skipping to change at page 66, line 37
[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>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
Appendix A. Significant changes from RFC7242 Appendix A. Significant changes from RFC7242
The areas in which changes from [RFC7242] have been made to existing The areas in which changes from [RFC7242] have been made to existing
headers and messages are: headers and messages are:
o Split Contact Header into pre-TLS protocol negotiation and o Split Contact Header into pre-TLS protocol negotiation and
SESS_INIT parameter negotiation. The Contact Header is now fixed- SESS_INIT parameter negotiation. The Contact Header is now fixed-
length. length.
o Changed Contact Header content to limit number of negotiated o Changed Contact Header content to limit number of negotiated
 End of changes. 28 change blocks. 
117 lines changed or deleted 223 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/