draft-ietf-dtn-tcpclv4-24.txt   draft-ietf-dtn-tcpclv4-25.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: 7 June 2021 UC Berkeley Expires: 5 August 2021 UC Berkeley
J. Ott J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
4 December 2020 1 February 2021
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-24 draft-ietf-dtn-tcpclv4-25
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 7 June 2021. This Internet-Draft will expire on 5 August 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 2, line 35 skipping to change at page 2, line 35
3.5. Session Keeping Policies . . . . . . . . . . . . . . . . 20 3.5. Session Keeping Policies . . . . . . . . . . . . . . . . 20
3.6. Transfer Segmentation Policies . . . . . . . . . . . . . 21 3.6. Transfer Segmentation Policies . . . . . . . . . . . . . 21
3.7. Example Message Exchange . . . . . . . . . . . . . . . . 22 3.7. Example Message Exchange . . . . . . . . . . . . . . . . 22
4. Session Establishment . . . . . . . . . . . . . . . . . . . . 24 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 24
4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 24 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 24
4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 25 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 25
4.3. Contact Validation and Negotiation . . . . . . . . . . . 26 4.3. Contact Validation and Negotiation . . . . . . . . . . . 26
4.4. Session Security . . . . . . . . . . . . . . . . . . . . 28 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 28
4.4.1. Entity Identification . . . . . . . . . . . . . . . . 28 4.4.1. Entity Identification . . . . . . . . . . . . . . . . 28
4.4.2. Certificate Profile for TCPCL . . . . . . . . . . . . 29 4.4.2. Certificate Profile for TCPCL . . . . . . . . . . . . 29
4.4.3. TLS Handshake . . . . . . . . . . . . . . . . . . . . 30 4.4.3. TLS Handshake . . . . . . . . . . . . . . . . . . . . 31
4.4.4. TLS Authentication . . . . . . . . . . . . . . . . . 31 4.4.4. TLS Authentication . . . . . . . . . . . . . . . . . 32
4.4.5. Policy Recommendations . . . . . . . . . . . . . . . 33 4.4.5. Policy Recommendations . . . . . . . . . . . . . . . 33
4.4.6. Example TLS Initiation . . . . . . . . . . . . . . . 33 4.4.6. Example TLS Initiation . . . . . . . . . . . . . . . 34
4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 35 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 36
4.6. Session Initialization Message (SESS_INIT) . . . . . . . 36 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 37
4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 38 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 39
4.8. Session Extension Items . . . . . . . . . . . . . . . . . 39 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 40
5. Established Session Operation . . . . . . . . . . . . . . . . 40 5. Established Session Operation . . . . . . . . . . . . . . . . 41
5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 40 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 41
5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 40 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 41
5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 41 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 42
5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 43 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 44
5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 44 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 45
5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 44 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 45
5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 46 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 47
5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 48 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 49
5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 50 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 51
6. Session Termination . . . . . . . . . . . . . . . . . . . . . 52 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 53
6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 52 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 53
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 55 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 56
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 55 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 56
8. Security Considerations . . . . . . . . . . . . . . . . . . . 55 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57
8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 56 8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 57
8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 56 8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 57
8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 56 8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 57
8.4. Threat: Transport Security Stripping . . . . . . . . . . 56 8.4. Threat: Transport Security Stripping . . . . . . . . . . 57
8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 57 8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 58
8.6. Threat: Untrusted End-Entity Certificate . . . . . . . . 57 8.6. Threat: Untrusted End-Entity Certificate . . . . . . . . 58
8.7. Threat: Certificate Validation Vulnerabilities . . . . . 57 8.7. Threat: Certificate Validation Vulnerabilities . . . . . 58
8.8. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 58 8.8. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 59
8.9. Threat: BP Node Impersonation . . . . . . . . . . . . . . 58 8.9. Threat: BP Node Impersonation . . . . . . . . . . . . . . 59
8.10. Threat: Denial of Service . . . . . . . . . . . . . . . . 59 8.10. Threat: Denial of Service . . . . . . . . . . . . . . . . 60
8.11. Mandatory-to-Implement TLS . . . . . . . . . . . . . . . 60 8.11. Mandatory-to-Implement TLS . . . . . . . . . . . . . . . 61
8.12. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 60 8.12. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 61
8.12.1. TLS Without Authentication . . . . . . . . . . . . . 60 8.12.1. TLS Without Authentication . . . . . . . . . . . . . 61
8.12.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 60 8.12.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 61
8.13. Predictability of Transfer IDs . . . . . . . . . . . . . 61 8.13. Predictability of Transfer IDs . . . . . . . . . . . . . 62
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 61 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 62
9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 62 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 63
9.3. Session Extension Types . . . . . . . . . . . . . . . . . 63 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 64
9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 63 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 64
9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 64 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 65
9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 65 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 66
9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 66 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 67
9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 67 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 68
9.9. Object Identifier for PKIX Extended Key Usage . . . . . . 68 9.9. Object Identifier for PKIX Extended Key Usage . . . . . . 69
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
11.1. Normative References . . . . . . . . . . . . . . . . . . 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 70
11.2. Informative References . . . . . . . . . . . . . . . . . 70 11.2. Informative References . . . . . . . . . . . . . . . . . 71
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 72 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75
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 14 skipping to change at page 5, line 14
* The format of protocol data units of the Bundle Protocol, as those * The format of protocol data units of the Bundle Protocol, as those
are defined elsewhere in [I-D.ietf-dtn-bpbis]. This includes the are defined elsewhere in [I-D.ietf-dtn-bpbis]. This includes the
concept of bundle fragmentation or bundle encapsulation. The concept of bundle fragmentation or bundle encapsulation. The
TCPCL transfers bundles as opaque data blocks. TCPCL transfers bundles as opaque data blocks.
* Mechanisms for locating or identifying other bundle entities * 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. The mapping
of DNS name and/or address to a choice of end-entity certificate
to authenticate a node to its peers.
* Logic for routing bundles along a path toward a bundle's endpoint. * 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 entities in a routing sequence. adjacent entities in a routing sequence.
* Policies or mechanisms for issuing Public Key Infrastructure Using * Policies or mechanisms for issuing Public Key Infrastructure Using
X.509 (PKIX) certificates; provisioning, deploying, or accessing X.509 (PKIX) certificates; provisioning, deploying, or accessing
certificates and private keys; deploying or accessing certificate certificates and private keys; deploying or accessing certificate
revocation lists (CRLs); or configuring security parameters on an revocation lists (CRLs); or configuring security parameters on an
individual entity or across a network. individual entity or across a network.
skipping to change at page 20, line 24 skipping to change at page 20, line 24
By using the Server Name Indication (SNI) DNS name (see By using the Server Name Indication (SNI) DNS name (see
Section 4.4.3) a single passive entity can act as a convergence layer Section 4.4.3) a single passive entity can act as a convergence layer
for multiple BP agents with distinct Node IDs. When this "virtual for multiple BP agents with distinct Node IDs. When this "virtual
host" behavior is used, the DNS name is used as the indication of host" behavior is used, the DNS name is used as the indication of
which BP Node the active entity is attempting to communicate with. A which BP Node the active entity is attempting to communicate with. A
virtual host CL entity can be authenticated by a certificate virtual host CL entity can be authenticated by a certificate
containing all of the DNS names and/or Node IDs being hosted or by containing all of the DNS names and/or Node IDs being hosted or by
several certificates each authenticating a single DNS name and/or several certificates each authenticating a single DNS name and/or
Node ID, using the SNI value from the peer to select which Node ID, using the SNI value from the peer to select which
certificate to use. certificate to use. The logic for mapping an SNI DNS name to an end-
entity certificate is an implementation matter, and can involve
correlating DNS name with Node ID or other certificate attributes.
3.5. Session Keeping Policies 3.5. Session Keeping Policies
This specification gives requirements about how to initiate, sustain, This specification gives requirements about how to initiate, sustain,
and terminate a TCPCL session but does not impose any requirements on 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 how sessions need to be managed by a BP agent. It is a network
administration matter to determine an appropriate session keeping administration matter to determine an appropriate session keeping
policy, but guidance given here can be used to steer policy toward policy, but guidance given here can be used to steer policy toward
performance goals. performance goals.
skipping to change at page 29, line 38 skipping to change at page 29, line 38
This specification defines a IPADDR-ID of a certificate as being the This specification defines a IPADDR-ID of a certificate as being the
subjectAltName entry of type iPAddress whose value is encoded subjectAltName entry of type iPAddress whose value is encoded
according to [RFC5280]. according to [RFC5280].
4.4.2. Certificate Profile for TCPCL 4.4.2. Certificate Profile for TCPCL
All end-entity certificates used by a TCPCL entity SHALL conform to All end-entity certificates used by a TCPCL entity SHALL conform to
[RFC5280], or any updates or successors to that profile. When an [RFC5280], or any updates or successors to that profile. When an
end-entity certificate is supplied, the full certification chain end-entity certificate is supplied, the full certification chain
SHOULD be included unless security policy indicates that is SHOULD be included unless security policy indicates that is
unnecessary. unnecessary. An entity SHOULD omit the root CA certificate (the last
item of the chain) when sending a certification chain, as the
recipient already has the root CA to anchor its validation.
The TCPCL requires Version 3 certificates due to the extensions used The TCPCL requires Version 3 certificates due to the extensions used
by this profile. TCPCL entities SHALL reject as invalid Version 1 by this profile. TCPCL entities SHALL reject as invalid Version 1
and Version 2 end-entity certificates. and Version 2 end-entity certificates.
TCPCL entities SHALL accept certificates that contain an empty TCPCL entities SHALL accept certificates that contain an empty
Subject field or contain a Subject without a Common Name. Identity Subject field or contain a Subject without a Common Name. Identity
information in end-entity certificates is contained entirely in the information in end-entity certificates is contained entirely in the
subjectAltName extension as defined in Section 4.4.1 and below. subjectAltName extension as defined in Section 4.4.1 and below.
skipping to change at page 30, line 13 skipping to change at page 30, line 17
accordance with [RFC5280]. TCPCL entities SHOULD NOT rely on either accordance with [RFC5280]. TCPCL entities SHOULD NOT rely on either
a Subject Key Identifier and an Authority Key Identifier being a Subject Key Identifier and an Authority Key Identifier being
present in any received certificate. Including key identifiers present in any received certificate. Including key identifiers
simplifies the work of an entity needing to assemble a certification simplifies the work of an entity needing to assemble a certification
chain. chain.
Unless prohibited by CA policy, a TCPCL end-entity certificate SHALL Unless prohibited by CA policy, a TCPCL end-entity certificate SHALL
contain a NODE-ID which authenticates the Node ID of the peer. When contain a NODE-ID which authenticates the Node ID of the peer. When
assigned one or more stable DNS names, a TCPCL end-entity certificate assigned one or more stable DNS names, a TCPCL end-entity certificate
SHOULD contain DNS-ID which authenticates those (fully qualified) SHOULD contain DNS-ID which authenticates those (fully qualified)
names. When assigned one or more stable network addresss, a TCPCL names. When assigned one or more stable network addresses, a TCPCL
end-entity certificate MAY contain IPADDR-ID which authenticates end-entity certificate MAY contain IPADDR-ID which authenticates
those addresses. those addresses.
This document defines a PKIX Extended Key Usage key purpose "id-kp- This document defines a PKIX Extended Key Usage key purpose "id-kp-
bundleSecurity" in Section 9.9 which MAY be used to restrict a bundleSecurity" in Section 9.9 which can be used to restrict a
certificate's use. The "id-kp-bundleSecurity" purpose can be certificate's use. The "id-kp-bundleSecurity" purpose can be
combined with other purposes in the same certificate. Although not combined with other purposes in the same certificate. When allowed
specifically required by TCPCL, some networks or TLS implementations by CA policy, a BPSec end-entity certificate SHOULD contain a PKIX
assume the use of "id-kp-clientAuth" and "id-kp-serverAuth" are Extended Key Usage extension in accordance with Section 4.2.1.12 of
needed for, respectively, the client-side and server-side of TLS [RFC5280]. When the PKIX Extended Key Usage extension is present, it
authentication. For interoperability, a TCPCL end-entity certificate SHOULD contain a key purpose "id-kp-bundleSecurity" as defined in
MAY contain an Extended Key Usage with both "id-kp-clientAuth" and Section 9.9. Although not specifically required by TCPCL, some
"id-kp-serverAuth" values. networks or TLS implementations assume the use of "id-kp-clientAuth"
and "id-kp-serverAuth" are needed for, respectively, the client-side
and server-side of TLS authentication. For interoperability, a TCPCL
end-entity certificate MAY contain an Extended Key Usage with both
"id-kp-clientAuth" and "id-kp-serverAuth" values.
The PKIX Key Usage bits which are consistent with TCPCL security are: When allowed by CA policy, a TCPCL end-entity certificate SHOULD
digitalSignature, keyEncipherment, and keyAgreement. The specific contain a PKIX Key Usage extension in accordance with Section 4.2.1.3
algorithms used during the TLS handshake will determine which of of [RFC5280]. The PKIX Key Usage bit which is consistent with TCPCL
those key uses are exercised. security using TLS 1.3 is digitalSignature. The specific algorithms
used during the TLS handshake will determine which of those key uses
are exercised. Earlier versions of TCPCL can mandate use of the bits
keyEncipherment or keyAgreement.
When allowed by CA policy, a TCPCL end-entity certificate SHOULD When allowed by CA policy, a TCPCL end-entity certificate SHOULD
contain an Online Certificate Status Protocol (OCSP) URI within an contain an Online Certificate Status Protocol (OCSP) URI within an
Authority Information Access extension in accordance with Authority Information Access extension in accordance with
Section 4.2.2.1 of [RFC5280]. Section 4.2.2.1 of [RFC5280].
4.4.3. TLS Handshake 4.4.3. TLS Handshake
The use of TLS is negotiated 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
skipping to change at page 32, line 31 skipping to change at page 32, line 46
Failure: Indicating that one or more such claims are present and Failure: Indicating that one or more such claims are present and
none match the peer identity. none match the peer identity.
4.4.4.1. Certificate Path and Purpose Validation 4.4.4.1. Certificate Path and Purpose Validation
For any peer end-entity certificate received during TLS handshake, For any peer end-entity certificate received during TLS handshake,
the entity SHALL perform the certification path validation of the entity SHALL perform the certification path validation of
[RFC5280] up to one of the entity's trusted CA certificates. If [RFC5280] up to one of the entity's trusted CA certificates. If
enabled by local policy, the entity SHALL perform an OCSP check of enabled by local policy, the entity SHALL perform an OCSP check of
each certificate providing OCSP authoritiy information in accordance each certificate providing OCSP authority information in accordance
with [RFC6960]. If certificate validation fails or if security with [RFC6960]. If certificate validation fails or if security
policy disallows a certificate for any reason, the entity SHALL fail policy disallows a certificate for any reason, the entity SHALL fail
the TLS handshake with a "bad_certificate" alert. Leaving out part the TLS handshake with a "bad_certificate" alert. Leaving out part
of the certification chain can cause the entity to fail to validate a of the certification chain can cause the entity to fail to validate a
certificate if the left-out certificates are unknown to the entity certificate if the left-out certificates are unknown to the entity
(see Section 8.6). (see Section 8.6).
For the end-entity peer certificate received during TLS handshake, For the end-entity peer certificate received during TLS handshake,
the entity SHALL apply security policy to the Key Usage extension (if the entity SHALL apply security policy to the Key Usage extension (if
present) and Extended Key Usage extension (if present) in accordance present) and Extended Key Usage extension (if present) in accordance
skipping to change at page 40, line 49 skipping to change at page 41, line 49
5.1. Upkeep and Status Messages 5.1. Upkeep and Status Messages
5.1.1. Session Upkeep (KEEPALIVE) 5.1.1. Session Upkeep (KEEPALIVE)
The protocol includes a provision for transmission of KEEPALIVE The protocol includes a provision for transmission of KEEPALIVE
messages over the TCPCL session to help determine if the underlying messages over the TCPCL session to help determine if the underlying
TCP connection has been disrupted. TCP connection has been disrupted.
As described in Section 4.3, a negotiated parameter of each session As described in Section 4.3, a negotiated parameter of each session
is the Session Keepalive interval. If the negotiated Session is the Session Keepalive interval. If the negotiated Session
Keepalive is zero (i.e., one or both contact headers contains a zero Keepalive is zero (i.e., one or both SESS_INIT messages contains a
Keepalive Interval), then the keepalive feature is disabled. There zero Keepalive Interval), then the keepalive feature is disabled.
is no logical minimum value for the keepalive interval (within the There is no logical minimum value for the keepalive interval (within
minimum imposed by the positive-value encoding), but when used for the minimum imposed by the positive-value encoding), but when used
many sessions on an open, shared network a short interval could lead for many sessions on an open, shared network a short interval could
to excessive traffic. For shared network use, entities SHOULD choose lead to excessive traffic. For shared network use, entities SHOULD
a keepalive interval no shorter than 30 seconds. There is no logical choose a keepalive interval no shorter than 30 seconds. There is no
maximum value for the keepalive interval (within the maximum imposed logical maximum value for the keepalive interval (within the maximum
by the fixed-size encoding), but an idle TCP connection is liable for imposed by the fixed-size encoding), but an idle TCP connection is
closure by the host operating system if the keepalive time is longer liable for closure by the host operating system if the keepalive time
than tens-of-minutes. Entities SHOULD choose a keepalive interval no is longer than tens-of-minutes. Entities SHOULD choose a keepalive
longer than 10 minutes (600 seconds). interval no longer than 10 minutes (600 seconds).
Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP
retransmissions MAY occur in case of packet loss. Those will have to retransmissions MAY occur in case of packet loss. Those will have to
be triggered by a timeout (TCP retransmission timeout (RTO)), which be triggered by a timeout (TCP retransmission timeout (RTO)), which
is dependent on the measured RTT for the TCP connection so that is dependent on the measured RTT for the TCP connection so that
KEEPALIVE messages can experience noticeable latency. KEEPALIVE messages can experience noticeable latency.
The format of a KEEPALIVE message is a one-octet message type code of The format of a KEEPALIVE message is a one-octet message type code of
KEEPALIVE (as described in Table 2) with no additional data. Both KEEPALIVE (as described in Table 2) with no additional data. Both
sides SHALL send a KEEPALIVE message whenever the negotiated interval sides SHALL send a KEEPALIVE message whenever the negotiated interval
skipping to change at page 55, line 20 skipping to change at page 56, line 20
implementation and configuration matter. implementation and configuration matter.
If there is a configured time to terminate idle sessions and if no If there is a configured time to terminate idle sessions and if no
TCPCL messages (other than KEEPALIVE messages) has been received for TCPCL messages (other than KEEPALIVE messages) has been received for
at least that amount of time, then either entity MAY terminate the at least that amount of time, then either entity MAY terminate the
session by transmitting a SESS_TERM message indicating the reason session by transmitting a SESS_TERM message indicating the reason
code of "Idle timeout" (as described in Table 9). code of "Idle timeout" (as described in Table 9).
7. Implementation Status 7. Implementation Status
This section is to be removed before publishing as an RFC.
[NOTE to the RFC Editor: please remove this section before [NOTE to the RFC Editor: please remove this section before
publication, as well as the reference to [RFC7942] and publication, as well as the reference to [RFC7942],
[github-dtn-bpbis-tcpcl].] [github-dtn-demo-agent], and [github-dtn-wireshark].]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations can features. Readers are advised to note that other implementations can
exist. exist.
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 intended created as a GitHub project [github-dtn-demo-agent] and is intended
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.
A wireshark dissector for TCPCLv4 has been created as a GitHub
project [github-dtn-wireshark] and has been kept in-sync with the
latest encoding of this specification.
8. Security Considerations 8. Security Considerations
This section separates security considerations into threat categories This section separates security considerations into threat categories
based on guidance of BCP 72 [RFC3552]. based on guidance of BCP 72 [RFC3552].
8.1. Threat: Passive Leak of Node Data 8.1. Threat: Passive Leak of Node Data
When used without TLS security, the TCPCL exposes the Node ID and When used without TLS security, the TCPCL exposes the Node ID and
other configuration data to passive eavesdroppers. This occurs even other configuration data to passive eavesdroppers. This occurs even
when no transfers occur within a TCPCL session. This can be avoided when no transfers occur within a TCPCL session. This can be avoided
skipping to change at page 60, line 10 skipping to change at page 61, line 10
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.11. Mandatory-to-Implement TLS 8.11. Mandatory-to-Implement TLS
Following IETF best current practice, TLS is mandatory to implement Following IETF best current practice, TLS is mandatory to implement
for all TCPCL implementations but TLS is optional to use for a given for all TCPCL implementations but TLS is optional to use for a given
TCPCL session. The recommended configuration of Section 4.2 is to TCPCL session. The recommended configuration of Section 4.2 is to
always enable TLS, but entites are permitted to disable TLS based on always enable TLS, but entities are permitted to disable TLS based on
local configration. The configuration to enable or disable TLS for local configuration. The configuration to enable or disable TLS for
an entity or a session is outside of the scope of this document. The an entity or a session is outside of the scope of this document. The
configuration to disable TLS is different from the threat of TLS configuration to disable TLS is different from the threat of TLS
stripping described in Section 8.4. stripping described in Section 8.4.
8.12. Alternate Uses of TLS 8.12. Alternate Uses of TLS
This specification makes use of PKIX 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
skipping to change at page 68, line 39 skipping to change at page 69, line 39
identifying DTN endpoints as in the following table. identifying DTN endpoints as in the following table.
+=========+======================+=====================+ +=========+======================+=====================+
| Decimal | Description | References | | Decimal | Description | References |
+=========+======================+=====================+ +=========+======================+=====================+
| KP-TBD | id-kp-bundleSecurity | This specification. | | KP-TBD | id-kp-bundleSecurity | This specification. |
+---------+----------------------+---------------------+ +---------+----------------------+---------------------+
Table 18 Table 18
This also corresponds with the following SMI for that key purpose: This also corresponds with the following SMI, in ASN.1 syntax of
[X.680], for that key purpose:
<CODE BEGINS> <CODE BEGINS>
id-kp-bundleSecurity OBJECT IDENTIFIER ::= { id-kp-bundleSecurity OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) KP-TBD } security(5) mechanisms(5) pkix(7) kp(3) KP-TBD }
<CODE ENDS> <CODE ENDS>
10. Acknowledgments 10. Acknowledgments
This specification is based on comments on implementation of This specification is based on comments on implementation of
skipping to change at page 70, line 40 skipping to change at page 71, line 40
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 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[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", Work in Progress, Internet-Draft, draft-ietf- Version 7", Work in Progress, Internet-Draft, draft-ietf-
dtn-bpbis-29, 17 November 2020, dtn-bpbis-30, 10 December 2020,
<https://tools.ietf.org/html/draft-ietf-dtn-bpbis-29>. <https://tools.ietf.org/html/draft-ietf-dtn-bpbis-30>.
[X.680] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2015, August 2015,
<https://www.itu.int/rec/T-REC-X.680-201508-I/en>.
11.2. Informative References 11.2. Informative References
[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>.
[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,
skipping to change at page 72, line 23 skipping to change at page 73, line 33
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[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", Work in Progress, Internet-Draft, draft- Specification", Work in Progress, Internet-Draft, draft-
ietf-dtn-bpsec-25, 1 December 2020, ietf-dtn-bpsec-26, 8 January 2021,
<https://tools.ietf.org/html/draft-ietf-dtn-bpsec-25>. <https://tools.ietf.org/html/draft-ietf-dtn-bpsec-26>.
[I-D.ietf-dtn-bibect] [I-D.ietf-dtn-bibect]
Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in
Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18
February 2020, February 2020,
<https://tools.ietf.org/html/draft-ietf-dtn-bibect-03>. <https://tools.ietf.org/html/draft-ietf-dtn-bibect-03>.
[github-dtn-bpbis-tcpcl] [github-dtn-demo-agent]
Sipos, B., "TCPCL Example Implementation", Sipos, B., "TCPCL Example Implementation",
<https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/>. <https://github.com/BSipos-RKF/dtn-demo-agent/>.
[github-dtn-wireshark]
Sipos, B., "TCPCL Wireshark Dissector",
<https://github.com/BSipos-RKF/dtn-wireshark/>.
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:
* Split Contact Header into pre-TLS protocol negotiation and * 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.
 End of changes. 27 change blocks. 
99 lines changed or deleted 128 lines changed or added

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