draft-ietf-dtn-tcpclv4-23.txt   draft-ietf-dtn-tcpclv4-24.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: 18 May 2021 UC Berkeley Expires: 7 June 2021 UC Berkeley
J. Ott J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
14 November 2020 4 December 2020
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-23 draft-ietf-dtn-tcpclv4-24
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 18 May 2021. This Internet-Draft will expire on 7 June 2021.
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 (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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . 12
3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 13 3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 13
3.4. PKIX Environments and CA Policy . . . . . . . . . . . . . 19 3.4. PKIX Environments and CA Policy . . . . . . . . . . . . . 19
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. TLS Handshake . . . . . . . . . . . . . . . . . . . . 29 4.4.2. Certificate Profile for TCPCL . . . . . . . . . . . . 29
4.4.3. TLS Authentication . . . . . . . . . . . . . . . . . 31 4.4.3. TLS Handshake . . . . . . . . . . . . . . . . . . . . 30
4.4.4. Example TLS Initiation . . . . . . . . . . . . . . . 32 4.4.4. TLS Authentication . . . . . . . . . . . . . . . . . 31
4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 34 4.4.5. Policy Recommendations . . . . . . . . . . . . . . . 33
4.6. Session Initialization Message (SESS_INIT) . . . . . . . 35 4.4.6. Example TLS Initiation . . . . . . . . . . . . . . . 33
4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 37 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 35
4.8. Session Extension Items . . . . . . . . . . . . . . . . . 38 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 36
5. Established Session Operation . . . . . . . . . . . . . . . . 39 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 38
5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 39 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 39
5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 39 5. Established Session Operation . . . . . . . . . . . . . . . . 40
5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 40 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 40
5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 42 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 40
5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 43 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 41
5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 43 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 43
5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 45 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 44
5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 47 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 44
5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 49 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 46
6. Session Termination . . . . . . . . . . . . . . . . . . . . . 51 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 48
6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 51 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 50
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 54
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 54 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 52
8. Security Considerations . . . . . . . . . . . . . . . . . . . 54 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 52
8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 55 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 55
8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 55 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 55
8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 55 8. Security Considerations . . . . . . . . . . . . . . . . . . . 55
8.4. Threat: Transport Security Stripping . . . . . . . . . . 55 8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 56
8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 56 8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 56
8.6. Threat: Untrusted End-Entity Certificate . . . . . . . . 56 8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 56
8.7. Threat: Certificate Validation Vulnerabilities . . . . . 56 8.4. Threat: Transport Security Stripping . . . . . . . . . . 56
8.8. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 57 8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 57
8.9. Threat: BP Node Impersonation . . . . . . . . . . . . . . 57 8.6. Threat: Untrusted End-Entity Certificate . . . . . . . . 57
8.10. Threat: Denial of Service . . . . . . . . . . . . . . . . 57 8.7. Threat: Certificate Validation Vulnerabilities . . . . . 57
8.11. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 58 8.8. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 58
8.11.1. TLS Without Authentication . . . . . . . . . . . . . 59 8.9. Threat: BP Node Impersonation . . . . . . . . . . . . . . 58
8.11.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 59 8.10. Threat: Denial of Service . . . . . . . . . . . . . . . . 59
8.12. Predictability of Transfer IDs . . . . . . . . . . . . . 59 8.11. Mandatory-to-Implement TLS . . . . . . . . . . . . . . . 60
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 8.12. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 60
9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 60 8.12.1. TLS Without Authentication . . . . . . . . . . . . . 60
9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 60 8.12.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 60
9.3. Session Extension Types . . . . . . . . . . . . . . . . . 61 8.13. Predictability of Transfer IDs . . . . . . . . . . . . . 61
9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 63 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 61
9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 64 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 62
9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 65 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 63
9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 66 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 63
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 64
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 65
11.1. Normative References . . . . . . . . . . . . . . . . . . 67 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 66
11.2. Informative References . . . . . . . . . . . . . . . . . 69 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 67
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 71 9.9. Object Identifier for PKIX Extended Key Usage . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 68
11.1. Normative References . . . . . . . . . . . . . . . . . . 69
11.2. Informative References . . . . . . . . . . . . . . . . . 70
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
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 22 skipping to change at page 5, line 27
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.
* Uses of TLS which are not based on PKIX certificate authentication * Uses of TLS which are not based on PKIX certificate authentication
(see Section 8.11.2) or in which authentication of both entities (see Section 8.12.2) or in which authentication of both entities
is not possible (see Section 8.11.1). is not possible (see Section 8.12.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 10, line 21 skipping to change at page 10, line 21
Connecting: A TCP connection is being established. This state Connecting: A TCP connection is being established. This state
only applies to the active entity. only applies to the active entity.
Contact Negotiating: A TCP connection has been made (as either Contact Negotiating: A TCP connection has been made (as either
active or passive entity) and contact negotiation has begun. active or passive entity) and contact negotiation has begun.
Session Negotiating: Contact negotiation has been completed Session Negotiating: Contact negotiation has been completed
(including possible TLS use) and session negotiation has begun. (including possible TLS use) and session negotiation has begun.
Established: The session has been fully established and is ready Established: The session has been fully established and is ready
for its first transfer. for its first transfer. When the session is established, the
peer Node ID (along with indication of whether or not it was
authenticated) and the negotiated session parameters (see
Section 4.7) are also communicated to the BP agent.
Ending: The entity sent SESS_TERM message and is in the ending Ending: The entity sent SESS_TERM message and is in the ending
state. state.
Terminated: The session has finished normal termination Terminated: The session has finished normal termination
sequencing. sequencing.
Failed: The session ended without normal termination sequencing. Failed: The session ended without normal termination sequencing.
Session Idle Changed: The TCPCL entity indicates to the BP agent Session Idle Changed: The TCPCL entity indicates to the BP agent
skipping to change at page 19, line 34 skipping to change at page 19, line 34
quite different PKIX environments: quite different PKIX environments:
DTN-Aware CAs: In the ideal case, the CA(s) issuing certificates for 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 TCPCL entities are aware of the end use of the certificate, have a
mechanism for verifying ownership of a Node ID, and are issuing mechanism for verifying ownership of a Node ID, and are issuing
certificates directly for that Node ID. In this environment, the certificates directly for that Node ID. In this environment, the
ability to authenticate a peer entity Node ID directly avoids the ability to authenticate a peer entity Node ID directly avoids the
need to authenticate a network name or address and then implicitly need to authenticate a network name or address and then implicitly
trust Node ID of the peer. The TCPCL authenticates the Node ID trust Node ID of the peer. The TCPCL authenticates the Node ID
whenever possible and this is preferred over lower-level PKIX whenever possible and this is preferred over lower-level PKIX
identifiers. identities.
DTN-Ignorant CAs: It is expected that Internet-scale "public" CAs DTN-Ignorant CAs: It is expected that Internet-scale "public" CAs
will continue to focus on DNS names as the preferred PKIX will continue to focus on DNS names as the preferred PKIX
identifier. There are large infrastructures already in-place for identifier. There are large infrastructures already in-place for
managing network-level authentication and protocols to manage managing network-level authentication and protocols to manage
identity verification in those environments [RFC8555]. The TCPCL identity verification in those environments [RFC8555]. The TCPCL
allows for this type of environment by authenticating a lower- allows for this type of environment by authenticating a lower-
level identifier for a peer and requiring the entity to trust that level identifier for a peer and requiring the entity to trust that
the Node ID given by the peer (during session initialization) is the Node ID given by the peer (during session initialization) is
valid. This situation not ideal, as it allows vulnerabilities valid. This situation is not ideal, as it allows vulnerabilities
described in Section 8.9, but still provides some amount of mutual described in Section 8.9, but still provides some amount of mutual
authentication to take place for a TCPCL session. authentication to take place for a TCPCL session.
Even within a single TCPCL session, each entity may operate within Even within a single TCPCL session, each entity may operate within
different PKI environments and with different identifier limitations. different PKI environments and with different identifier limitations.
The requirements related to identifiers in in a PKIX certificate are The requirements related to identifiers in in a PKIX certificate are
in Section 4.4.1. in Section 4.4.1.
It is important for interoperability that a TCPCL entity have its own It is important for interoperability that a TCPCL entity have its own
security policy tailored to accommodate the peers with which it is security policy tailored to accommodate the peers with which it is
expected to operate. A strict TLS security policy is appropriate for expected to operate. Some security policy recommendations are given
a private network with a single shared CA. Operation on the Internet in Section 4.4.5 but these are meant as a starting point for
(such as inter-site BP gateways) could trade more lax TCPCL security tailoring. A strict TLS security policy is appropriate for a private
with the use of encrypted bundle encapsulation [I-D.ietf-dtn-bibect] network with a single shared CA. Operation on the Internet (such as
to ensure strong bundle security. 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.
By using the Server Name Indication (SNI) DNS name (see
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
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
virtual host CL entity can be authenticated by a certificate
containing all of the DNS names and/or Node IDs being hosted or by
several certificates each authenticating a single DNS name and/or
Node ID, using the SNI value from the peer to select which
certificate to use.
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 25, line 26 skipping to change at page 25, line 26
Within this specification when an entity is said to "close" a TCP Within this specification when an entity is said to "close" a TCP
connection the entity SHALL use the TCP FIN mechanism and not the RST connection the entity SHALL use the TCP FIN mechanism and not the RST
mechanism. Either mechanism, however, when received will cause a TCP mechanism. Either mechanism, however, when received will cause a TCP
connection to become closed. connection to become closed.
4.2. Contact Header 4.2. Contact Header
This section describes the format of the Contact Header and the This section describes the format of the Contact Header and the
meaning of its fields. meaning of its fields.
If an entity is capable of exchanging messages according to TLS 1.3 If the entity is configured to enable exchanging messages according
[RFC8446] or any successors which are compatible with that TLS to TLS 1.3 [RFC8446] or any successors which are compatible with that
ClientHello, the the CAN_TLS flag within its Contact Header SHALL be TLS ClientHello, the the CAN_TLS flag within its Contact Header SHALL
set to 1. This behavior prefers the use of TLS when possible, even be set to 1. The RECOMMENDED policy is to enable TLS for all
if security policy does not allow or require authentication. This sessions, even if security policy does not allow or require
follows the opportunistic security model of [RFC7435], though an authentication. This follows the opportunistic security model of
active attacker could interfere with the exchange in such cases. [RFC7435], though an active attacker could interfere with the
exchange in such cases (see Section 8.4).
Upon receipt of the Contact Header, both entities perform the Upon receipt of the Contact Header, both entities perform the
validation and negotiation procedures defined in Section 4.3. After validation and negotiation procedures defined in Section 4.3. After
receiving the Contact Header from the other entity, either entity MAY receiving the Contact Header from the other entity, either entity MAY
refuse the session by sending a SESS_TERM message with an appropriate refuse the session by sending a SESS_TERM message with an appropriate
reason code. reason code.
The format for the Contact Header is as follows: The format for the Contact Header is as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
skipping to change at page 26, line 22 skipping to change at page 26, line 22
UTF-8). UTF-8).
Version: A one-octet field value containing the value 4 (current Version: A one-octet field value containing the value 4 (current
version of the TCPCL). version of the TCPCL).
Flags: A one-octet field of single-bit flags, interpreted according Flags: A one-octet field of single-bit flags, interpreted according
to the descriptions in Table 1. All reserved header flag bits to the descriptions in Table 1. All reserved header flag bits
SHALL be set to 0 by the sender. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits
SHALL be ignored by the receiver. SHALL be ignored by the receiver.
+==========+========+==========================================+ +==========+========+========================================+
| Name | Code | Description | | Name | Code | Description |
+==========+========+==========================================+ +==========+========+========================================+
| CAN_TLS | 0x01 | If bit is set, indicates that the | | CAN_TLS | 0x01 | If bit is set, indicates that the |
| | | sending peer is capable of TLS security. | | | | sending peer has enabled TLS security. |
+----------+--------+------------------------------------------+ +----------+--------+----------------------------------------+
| Reserved | others | | | Reserved | others | |
+----------+--------+------------------------------------------+ +----------+--------+----------------------------------------+
Table 1: Contact Header Flags Table 1: Contact Header Flags
4.3. Contact Validation and Negotiation 4.3. Contact Validation and Negotiation
Upon reception of the Contact Header, each entity follows the Upon reception of the Contact Header, each entity follows the
following procedures to ensure the validity of the TCPCL session and following procedures to ensure the validity of the TCPCL session and
to negotiate values for the session parameters. to negotiate values for the session parameters.
If the magic string is not present or is not valid, the connection If the magic string is not present or is not valid, the connection
skipping to change at page 27, line 37 skipping to change at page 27, line 37
negotiation have identical TCPCL Version numbers as described negotiation have identical TCPCL Version numbers as described
above. Only upon response of a Contact Header from the passive above. Only upon response of a Contact Header from the passive
entity is the TCPCL protocol version established and session entity is the TCPCL protocol version established and session
negotiation begun. negotiation begun.
Enable TLS: Negotiation of the Enable TLS parameter is performed by Enable TLS: Negotiation of the Enable TLS parameter is performed by
taking the logical AND of the two Contact Headers' CAN_TLS flags. taking the logical AND of the two Contact Headers' CAN_TLS flags.
A local security policy is then applied to determine of the A local security policy is then applied to determine of the
negotiated value of Enable TLS is acceptable. It can be a negotiated value of Enable TLS is acceptable. It can be a
reasonable security policy to require or disallow the use of TLS reasonable security policy to require or disallow the use of TLS
depending upon the desired network flows. Because this state is depending upon the desired network flows. The RECOMMENDED policy
is to require TLS for all sessions, even if security policy does
not allow or require authentication. Because this state is
negotiated over an unsecured medium, there is a risk of a TLS negotiated over an unsecured medium, there is a risk of a TLS
Stripping as described in Section 8. If the Enable TLS state is Stripping as described in Section 8.4.
unacceptable, the entity SHALL terminate the session with a reason
code of "Contact Failure". Note that this contact failure reason If the Enable TLS state is unacceptable, the entity SHALL
is different than a failure of TLS handshake or TLS authentication terminate the session with a reason code of "Contact Failure".
after an agreed-upon and acceptable Enable TLS state. If the Note that this contact failure reason is different than a failure
negotiated Enable TLS value is true and acceptable then TLS of TLS handshake or TLS authentication after an agreed-upon and
negotiation feature (described in Section 4.4) begins immediately acceptable Enable TLS state. If the negotiated Enable TLS value
following the Contact Header exchange. is true and acceptable then TLS negotiation feature (described in
Section 4.4) begins immediately following the Contact Header
exchange.
4.4. Session Security 4.4. Session Security
This version of the TCPCL supports establishing a Transport Layer This version of the TCPCL supports establishing a Transport Layer
Security (TLS) session within an existing TCP connection. When TLS Security (TLS) session within an existing TCP connection. When TLS
is used within the TCPCL it affects the entire session. Once TLS is is used within the TCPCL it affects the entire session. Once TLS is
established, there is no mechanism available to downgrade the TCPCL established, there is no mechanism available to downgrade the TCPCL
session to non-TLS operation. session to non-TLS operation.
Once established, the lifetime of a TLS connection SHALL be bound to Once established, the lifetime of a TLS connection SHALL be bound to
the lifetime of the underlying TCP connection. Immediately prior to the lifetime of the underlying TCP connection. Immediately prior to
actively ending a TLS connection after TCPCL session termination, the actively ending a TLS connection after TCPCL session termination, the
peer which sent the original (non-reply) SESS_TERM message SHOULD peer which sent the original (non-reply) SESS_TERM message SHOULD
follow the Closure Alert procedure of [RFC8446] to cleanly terminate follow the Closure Alert procedure of [RFC8446] to cleanly terminate
the TLS connection. Because each TCPCL message is either fixed- the TLS connection. Because each TCPCL message is either fixed-
length or self-indicates its length, the lack of a TLS Closure Alert length or self-indicates its length, the lack of a TLS Closure Alert
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 to use the TLS session 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 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
skipping to change at page 29, line 15 skipping to change at page 29, line 15
stable DNS names can be identified in the certificate. The use of stable DNS names can be identified in the certificate. The use of
wildcard DNS-ID is discouraged due to the complex rules for 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 (see Section 6.4.3 of [RFC6125]). matching (see Section 6.4.3 of [RFC6125]).
Network Address: If no stable DNS name is available but a stable Network Address: If no stable DNS 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 IPADDR-ID (as defined below) then one or more network contain a IPADDR-ID (as defined below) then one or more network
addresses can be identified in the certificate. addresses can be identified in the certificate.
When only a DNS-ID or IPADDR-ID can be identified by a certificate,
it is implied that an entity which authenticates using that
certificate is trusted to provide a valid Node ID in its SESS_INIT;
the certificate itself does not actually authenticate that Node ID.
The RECOMMENDED security policy of an entity is to validate a NODE-ID
when present, and only require DNS-ID/IPADDR-ID authentication in the
absence of a NODE-ID.
This specification defines a NODE-ID of a certificate as being the This specification defines a NODE-ID of a certificate as being the
subjectAltName entry of type uniformResourceIdentifier whose value is subjectAltName entry of type uniformResourceIdentifier whose value is
a URI consistent with the requirements of [RFC3986] and the URI a URI consistent with the requirements of [RFC3986] and the URI
schemes of the IANA "Bundle Protocol URI Scheme Type" registry schemes of the IANA "Bundle Protocol URI Scheme Type" registry
[IANA-BUNDLE]. This is similar to the URI-ID of [RFC6125] but does [IANA-BUNDLE]. This is similar to the URI-ID of [RFC6125] but does
not require any structure to the scheme-specific-part of the URI. not require any structure to the scheme-specific-part of the URI.
Unless specified otherwise by the definition of the URI scheme being Unless specified otherwise by the definition of the URI scheme being
authenticated, URI matching of a NODE-ID SHALL use the URI comparison authenticated, URI matching of a NODE-ID SHALL use the URI comparison
logic of [RFC3986] and scheme-based normalization of those schemes logic of [RFC3986] and scheme-based normalization of those schemes
specified in [I-D.ietf-dtn-bpbis]. A URI scheme can refine this specified in [I-D.ietf-dtn-bpbis]. A URI scheme can refine this
"exact match" logic with rules about how Node IDs within that scheme "exact match" logic with rules about how Node IDs within that scheme
are to be compared with the certificate-authenticated NODE-ID. are to be compared with the certificate-authenticated NODE-ID.
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. TLS Handshake 4.4.2. Certificate Profile for TCPCL
All end-entity certificates used by a TCPCL entity SHALL conform to
[RFC5280], or any updates or successors to that profile. When an
end-entity certificate is supplied, the full certification chain
SHOULD be included unless security policy indicates that is
unnecessary.
The TCPCL requires Version 3 certificates due to the extensions used
by this profile. TCPCL entities SHALL reject as invalid Version 1
and Version 2 end-entity certificates.
TCPCL entities SHALL accept certificates that contain an empty
Subject field or contain a Subject without a Common Name. Identity
information in end-entity certificates is contained entirely in the
subjectAltName extension as defined in Section 4.4.1 and below.
All end-entity and CA certificates used for TCPCL SHOULD contain both
a Subject Key Identifier and an Authority Key Identifier extension in
accordance with [RFC5280]. TCPCL entities SHOULD NOT rely on either
a Subject Key Identifier and an Authority Key Identifier being
present in any received certificate. Including key identifiers
simplifies the work of an entity needing to assemble a certification
chain.
Unless prohibited by CA policy, a TCPCL end-entity certificate SHALL
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
SHOULD contain DNS-ID which authenticates those (fully qualified)
names. When assigned one or more stable network addresss, a TCPCL
end-entity certificate MAY contain IPADDR-ID which authenticates
those addresses.
This document defines a PKIX Extended Key Usage key purpose "id-kp-
bundleSecurity" in Section 9.9 which MAY be used to restrict a
certificate's use. The "id-kp-bundleSecurity" purpose can be
combined with other purposes in the same certificate. Although not
specifically required by TCPCL, some 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:
digitalSignature, keyEncipherment, and keyAgreement. The specific
algorithms used during the TLS handshake will determine which of
those key uses are exercised.
When allowed by CA policy, a TCPCL end-entity certificate SHOULD
contain an Online Certificate Status Protocol (OCSP) URI within an
Authority Information Access extension in accordance with
Section 4.2.2.1 of [RFC5280].
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
before any other TCPCL messages are sent within the session, the before any other TCPCL messages are sent within the session, the
session entities SHALL begin a TLS handshake in accordance with session entities SHALL begin a TLS handshake in accordance with
[RFC8446]. By convention, this protocol uses the entity which [RFC8446]. By convention, this protocol uses the entity which
initiated the underlying TCP connection (the active peer) as the initiated the underlying TCP connection (the active peer) as the
"client" role of the TLS handshake request. "client" role of the TLS handshake request.
The TLS handshake, if it occurs, is considered to be part of the The TLS handshake, if it occurs, is considered to be part of the
contact negotiation before the TCPCL session itself is established. contact negotiation before the TCPCL session itself is established.
Specifics about sensitive data exposure are discussed in Section 8. Specifics about sensitive data exposure are discussed in Section 8.
The parameters within each TLS negotiation are implementation The parameters within each TLS negotiation are implementation
dependent but any TCPCL entity SHALL follow all recommended practices dependent but any TCPCL entity SHALL follow all recommended practices
of BCP 195 [RFC7525], or any updates or successors that become part of BCP 195 [RFC7525], or any updates or successors that become part
of BCP 195. Within each TLS handshake, the following requirements of BCP 195. Within each TLS handshake, the following requirements
apply (using the rough order in which they occur): apply (using the rough order in which they occur):
Client Hello: When a resolved DNS name was used to establish the TCP Client Hello: When a resolved DNS name was used to establish the TCP
connection, the TLS ClientHello SHOULD include a Server Name connection, the TLS ClientHello SHOULD include a "server_name"
Indication (SNI) in accordance with [RFC6066]. When present, the extension in accordance with [RFC6066]. When present, the
"server_name" extension SHALL contain a "HostName" value taken "server_name" extension SHALL contain a "HostName" value taken
from the DNS name (of the passive entity) which was resolved. from the DNS name (of the passive entity) which was resolved.
Note: The 'HostName in the "server_name" extension is the network Note: The "HostName" in the "server_name" extension is the network
name for the passive entity, not the Node ID of that entity. name for the passive entity, not the Node ID of that entity.
Server Certificate: The passive entity SHALL supply a certificate Server Certificate: The passive entity SHALL supply a certificate
within the TLS handshake to allow authentication of its side of within the TLS handshake to allow authentication of its side of
the session. Unless prohibited by CA policy, the passive entity the session. The supplied end-entity certificate SHALL conform to
certificate SHALL contain a NODE-ID which authenticates the Node the profile of Section 4.4.2. The passive entity MAY use the SNI
ID of the peer. When assigned a stable DNS name, the passive DNS name to choose an appropriate server-side certificate which
entity certificate SHOULD contain a DNS-ID which authenticates authenticates that DNS name.
that (fully qualified) name. When assigned a stable network
address, the passive entity certificate MAY contain a IPADDR-ID
which authenticates that address. The passive entity MAY use the
SNI DNS name to choose an appropriate server-side certificate
which authenticates that DNS name.
Certificate Request: During TLS handshake, the passive entity SHALL Certificate Request: During TLS handshake, the passive entity SHALL
request a client-side certificate. request a client-side certificate.
Client Certificate: The active entity SHALL supply a certificate Client Certificate: The active entity SHALL supply a certificate
chain within the TLS handshake to allow authentication of its side chain within the TLS handshake to allow authentication of its side
of the session. Unless prohibited by CA policy, the active entity of the session. The supplied end-entity certificate SHALL conform
certificate SHALL contain a NODE-ID which authenticates the Node to the profile of Section 4.4.2.
ID of the peer. When assigned a stable DNS name, the active
entity certificate SHOULD contain a DNS-ID which authenticates
that (fully qualified) name. When assigned a stable network
address, the active entity certificate MAY contain a IPADDR-ID
which authenticates that address.
All certificates supplied during TLS handshake SHALL conform to
[RFC5280], or any updates or successors to that profile. When a
certificate is supplied during TLS handshake, the full certification
chain SHOULD be included unless security policy indicates that is
unnecessary.
If a TLS handshake cannot negotiate a TLS connection, both entities If a TLS handshake cannot negotiate a TLS connection, both entities
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.4. TLS Authentication
Using PKIX certificates exchanged during the TLS handshake, each of Using PKIX certificates exchanged during the TLS handshake, each of
the entities can authenticate a peer Node ID directly or authenticate the entities can authenticate a peer Node ID directly or authenticate
the peer DNS name or network address. The logic for handling the peer DNS name or network address. The logic for handling
certificates and certificate data is separated into three phases: certificates and certificate data is separated into the following
phases:
1. Validating the certification path from the end-entity certificate 1. Validating the certification path from the end-entity certificate
up to a trusted root CA. up to a trusted root CA.
2. Authenticating identities from a valid end-entity certificate. 2. Validating the Extended Key Usage (EKU) and other properties of
the end-entity certificate.
3. Applying security policy to the result of each identity type 3. Authenticating identities from a valid end-entity certificate.
4. Applying security policy to the result of each identity type
authentication. authentication.
By using the SNI DNS name (see Section 4.4.2) a single passive entity The result of validating a peer identity (see Section 4.4.1) against
can act as a convergence layer for multiple BP agents with distinct one or more type of certificate claim is one of the following:
Node IDs. When this "virtual 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 virtual host CL entity can be
authenticated by a certificate containing all of the DNS names and/or
Node IDs being hosted or by several certificates each authenticating
a single DNS name and/or Node ID, using the SNI value from the peer
to select which certificate to use.
For any peer certificate received during TLS handshake, the entity Absent: Indicating that no such claims are present in the
SHALL perform the certification path validation of [RFC5280] up to certificate and the identity cannot be authenticated.
one of the entity's trusted CA certificates. If certificate
validation fails or if security policy disallows a certificate for
any reason, the entity SHALL fail the TLS handshake with a bad
certificate error. Leaving out part of the certification chain can
cause the entity to fail to validate a certificate if the left-out
certificates are unknown to the entity (see Section 8.6).
The result of authenticating a peer identity (i.e., Node ID, DNS Success: Indicating that one or more such claims are present and at
name, or IP address) against one type of certificate claim is one of: least one matches the peer identity value.
Absent: Indicating that no claims of that type are present in the Failure: Indicating that one or more such claims are present and
certificate and the identity cannot be authenticated. none match the peer identity.
Success: Indicating that one or more claims of that type are present 4.4.4.1. Certificate Path and Purpose Validation
and one matches the peer identity value.
Failure: Indicating that one or more claims of that type are present For any peer end-entity certificate received during TLS handshake,
and none match the peer identity. the entity SHALL perform the certification path validation of
[RFC5280] up to one of the entity's trusted CA certificates. If
enabled by local policy, the entity SHALL perform an OCSP check of
each certificate providing OCSP authoritiy information in accordance
with [RFC6960]. If certificate validation fails or if security
policy disallows a certificate for any reason, the entity SHALL fail
the TLS handshake with a "bad_certificate" alert. Leaving out part
of the certification chain can cause the entity to fail to validate a
certificate if the left-out certificates are unknown to the entity
(see Section 8.6).
Either during or immediately after the TLS handshake if the active For the end-entity peer certificate received during TLS handshake,
entity resolved a DNS name (of the passive entity) in order to the entity SHALL apply security policy to the Key Usage extension (if
initiate the TCP connection, the active entity SHALL authenticate present) and Extended Key Usage extension (if present) in accordance
that DNS name using any DNS-ID of the peer certificate. If the DNS with Section 4.2.1.12 of [RFC5280] and the profile in Section 4.4.2.
name authentication result is Failure or if the result is Absent and
security policy requires an authenticated DNS name, the entity SHALL
terminate the session (with a reason code of "Contact Failure").
Either during or immediately after the TLS handshake, each side of 4.4.4.2. Network-Level Authentication
the session SHALL authenticate the IP address of the other side of
the TCP connection using any IPADDR-ID of the peer certificate. If
the address authentication result is Failure or if the result is
Absent and security policy requires an authenticated network address,
the entity SHALL terminate the session (with a reason code of
"Contact Failure").
Immediately before Session Parameter Negotiation, each side of the Either during or immediately after the TLS handshake, if required by
session SHALL authenticate the Node ID of the peer's SESS_INIT security policy each entity SHALL validate the following certificate
message using any NODE-ID of the peer certificate. If the Node ID identifiers together in accordance with Section 6 of [RFC6125]:
authentication result is Failure or if the result is Absent and
* If the active entity resolved a DNS name (of the passive entity)
in order to initiate the TCP connection that DNS name SHALL be
used as a DNS-ID reference identifier.
* The IP address of the other side of the TCP connection SHALL be
used as an IPADDR-ID reference identifier.
If the network-level identifiers authentication result is Failure or
if the result is Absent and security policy requires an authenticated
network-level identifier, the entity SHALL terminate the session
(with a reason code of "Contact Failure").
4.4.4.3. Node ID Authentication
Immediately before Session Parameter Negotiation, if required by
security policy each entity SHALL validate the certificate NODE-ID in
accordance with Section 6 of [RFC6125] using the Node ID of the
peer's SESS_INIT message as the NODE-ID reference identifier. If the
NODE-ID validation result is Failure or if the result is Absent and
security policy requires an authenticated Node ID, the entity SHALL security policy requires an authenticated Node ID, the entity SHALL
terminate the session (with a reason code of "Contact Failure"). terminate the session (with a reason code of "Contact Failure").
4.4.4. Example TLS Initiation 4.4.5. Policy Recommendations
A RECOMMENDED security policy is to enable the use of OCSP checking
during TLS handshake. A RECOMMENDED security policy is that if an
Extended Key Usage is present that it needs to contain "id-kp-
bundleSecurity" (of Section 4.4.4.1) to be usable with TCPCL
security. A RECOMMENDED security policy is to require a validated
Node ID (of Section 4.4.4.3) and to ignore any network-level
identifier (of Section 4.4.4.2).
This policy relies on and informs the certificate requirements in
Section 4.4.3. This policy assumes that a DTN-aware CA (see
Section 3.4) will only issue a certificate for a Node ID when it has
verified that the private key holder actually controls the DTN node;
this is needed to avoid the threat identified in Section 8.9. This
policy requires that a certificate contain a NODE-ID and allows the
certificate to also contain network-level identifiers. A tailored
policy on a more controlled network could relax the requirement on
Node ID validation and allow just network-level identifiers to
authenticate a peer.
4.4.6. Example TLS Initiation
A summary of a typical TLS use is shown in the sequence in Figure 17 A summary of a typical TLS use is shown in the sequence in Figure 17
below. In this example the active peer terminates the session but below. In this example the active peer terminates the session but
termination can be initiated from either peer. termination can be initiated from either peer.
Entity A Entity B Entity A Entity B
active peer passive peer active peer passive peer
+-------------------------+ +-------------------------+
| Open TCP Connection | -> +-------------------------+ | Open TCP Connection | -> +-------------------------+
skipping to change at page 37, line 10 skipping to change at page 38, line 10
variable-length text string. The Node ID Length is a 16-bit variable-length text string. The Node ID Length is a 16-bit
unsigned integer indicating the number of octets of Node ID Data unsigned integer indicating the number of octets of Node ID Data
to follow. A zero-length Node ID SHALL be used to indicate the to follow. A zero-length Node ID SHALL be used to indicate the
lack of Node ID rather than a truly empty Node ID. This case lack of Node ID rather than a truly empty Node ID. This case
allows an entity to avoid exposing Node ID information on an allows an entity to avoid exposing Node ID information on an
untrusted network. A non-zero-length Node ID Data SHALL contain untrusted network. A non-zero-length Node ID Data SHALL contain
the UTF-8 encoded Node ID of the Entity which sent the SESS_INIT the UTF-8 encoded Node ID of the Entity which sent the SESS_INIT
message. Every Node ID SHALL be a URI consistent with the message. Every Node ID SHALL be a URI consistent with the
requirements of [RFC3986] and the URI schemes of the IANA "Bundle requirements of [RFC3986] and the URI schemes of the IANA "Bundle
Protocol URI Scheme Type" registry [IANA-BUNDLE]. The Node ID Protocol URI Scheme Type" registry [IANA-BUNDLE]. The Node ID
itself can be authenticated as described in Section 4.4.3. itself can be authenticated as described in Section 4.4.4.
Session Extension Length and Session Extension Items: Together these Session Extension Length and Session Extension Items: Together these
fields represent protocol extension data not defined by this fields represent protocol extension data not defined by this
specification. The Session Extension Length is the total number specification. The Session Extension Length is the total number
of octets to follow which are used to encode the Session Extension of octets to follow which are used to encode the Session Extension
Item list. The encoding of each Session Extension Item is within Item list. The encoding of each Session Extension Item is within
a consistent data container as described in Section 4.8. The full a consistent data container as described in Section 4.8. The full
set of Session Extension Items apply for the duration of the TCPCL set of Session Extension Items apply for the duration of the TCPCL
session to follow. The order and multiplicity of these Session session to follow. The order and multiplicity of these Session
Extension Items is significant, as defined in the associated type Extension Items is significant, as defined in the associated type
specification(s). If the content of the Session Extension Items specification(s). If the content of the Session Extension Items
data disagrees with the Session Extension Length (e.g., the last data disagrees with the Session Extension Length (e.g., the last
Item claims to use more octets than are present in the Session Item claims to use more octets than are present in the Session
Extension Length), the reception of the SESS_INIT is considered to Extension Length), the reception of the SESS_INIT is considered to
have failed. have failed.
If an entity receives a peer Node ID which is not authenticated (by
the procedure of Section 4.4.4.3) that Node ID SHOULD NOT be used by
a BP agent for any discovery or routing functions. Trusting an
unauthenticated Node ID can lead to the threat described in
Section 8.9.
When the active entity initiates a TCPCL session, it is likely based When the active entity initiates a TCPCL session, it is likely based
on routing information which binds a Node ID to CL parameters. If on routing information which binds a Node ID to CL parameters used to
the active entity receives a SESS_INIT with different Node ID than initiate the session. If the active entity receives a SESS_INIT with
was intended for the TCPCL session, the session MAY be allowed to be different Node ID than was intended for the TCPCL session, the
established. If allowed, such a session SHALL be associated with the session MAY be allowed to be established. If allowed, such a session
Node ID provided in the SESS_INIT message rather than any intended SHALL be associated with the Node ID provided in the SESS_INIT
value. message rather than any intended value.
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 SESS_INIT it sent to the peer) with the preferences of the peer
entity (expressed in the SESS_INIT that it received from the peer). entity (expressed in the SESS_INIT that it received from the peer).
The negotiated parameters defined by this specification are described The negotiated parameters defined by this specification are described
in the following paragraphs. in the following paragraphs.
skipping to change at page 43, line 27 skipping to change at page 44, line 27
receiving entity uses that same Transfer ID in acknowledgements. receiving entity uses that same Transfer ID in acknowledgements.
Transfer IDs from each entity SHALL be unique within a single TCPCL Transfer IDs from each entity SHALL be unique within a single TCPCL
session. Upon exhaustion of the entire 64-bit Transfer ID space, the session. Upon exhaustion of the entire 64-bit Transfer ID space, the
sending entity SHALL terminate the session with SESS_TERM reason code sending entity SHALL terminate the session with SESS_TERM reason code
"Resource Exhaustion". For bidirectional bundle transfers, a TCPCL "Resource Exhaustion". For bidirectional bundle transfers, a TCPCL
entity SHOULD NOT rely on any relation between Transfer IDs entity SHOULD NOT rely on any relation between Transfer IDs
originating from each side of the TCPCL session. originating from each side of the TCPCL session.
Although there is not a strict requirement for Transfer ID initial Although there is not a strict requirement for Transfer ID initial
values or ordering (see Section 8.12), in the absence of any other values or ordering (see Section 8.13), in the absence of any other
mechanism for generating Transfer IDs an entity SHALL use the mechanism for generating Transfer IDs an entity SHALL use the
following algorithm: The initial Transfer ID from each entity is zero following algorithm: The initial Transfer ID from each entity is zero
and subsequent Transfer ID values are incremented from the prior and subsequent Transfer ID values are incremented from the prior
Transfer ID value by one. Transfer ID value by one.
5.2.2. Data Transmission (XFER_SEGMENT) 5.2.2. Data Transmission (XFER_SEGMENT)
Each bundle is transmitted in one or more data segments. The format Each bundle is transmitted in one or more data segments. The format
of a XFER_SEGMENT message follows in Figure 22. of a XFER_SEGMENT message follows in Figure 22.
skipping to change at page 55, line 11 skipping to change at page 56, line 11
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
by always using TLS, even if authentication is not available (see by always using TLS, even if authentication is not available (see
Section 8.11). Section 8.12).
8.2. Threat: Passive Leak of Bundle Data 8.2. Threat: Passive Leak of Bundle Data
TCPCL can be used to provide point-to-point transport security, but TCPCL can be used to provide point-to-point transport security, but
does not provide security of data-at-rest and does not guarantee end- does not provide security of data-at-rest and does not guarantee end-
to-end bundle security. The bundle security mechanisms defined in to-end bundle security. The bundle security mechanisms defined in
[I-D.ietf-dtn-bpsec] are to be used instead. [I-D.ietf-dtn-bpsec] are to be used instead.
When used without TLS security, the TCPCL exposes all bundle data to When used without TLS security, the TCPCL exposes all bundle data to
passive eavesdroppers. This can be avoided by always using TLS, even passive eavesdroppers. This can be avoided by always using TLS, even
if authentication is not available (see Section 8.11). if authentication is not available (see Section 8.12).
8.3. Threat: TCPCL Version Downgrade 8.3. Threat: TCPCL Version Downgrade
When a TCPCL entity supports multiple versions of the protocol it is When a TCPCL entity supports multiple versions of the protocol it is
possible for a malicious or misconfigured peer to use an older possible for a malicious or misconfigured peer to use an older
version of TCPCL which does not support transport security. A man- version of TCPCL which does not support transport security. A on-
in-the-middle attacker can also manipulate a Contact Header to path attacker can also manipulate a Contact Header to present a lower
present a lower protocol version than desired. protocol version than desired.
It is up to security policies within each TCPCL entity to ensure that It is up to security policies within each TCPCL entity to ensure that
the negotiated TCPCL version meets transport security requirements. the negotiated TCPCL version meets transport security requirements.
8.4. Threat: Transport Security Stripping 8.4. Threat: Transport Security Stripping
When security policy allows non-TLS sessions, TCPCL does not protect When security policy allows non-TLS sessions, TCPCL does not protect
against active network attackers. It is possible for a man-in-the- against active network attackers. It is possible for a on-path
middle attacker to set the CAN_TLS flag to 0 on either side of the attacker to set the CAN_TLS flag to 0 on either side of the Contact
Contact Header exchange. This leads to the "SSL Stripping" attack Header exchange, which will cause the negotiation of Section 4.3 to
described in [RFC7457]. disable TLS. This leads to the "SSL Stripping" attack described in
[RFC7457].
The purpose of the CAN_TLS flag is to allow the use of TCPCL on 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. entities which simply do not have a TLS implementation available.
When TLS is available on an entity, it is strongly encouraged that When TLS is available on an entity, it is strongly encouraged that
the security policy disallow non-TLS sessions. This requires that the security policy disallow non-TLS sessions. This requires that
the TLS handshake occurs, regardless of the policy-driven parameters the TLS handshake occurs, regardless of the policy-driven parameters
of the handshake and policy-driven handling of the handshake outcome. of the handshake and policy-driven handling of the handshake outcome.
One mechanism to mitigate the possibility of TLS stripping is the use One mechanism to mitigate the possibility of TLS stripping is the use
of DNS-based Authentication of Named Entities (DANE) [RFC6698] for of DNS-based Authentication of Named Entities (DANE) [RFC6698] toward
the passive peer. This mechanism relies on DNS and is the passive peer. This mechanism relies on DNS and is
unidirectional, so it doesn't help with applying policy toward the unidirectional, so it doesn't help with applying policy toward the
active peer, but it can be useful in an environment using active peer, but it can be useful in an environment using
opportunistic security. The configuration and use of DANE are are opportunistic security. The configuration and use of DANE are
outside of the scope of this document. outside of the scope of this document.
The negotiated use of TLS is identical behavior to STARTTLS use in The negotiated use of TLS is identical behavior to STARTTLS use in
[RFC2595] and [RFC4511]. [RFC2595], [RFC4511], and others.
8.5. Threat: Weak TLS Configurations 8.5. Threat: Weak TLS Configurations
Even when using TLS to secure the TCPCL session, the actual Even when using TLS to secure the TCPCL session, the actual
ciphersuite negotiated between the TLS peers can be insecure. ciphersuite negotiated between the TLS peers can be insecure.
Recommendations for ciphersuite use are included in BCP 195 Recommendations for ciphersuite use are included in BCP 195
[RFC7525]. It is up to security policies within each TCPCL entity to [RFC7525]. It is up to security policies within each TCPCL entity to
ensure that the negotiated TLS ciphersuite meets transport security ensure that the negotiated TLS ciphersuite meets transport security
requirements. requirements.
8.6. Threat: Untrusted End-Entity Certificate 8.6. Threat: Untrusted End-Entity Certificate
The profile in Section 4.4.3 uses end-entity certificates chained up The profile in Section 4.4.4 uses end-entity certificates chained up
to a trusted root CA. During TLS handshake, either entity can send a to a trusted root CA. During TLS handshake, either entity can send a
certificate set which does not contain the full chain, possibly certificate set which does not contain the full chain, possibly
excluding intermediate or root CAs. In an environment where peers excluding intermediate or root CAs. In an environment where peers
are known to already contain needed root and intermediate CAs there are known to already contain needed root and intermediate CAs there
is no need to include those CAs, but this has a risk of an entity not is no need to include those CAs, but this has a risk of an entity not
actually having one of the needed CAs. actually having one of the needed CAs.
8.7. Threat: Certificate Validation Vulnerabilities 8.7. Threat: Certificate Validation Vulnerabilities
Even when TLS itself is operating properly an attacker can attempt to Even when TLS itself is operating properly an attacker can attempt to
exploit vulnerabilities within certificate check algorithms or exploit vulnerabilities within certificate check algorithms or
configuration to establish a secure TCPCL session using an invalid configuration to establish a secure TCPCL session using an invalid
certificate. A BP agent treats the peer Node ID within a TCPCL certificate. A BP agent treats the peer Node ID within a TCPCL
session as authoritative and an invalid certificate exploit could session as authoritative and an invalid certificate exploit could
lead to bundle data leaking and/or denial of service to the Node ID lead to bundle data leaking and/or denial of service to the Node ID
being impersonated. There are many reasons, described in [RFC5280], being impersonated.
why a certificate can fail to validate, including using the
certificate outside of its valid time interval, using purposes for There are many reasons, described in [RFC5280] and [RFC6125], why a
which it was not authorized, or using it after it has been revoked by certificate can fail to validate, including using the certificate
its CA. Validating a certificate is a complex task and can require outside of its valid time interval, using purposes for which it was
network connectivity outside of the primary TCPCL network path(s) if not authorized, or using it after it has been revoked by its CA.
a mechanism such as the Online Certificate Status Protocol (OCSP) Validating a certificate is a complex task and can require network
[RFC6960] is used by the CA. The configuration and use of particular connectivity outside of the primary TCPCL network path(s) if a
certificate validation methods are outside of the scope of this mechanism such as OCSP [RFC6960] is used by the CA. The
document. configuration and use of particular certificate validation methods
are outside of the scope of this document.
8.8. Threat: Symmetric Key Limits 8.8. Threat: Symmetric Key Limits
Even with a secure block cipher and securely-established session Even with a secure block cipher and securely-established session
keys, there are limits to the amount of plaintext which can be safely 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]. encrypted with a given set of keys as described in [AEAD-LIMITS].
When permitted by the negotiated TLS version (see [RFC8446]), it is When permitted by the negotiated TLS version (see [RFC8446]), it is
advisable to take advantage of session key updates to avoid those advisable to take advantage of session key updates to avoid those
limits. limits.
8.9. Threat: BP Node Impersonation 8.9. Threat: BP Node Impersonation
The certificates exchanged by TLS enable authentication of peer DNS The certificates exchanged by TLS enable authentication of peer DNS
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 DNS name or Node ID of the peer (see Section 3.4). Having a CA- the DNS-ID/IPADDR-ID or NODE-ID of the peer (see Section 3.4).
validated certificate does not alone guarantee the identity of the Having a CA-validated certificate does not alone guarantee the
network host or BP node from which the certificate is provided; identity of the network host or BP node from which the certificate is
additional validation procedures in Section 4.4.2 bind the DNS name provided; additional validation procedures in Section 4.4.3 bind the
or Node ID based on the contents of the certificate. DNS-ID/IPADDR-ID or NODE-ID based on the contents of the certificate.
The DNS name validation is a weaker form of authentication, because The DNS-ID/IPADDR-ID validation is a weaker form of authentication,
even if a peer is operating on an authenticated network DNS name it because even if a peer is operating on an authenticated network DNS
can provide an invalid Node ID and cause bundles to be "leaked" to an name or IP address it can provide an invalid Node ID and cause
invalid node. Especially in DTN environments, network names and bundles to be "leaked" to an invalid node. Especially in DTN
addresses of nodes can be time-variable so binding a certificate to a environments, network names and addresses of nodes can be time-
Node ID is a more stable identity. variable so binding a certificate to a Node ID is a more stable
identity.
Node ID validation ensures that the peer to which a bundle is 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 DNS name validation if certificates In circumstances where certificates can only be issued to DNS names,
can be guaranteed to validate the peer's Node ID. In circumstances Node ID validation is not possible but it could be reasonable to
where certificates can only be issued to DNS names, Node ID assume that a trusted host is not going to present an invalid Node
validation is not possible but it could be reasonable to assume that ID. Determining when a DNS-ID/IPADDR-ID authentication can be
a trusted host is not going to present an invalid Node ID. trusted to validate a Node ID is also a policy matter outside of the
Determining of when a DNS name authentication can be trusted to scope of this document.
validate a Node ID is also a policy matter outside the scope of this
document. One mitigation to arbitrary entities with valid PKIX certificates
impersonating arbitrary Node IDs is the use of the PKIX Extended Key
Usage key purpose "id-kp-bundleSecurity" in Section 9.9. When this
Extended Key Usage is present in the certificate, it represents a
stronger assertion that the private key holder should in fact be
trusted to operate as a DTN Node.
8.10. Threat: Denial of Service 8.10. Threat: Denial of Service
The behaviors described in this section all amount to a potential The behaviors described in this section all amount to a potential
denial-of-service to a TCPCL entity. The denial-of-service could be denial-of-service to a TCPCL entity. The denial-of-service could be
limited to an individual TCPCL session, could affect other well- limited to an individual TCPCL session, could affect other well-
behaving sessions on an entity, or could affect all sessions on a behaving sessions on an entity, or could affect all sessions on a
host. host.
A malicious entity can continually establish TCPCL sessions and delay A malicious entity can continually establish TCPCL sessions and delay
skipping to change at page 58, line 38 skipping to change at page 60, line 5
parameter the smallest Session Keepalive is one second, which should parameter the smallest Session Keepalive is one second, which should
be long enough to not flood the link. The victim entity can be long enough to not flood the link. The victim entity can
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.11. Alternate Uses of TLS 8.11. Mandatory-to-Implement TLS
Following IETF best current practice, TLS is mandatory to implement
for all TCPCL implementations but TLS is optional to use for a given
TCPCL session. The recommended configuration of Section 4.2 is to
always enable TLS, but entites are permitted to disable TLS based on
local configration. The configuration to enable or disable TLS for
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
stripping described in Section 8.4.
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
following subsections give examples of alternate TLS uses. following subsections give examples of alternate TLS uses.
8.11.1. TLS Without Authentication 8.12.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
authenticates only the passive entity of a TCPCL session or which authenticates only the passive entity of a TCPCL session or which
does not authenticate either entity. Using TLS in a way which does does not authenticate either entity. Using TLS in a way which does
not successfully authenticate some claim of both peer entities of a not successfully authenticate some claim of both peer entities of a
TCPCL session is outside of the scope of this document but does have TCPCL session is outside of the scope of this document but does have
similar properties to the opportunistic security model of [RFC7435]. similar properties to the opportunistic security model of [RFC7435].
8.11.2. Non-Certificate TLS Use 8.12.2. Non-Certificate TLS Use
In environments where PKI is unavailable, alternate uses of TLS which In environments where PKI is unavailable, alternate uses of TLS which
do not require certificates such as pre-shared key (PSK) do not require certificates such as pre-shared key (PSK)
authentication [RFC5489] and the use of raw public keys [RFC7250] are authentication [RFC5489] and the use of raw public keys [RFC7250] are
available and can be used to ensure confidentiality within TCPCL. available and can be used to ensure confidentiality within TCPCL.
Using non-PKI node authentication methods is outside of the scope of Using non-PKI node authentication methods is outside of the scope of
this document. this document.
8.12. Predictability of Transfer IDs 8.13. Predictability of Transfer IDs
The only requirement on Transfer IDs is that they be unique with each The only requirement on Transfer IDs is that they be unique with each
session from the sending peer only. The trivial algorithm of the session from the sending peer only. The trivial algorithm of the
first transfer starting at zero and later transfers incrementing by first transfer starting at zero and later transfers incrementing by
one causes absolutely predictable Transfer IDs. Even when a TCPCL one causes absolutely predictable Transfer IDs. Even when a TCPCL
session is not TLS secured and there is a man-in-the-middle attacker session is not TLS secured and there is a on-path attacker causing
causing denial of service with XFER_REFUSE messages, it is not denial of service with XFER_REFUSE messages, it is not possible to
possible to preemptively refuse a transfer so there is no benefit in preemptively refuse a transfer so there is no benefit in having
having unpredictable Transfer IDs within a session. unpredictable Transfer IDs within a session.
9. IANA Considerations 9. IANA Considerations
Registration procedures referred to in this section are defined in Registration procedures referred to in this section are defined in
[RFC8126]. [RFC8126].
Some of the registries have been defined as version specific to Some of the registries have been defined as version specific to
TCPCLv4, and imports some or all codepoints from TCPCLv3. This was TCPCLv4, and imports some or all codepoints from TCPCLv3. This was
done to disambiguate the use of these codepoints between TCPCLv3 and done to disambiguate the use of these codepoints between TCPCLv3 and
TCPCLv4 while preserving the semantics of some of the codepoints. TCPCLv4 while preserving the semantics of some of the codepoints.
skipping to change at page 67, line 23 skipping to change at page 68, line 23
+------------+--------------------------+ +------------+--------------------------+
| 0x03 | Message Unexpected | | 0x03 | Message Unexpected |
+------------+--------------------------+ +------------+--------------------------+
| 0x04--0xEF | Unassigned | | 0x04--0xEF | Unassigned |
+------------+--------------------------+ +------------+--------------------------+
| 0xF0--0xFF | Private/Experimental Use | | 0xF0--0xFF | Private/Experimental Use |
+------------+--------------------------+ +------------+--------------------------+
Table 17: MSG_REJECT Reason Codes Table 17: MSG_REJECT Reason Codes
9.9. Object Identifier for PKIX Extended Key Usage
IANA has created, under the "Structure of Management Information
(SMI) Numbers" registry [IANA-SMI], a sub-registry titled "SMI
Security for PKIX Extended Key Purpose". The extended key purpose
table is updated to include a purpose "id-kp-bundleSecurity" for
identifying DTN endpoints as in the following table.
+=========+======================+=====================+
| Decimal | Description | References |
+=========+======================+=====================+
| KP-TBD | id-kp-bundleSecurity | This specification. |
+---------+----------------------+---------------------+
Table 18
This also corresponds with the following SMI for that key purpose:
<CODE BEGINS>
id-kp-bundleSecurity OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) KP-TBD }
<CODE ENDS>
10. Acknowledgments 10. Acknowledgments
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
[IANA-BUNDLE]
IANA, "Bundle Protocol",
<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/>.
[IANA-BUNDLE] [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers",
IANA, "Bundle Protocol", <https://www.iana.org/assignments/smi-numbers/>.
<https://www.iana.org/assignments/bundle/>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
skipping to change at page 68, line 33 skipping to change at page 70, line 12
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
skipping to change at page 69, line 8 skipping to change at page 70, 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-27, 27 October 2020, dtn-bpbis-29, 17 November 2020,
<https://tools.ietf.org/html/draft-ietf-dtn-bpbis-27>. <https://tools.ietf.org/html/draft-ietf-dtn-bpbis-29>.
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 69, line 47 skipping to change at page 71, line 30
[RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for
Transport Layer Security (TLS)", RFC 5489, Transport Layer Security (TLS)", RFC 5489,
DOI 10.17487/RFC5489, March 2009, DOI 10.17487/RFC5489, March 2009,
<https://www.rfc-editor.org/info/rfc5489>. <https://www.rfc-editor.org/info/rfc5489>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram [RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram
Convergence Layers for the Delay- and Disruption-Tolerant Convergence Layers for the Delay- and Disruption-Tolerant
Networking (DTN) Bundle Protocol and Licklider Networking (DTN) Bundle Protocol and Licklider
Transmission Protocol (LTP)", RFC 7122, Transmission Protocol (LTP)", RFC 7122,
DOI 10.17487/RFC7122, March 2014, DOI 10.17487/RFC7122, March 2014,
<https://www.rfc-editor.org/info/rfc7122>. <https://www.rfc-editor.org/info/rfc7122>.
[RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant
Networking TCP Convergence-Layer Protocol", RFC 7242, Networking TCP Convergence-Layer Protocol", RFC 7242,
DOI 10.17487/RFC7242, June 2014, DOI 10.17487/RFC7242, June 2014,
skipping to change at page 70, line 45 skipping to change at page 72, line 23
<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-23, 25 October 2020, ietf-dtn-bpsec-25, 1 December 2020,
<https://tools.ietf.org/html/draft-ietf-dtn-bpsec-23>. <https://tools.ietf.org/html/draft-ietf-dtn-bpsec-25>.
[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-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/>.
 End of changes. 66 change blocks. 
247 lines changed or deleted 383 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/