--- 1/draft-ietf-dtn-tcpclv4-24.txt 2021-02-01 22:13:10.246579663 -0800 +++ 2/draft-ietf-dtn-tcpclv4-25.txt 2021-02-01 22:13:10.398583546 -0800 @@ -1,22 +1,22 @@ Delay-Tolerant Networking B. Sipos Internet-Draft RKF Engineering Intended status: Standards Track M. Demmer -Expires: 7 June 2021 UC Berkeley +Expires: 5 August 2021 UC Berkeley J. Ott Aalto University S. Perreault - 4 December 2020 + 1 February 2021 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 - draft-ietf-dtn-tcpclv4-24 + draft-ietf-dtn-tcpclv4-25 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,25 +31,25 @@ 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 7 June 2021. + This Internet-Draft will expire on 5 August 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. @@ -68,75 +68,75 @@ 3.5. Session Keeping Policies . . . . . . . . . . . . . . . . 20 3.6. Transfer Segmentation Policies . . . . . . . . . . . . . 21 3.7. Example Message Exchange . . . . . . . . . . . . . . . . 22 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 24 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 24 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 25 4.3. Contact Validation and Negotiation . . . . . . . . . . . 26 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 28 4.4.1. Entity Identification . . . . . . . . . . . . . . . . 28 4.4.2. Certificate Profile for TCPCL . . . . . . . . . . . . 29 - 4.4.3. TLS Handshake . . . . . . . . . . . . . . . . . . . . 30 - 4.4.4. TLS Authentication . . . . . . . . . . . . . . . . . 31 + 4.4.3. TLS Handshake . . . . . . . . . . . . . . . . . . . . 31 + 4.4.4. TLS Authentication . . . . . . . . . . . . . . . . . 32 4.4.5. Policy Recommendations . . . . . . . . . . . . . . . 33 - 4.4.6. Example TLS Initiation . . . . . . . . . . . . . . . 33 - 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 35 - 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 36 - 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 38 - 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 39 - 5. Established Session Operation . . . . . . . . . . . . . . . . 40 - 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 40 - 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 40 - 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 41 - 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 43 - 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 44 - 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 44 - 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 46 - 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 48 - 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 50 + 4.4.6. Example TLS Initiation . . . . . . . . . . . . . . . 34 + 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 36 + 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 37 + 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 39 + 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 40 + 5. Established Session Operation . . . . . . . . . . . . . . . . 41 + 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 41 + 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 41 + 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 42 + 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 44 + 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 45 + 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 45 + 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 47 + 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 49 + 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 51 - 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 52 - 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 52 - 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 55 - 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 55 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 55 - 8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 56 - 8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 56 - 8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 56 - 8.4. Threat: Transport Security Stripping . . . . . . . . . . 56 - 8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 57 - 8.6. Threat: Untrusted End-Entity Certificate . . . . . . . . 57 - 8.7. Threat: Certificate Validation Vulnerabilities . . . . . 57 - 8.8. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 58 - 8.9. Threat: BP Node Impersonation . . . . . . . . . . . . . . 58 - 8.10. Threat: Denial of Service . . . . . . . . . . . . . . . . 59 - 8.11. Mandatory-to-Implement TLS . . . . . . . . . . . . . . . 60 - 8.12. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 60 - 8.12.1. TLS Without Authentication . . . . . . . . . . . . . 60 - 8.12.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 60 - 8.13. Predictability of Transfer IDs . . . . . . . . . . . . . 61 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 - 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 61 - 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 62 - 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 63 - 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 63 - 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 64 - 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 65 - 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 66 - 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 67 - 9.9. Object Identifier for PKIX Extended Key Usage . . . . . . 68 - 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 + 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 53 + 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 53 + 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 56 + 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 56 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 + 8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 57 + 8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 57 + 8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 57 + 8.4. Threat: Transport Security Stripping . . . . . . . . . . 57 + 8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 58 + 8.6. Threat: Untrusted End-Entity Certificate . . . . . . . . 58 + 8.7. Threat: Certificate Validation Vulnerabilities . . . . . 58 + 8.8. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 59 + 8.9. Threat: BP Node Impersonation . . . . . . . . . . . . . . 59 + 8.10. Threat: Denial of Service . . . . . . . . . . . . . . . . 60 + 8.11. Mandatory-to-Implement TLS . . . . . . . . . . . . . . . 61 + 8.12. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 61 + 8.12.1. TLS Without Authentication . . . . . . . . . . . . . 61 + 8.12.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 61 + 8.13. Predictability of Transfer IDs . . . . . . . . . . . . . 62 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 + 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 62 + 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 63 + 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 64 + 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 64 + 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 65 + 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 66 + 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 67 + 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 68 + 9.9. Object Identifier for PKIX Extended Key Usage . . . . . . 69 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 70 + 11.2. Informative References . . . . . . . . . . . . . . . . . 71 + Appendix A. Significant changes from RFC7242 . . . . . . . . . . 74 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 1. Introduction This document describes the TCP-based convergence-layer protocol for Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- end architecture providing communications in and/or through highly stressed environments, including those with intermittent connectivity, long and/or variable delays, and high bit error rates. More detailed descriptions of the rationale and capabilities of these networks can be found in "Delay-Tolerant Network Architecture" @@ -190,21 +190,23 @@ * The format of protocol data units of the Bundle Protocol, as those are defined elsewhere in [I-D.ietf-dtn-bpbis]. This includes the concept of bundle fragmentation or bundle encapsulation. The TCPCL transfers bundles as opaque data blocks. * Mechanisms for locating or identifying other bundle entities (peers) within a network or across an internet. The mapping of Node ID to potential convergence layer (CL) protocol and network address is left to implementation and configuration of the BP - Agent and its various potential routing strategies. + Agent and its various potential routing strategies. The mapping + of DNS name and/or address to a choice of end-entity certificate + to authenticate a node to its peers. * Logic for routing bundles along a path toward a bundle's endpoint. This CL protocol is involved only in transporting bundles between adjacent entities in a routing sequence. * Policies or mechanisms for issuing Public Key Infrastructure Using X.509 (PKIX) certificates; provisioning, deploying, or accessing certificates and private keys; deploying or accessing certificate revocation lists (CRLs); or configuring security parameters on an individual entity or across a network. @@ -848,21 +850,23 @@ 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. + certificate to use. The logic for mapping an SNI DNS name to an end- + entity certificate is an implementation matter, and can involve + correlating DNS name with Node ID or other certificate attributes. 3.5. Session Keeping Policies This specification gives requirements about how to initiate, sustain, and terminate a TCPCL session but does not impose any requirements on how sessions need to be managed by a BP agent. It is a network administration matter to determine an appropriate session keeping policy, but guidance given here can be used to steer policy toward performance goals. @@ -1288,21 +1292,23 @@ This specification defines a IPADDR-ID of a certificate as being the subjectAltName entry of type iPAddress whose value is encoded according to [RFC5280]. 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. + unnecessary. An entity SHOULD omit the root CA certificate (the last + item of the chain) when sending a certification chain, as the + recipient already has the root CA to anchor its validation. The TCPCL requires Version 3 certificates due to the extensions used 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. @@ -1311,39 +1317,46 @@ 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 + names. When assigned one or more stable network addresses, 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 + bundleSecurity" in Section 9.9 which can 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. + combined with other purposes in the same certificate. When allowed + by CA policy, a BPSec end-entity certificate SHOULD contain a PKIX + Extended Key Usage extension in accordance with Section 4.2.1.12 of + [RFC5280]. When the PKIX Extended Key Usage extension is present, it + SHOULD contain a key purpose "id-kp-bundleSecurity" as defined in + Section 9.9. 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 a PKIX Key Usage extension in accordance with Section 4.2.1.3 + of [RFC5280]. The PKIX Key Usage bit which is consistent with TCPCL + security using TLS 1.3 is digitalSignature. The specific algorithms + used during the TLS handshake will determine which of those key uses + are exercised. Earlier versions of TCPCL can mandate use of the bits + keyEncipherment or keyAgreement. When allowed by CA policy, a TCPCL end-entity certificate SHOULD 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 Section 4.3. After negotiating an Enable TLS parameter of true, and @@ -1425,21 +1438,21 @@ Failure: Indicating that one or more such claims are present and none match the peer identity. 4.4.4.1. Certificate Path and Purpose Validation For any peer end-entity certificate received during TLS handshake, 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 + each certificate providing OCSP authority 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). For the end-entity peer certificate received during TLS handshake, the entity SHALL apply security policy to the Key Usage extension (if present) and Extended Key Usage extension (if present) in accordance @@ -1787,32 +1800,32 @@ 5.1. Upkeep and Status Messages 5.1.1. Session Upkeep (KEEPALIVE) The protocol includes a provision for transmission of KEEPALIVE messages over the TCPCL session to help determine if the underlying TCP connection has been disrupted. As described in Section 4.3, a negotiated parameter of each session is the Session Keepalive interval. If the negotiated Session - Keepalive is zero (i.e., one or both contact headers contains a zero - Keepalive Interval), then the keepalive feature is disabled. There - is no logical minimum value for the keepalive interval (within the - minimum imposed by the positive-value encoding), but when used for - many sessions on an open, shared network a short interval could lead - to excessive traffic. For shared network use, entities SHOULD choose - a keepalive interval no shorter than 30 seconds. There is no logical - maximum value for the keepalive interval (within the maximum imposed - by the fixed-size encoding), but an idle TCP connection is liable for - closure by the host operating system if the keepalive time is longer - than tens-of-minutes. Entities SHOULD choose a keepalive interval no - longer than 10 minutes (600 seconds). + Keepalive is zero (i.e., one or both SESS_INIT messages contains a + zero Keepalive Interval), then the keepalive feature is disabled. + There is no logical minimum value for the keepalive interval (within + the minimum imposed by the positive-value encoding), but when used + for many sessions on an open, shared network a short interval could + lead to excessive traffic. For shared network use, entities SHOULD + choose a keepalive interval no shorter than 30 seconds. There is no + logical maximum value for the keepalive interval (within the maximum + imposed by the fixed-size encoding), but an idle TCP connection is + liable for closure by the host operating system if the keepalive time + is longer than tens-of-minutes. Entities SHOULD choose a keepalive + interval no longer than 10 minutes (600 seconds). Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP retransmissions MAY occur in case of packet loss. Those will have to be triggered by a timeout (TCP retransmission timeout (RTO)), which is dependent on the measured RTT for the TCP connection so that KEEPALIVE messages can experience noticeable latency. The format of a KEEPALIVE message is a one-octet message type code of KEEPALIVE (as described in Table 2) with no additional data. Both sides SHALL send a KEEPALIVE message whenever the negotiated interval @@ -2424,44 +2437,50 @@ implementation and configuration matter. If there is a configured time to terminate idle sessions and if no TCPCL messages (other than KEEPALIVE messages) has been received for at least that amount of time, then either entity MAY terminate the session by transmitting a SESS_TERM message indicating the reason code of "Idle timeout" (as described in Table 9). 7. Implementation Status + This section is to be removed before publishing as an RFC. + [NOTE to the RFC Editor: please remove this section before - publication, as well as the reference to [RFC7942] and - [github-dtn-bpbis-tcpcl].] + publication, as well as the reference to [RFC7942], + [github-dtn-demo-agent], and [github-dtn-wireshark].] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations can exist. An example implementation of the this draft of TCPCLv4 has been - created as a GitHub project [github-dtn-bpbis-tcpcl] and is intended + created as a GitHub project [github-dtn-demo-agent] and is intended to use as a proof-of-concept and as a possible source of interoperability testing. This example implementation uses D-Bus as the CL-BP Agent interface, so it only runs on hosts which provide the Python "dbus" library. + A wireshark dissector for TCPCLv4 has been created as a GitHub + project [github-dtn-wireshark] and has been kept in-sync with the + latest encoding of this specification. + 8. Security Considerations This section separates security considerations into threat categories based on guidance of BCP 72 [RFC3552]. 8.1. Threat: Passive Leak of Node Data When used without TLS security, the TCPCL exposes the Node ID and other configuration data to passive eavesdroppers. This occurs even when no transfers occur within a TCPCL session. This can be avoided @@ -2639,22 +2658,22 @@ Finally, an attacker or a misconfigured entity can cause issues at the TCP connection which will cause unnecessary TCP retransmissions or connection resets, effectively denying the use of the overlying TCPCL session. 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 + always enable TLS, but entities are permitted to disable TLS based on + local configuration. 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 authentication within TLS. There are alternate uses of TLS which are not necessarily incompatible with the security goals of this specification, but are outside of the scope of this document. The @@ -3025,21 +3044,22 @@ 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: + This also corresponds with the following SMI, in ASN.1 syntax of + [X.680], for that key purpose: id-kp-bundleSecurity OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) KP-TBD } 10. Acknowledgments This specification is based on comments on implementation of @@ -3118,22 +3139,27 @@ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [I-D.ietf-dtn-bpbis] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol Version 7", Work in Progress, Internet-Draft, draft-ietf- - dtn-bpbis-29, 17 November 2020, - . + dtn-bpbis-30, 10 December 2020, + . + + [X.680] ITU-T, "Information technology -- Abstract Syntax Notation + One (ASN.1): Specification of basic notation", ITU-T + Recommendation X.680, ISO/IEC 8824-1:2015, August 2015, + . 11.2. Informative References [AEAD-LIMITS] Luykx, A. and K. Paterson, "Limits on Authenticated Encryption Use in TLS", August 2017, . [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999, @@ -3197,32 +3223,36 @@ . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . [I-D.ietf-dtn-bpsec] Birrane, E. and K. McKeever, "Bundle Protocol Security Specification", Work in Progress, Internet-Draft, draft- - ietf-dtn-bpsec-25, 1 December 2020, - . + ietf-dtn-bpsec-26, 8 January 2021, + . [I-D.ietf-dtn-bibect] Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 February 2020, . - [github-dtn-bpbis-tcpcl] + [github-dtn-demo-agent] Sipos, B., "TCPCL Example Implementation", - . + . + + [github-dtn-wireshark] + Sipos, B., "TCPCL Wireshark Dissector", + . Appendix A. Significant changes from RFC7242 The areas in which changes from [RFC7242] have been made to existing headers and messages are: * Split Contact Header into pre-TLS protocol negotiation and SESS_INIT parameter negotiation. The Contact Header is now fixed- length.