--- 1/draft-ietf-dtn-tcpclv4-19.txt 2020-05-15 15:13:05.616457243 -0700 +++ 2/draft-ietf-dtn-tcpclv4-20.txt 2020-05-15 15:13:05.752460709 -0700 @@ -1,22 +1,22 @@ Delay Tolerant Networking B. Sipos Internet-Draft RKF Engineering Intended status: Standards Track M. Demmer -Expires: September 8, 2020 UC Berkeley +Expires: November 14, 2020 UC Berkeley J. Ott Aalto University S. Perreault - March 7, 2020 + May 13, 2020 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 - draft-ietf-dtn-tcpclv4-19 + draft-ietf-dtn-tcpclv4-20 Abstract This document describes a TCP-based convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides a reliable transport of such bundles. @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 8, 2020. + This Internet-Draft will expire on November 14, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -93,23 +93,23 @@ 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 47 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 47 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 50 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 50 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 51 8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 51 8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 51 8.4. Threat: Transport Security Stripping . . . . . . . . . . 51 - 8.5. Threat: Weak Ciphersuite Downgrade . . . . . . . . . . . 52 - 8.6. Threat: Invalid Certificate Use . . . . . . . . . . . . . 52 - 8.7. Threat: Symmetric Key Overuse . . . . . . . . . . . . . . 52 + 8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 52 + 8.6. Threat: Certificate Validation Vulnerabilities . . . . . 52 + 8.7. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 52 8.8. Threat: BP Node Impersonation . . . . . . . . . . . . . . 52 8.9. Threat: Denial of Service . . . . . . . . . . . . . . . . 53 8.10. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 54 8.10.1. TLS Without Authentication . . . . . . . . . . . . . 54 8.10.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 54 8.11. Predictability of Transfer IDs . . . . . . . . . . . . . 54 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 55 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 55 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 56 @@ -2273,48 +2273,48 @@ The purpose of the CAN_TLS flag is to allow the use of TCPCL on entities which simply do not have a TLS implementation available. When TLS is available on an entity, it is strongly encouraged that the security policy disallow non-TLS sessions. This requires that the TLS handshake occurs, regardless of the policy-driven parameters of the handshake and policy-driven handling of the handshake outcome. The negotiated use of TLS is identical behavior to STARTTLS use in [RFC2595] and [RFC4511]. -8.5. Threat: Weak Ciphersuite Downgrade +8.5. Threat: Weak TLS Configurations Even when using TLS to secure the TCPCL session, the actual ciphersuite negotiated between the TLS peers can be insecure. Recommendations for ciphersuite use are included in BCP 195 [RFC7525]. It is up to security policies within each TCPCL node to ensure that the negotiated TLS ciphersuite meets transport security requirements. -8.6. Threat: Invalid Certificate Use +8.6. Threat: Certificate Validation Vulnerabilities Even when TLS itself is operating properly an attacker can attempt to exploit vulnerabilities within certificate check algorithms or configuration to establish a secure TCPCL session using an invalid certificate. A BP agent treats the peer Node ID within a TCPCL session as authoritative and an invalid certificate exploit could lead to bundle data leaking and/or denial of service to the Node ID being impersonated. There are many reasons, described in [RFC5280], why a certificate can fail to validate, including using the certificate outside of its valid time interval, using purposes for which it was not authorized, or using it after it has been revoked by its CA. Validating a certificate is a complex task and can require network connectivity outside of the primary TCPCL network path(s) if a mechanism such as the Online Certificate Status Protocol (OCSP) is used by the CA. The configuration and use of particular certificate validation methods are outside of the scope of this document. -8.7. Threat: Symmetric Key Overuse +8.7. Threat: Symmetric Key Limits Even with a secure block cipher and securely-established session keys, there are limits to the amount of plaintext which can be safely encrypted with a given set of keys as described in [AEAD-LIMITS]. When permitted by the negotiated TLS version (see [RFC8446]), it is advisable to take advantage of session key updates to avoid those limits. When key updates are not possible, renegotiation of the TLS connection or establishing new TCPCL/TLS session are alternatives to limit session key use. @@ -2399,21 +2399,22 @@ following subsections give examples of alternate TLS uses. 8.10.1. TLS Without Authentication In environments where PKI is available but there are restrictions on the issuance of certificates (including the contents of certificates), it may be possible to make use of TLS in a way which authenticates only the passive entity of a TCPCL session or which does not authenticate either entity. Using TLS in a way which does not authenticate both peer entities of each TCPCL session is outside - of the scope of this document. + of the scope of this document but does have similar properties to the + opportunistic security model of [RFC7435]. 8.10.2. Non-Certificate TLS Use In environments where PKI is unavailable, alternate uses of TLS which do not require certificates such as pre-shared key (PSK) authentication [RFC5489] and the use of raw public keys [RFC7250] are available and can be used to ensure confidentiality within TCPCL. Using non-PKI node authentication methods is outside of the scope of this document. @@ -2750,22 +2751,22 @@ This specification is based on comments on implementation of [RFC7242] provided from Scott Burleigh. 11. References 11.1. Normative References [I-D.ietf-dtn-bpbis] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol - Version 7", draft-ietf-dtn-bpbis-23 (work in progress), - February 2020. + Version 7", draft-ietf-dtn-bpbis-24 (work in progress), + March 2020. [IANA-BUNDLE] IANA, "Bundle Protocol", . [IANA-PORTS] IANA, "Service Name and Transport Protocol Port Number Registry", . @@ -2831,21 +2832,21 @@ Luykx, A. and K. Paterson, "Limits on Authenticated Encryption Use in TLS", August 2017, . [github-dtn-bpbis-tcpcl] Sipos, B., "TCPCL Example Implementation", . [I-D.ietf-dtn-bpsec] Birrane, E. and K. McKeever, "Bundle Protocol Security - Specification", draft-ietf-dtn-bpsec-21 (work in + Specification", draft-ietf-dtn-bpsec-22 (work in progress), March 2020. [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, .