DTN Working Group R. Taylor Internet-Draft Aalyria Technologies Updates: [9171] (if approved) 30 September 2024 Intended status: Standards Track Expires: 3 April 2025 Bundle Protocol Version Demultiplexing draft-taylor-dtn-demux-01 Abstract Since the publication of [RFC5050] a number of transport and convergence layer protocols have been developed to carry bundles between nodes in a delay-tolerant network. Before the publication of Bundle Protocol version 7 (BPv7) in [RFC9171], there was only one standardized version of the Bundle Protocol, version 6, and as many of these transport and convergence-layer protocols pre-date the publication of version 7, they do not include any protocol mechanism to differentiate between versions of the Bundle Protocol. This document updates [RFC9171] by defining a CBOR [RFC8949] tag that should be used as an explicit indicator that a particular CBOR array is a Bundle Protocol version 7 bundle. It also describes a mechanism by which an implementation can determine the version of the Bundle Protocol that was used to encode a bundle by examining the initial octets of the encoded data. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-taylor-dtn-demux/. Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (mailto:dtn@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dtn/. Subscribe at https://www.ietf.org/mailman/listinfo/dtn/. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dtn/draft-dtn-demux. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Taylor Expires 3 April 2025 [Page 1] Internet-Draft dtn-demux September 2024 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 3 April 2025. Copyright Notice Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. The BPv7 CBOR Tag type . . . . . . . . . . . . . . . . . . . 4 4. Bundle Version Detection . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Taylor Expires 3 April 2025 [Page 2] Internet-Draft dtn-demux September 2024 1. Introduction With the publication of the Bundle Protocol version 6 (BPv6) in [RFC5050], many groups began experimenting and deploying Delay and Disruption Tolerant Networks (DTNs). These networks relied on Convergence Layer Adaptors (CLAs) to perform the hop-by-hop transport of bundles, and several specifications emerged defining how to encapsulate bundles in suitable wrappers for transport over existing space data-links. At the same time, new link-layer protocols were developed and standardized to provide the efficient transport of bundles between nodes of larger DTN networks. The success of these networks drove the development of Bundle Protocol version 7 (BPv7), incorporating the lessons learned from BPv6, resulting in [RFC9171] some fifteen years later. Since the publication of BPv7 there has been a drive to deploy larger, more capable BPv7 DTNs, but there remains a need to update the existing BPv6 networks to support in some way coexistence with BPv6. Many of the CLAs and link-layer encapsulations were defined with a completely reasonable assumption that any future bundle protocol version would maintain a similar binary representation to BPv6, and hence determining the version in use would be a matter for the Bundle Processing Agent (BPA) and not a concern of the CLA or encapsulation protocol. Hence many of these existing specifications lack a field an implementation can use to distinguish the version of the bundle protocol used to format the bundle. Unfortunately, Bundle Protocol version 6 and 7 fundamentally differ in binary representation: the former uses Self-Delimiting Numeric Values (SDNVs), see Section 4.1 of [RFC5050], and the latter Concise Binary Object Representation (CBOR), see Section 4.1 of [RFC9171]. Luckily differentiating between SDNVs and CBOR is simple: the first octet of a SDNV encoded BPv6 bundle is not a valid first octet of the CBOR representation of a BPv7 bundle. However, given CBOR is a general-purpose representation of binary encoded objects, differentiating between a CBOR-encoded BPv7 bundle and another data item that is not a bundle, but is binary encoded using CBOR, is less simple and can require more expensive parsing to determine the difference. The purpose of this document is to provide two simple to implement mechanisms that can: 1. Avoid the need to update every CLA and bundle encapsulation specification, published in the era of BPv6 that lack an explicit version indicator, to support BPv7. Taylor Expires 3 April 2025 [Page 3] Internet-Draft dtn-demux September 2024 2. Avoid the need for a bundle processing agent to fully parse every received sequence of octets with an SDNV parser and a CBOR parser, both reasonably expensive operations, just to determine if the octets are even a binary encoding of a version 6 or 7 bundle. 1.1. Applicability The following protocols are known to be capable of transporting or encapsulating bundles, but to not have an in-band mechanism to differentiate between versions 6 and 7 of the Bundle Protocol: * Licklider Transmission Protocol (LTP) [RFC5326] * Delay-Tolerant Networking TCP Convergence-Layer Protocol (TCP- CLv3) [RFC7242] * Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP) [RFC7122] * CCSDS Encapsulation Packet Protocol (EPP) [EPP] Other protocols which lack a bundle version indication field may also exist for which this document is relevant. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. The BPv7 CBOR Tag type Section 4.1 of [RFC9171] defines the CBOR representation of a BPv7 bundle as an indefinite-length array, but does not require the use of CBOR tags with this encoding. The absence of any tag complicates the implementation of any transport protocol that must handle not only BPv7 bundles, but also other protocol data units that may be represented as CBOR indefinite-length arrays. In order to reduce the complexity of demultiplexing CBOR-encoded BPv7 bundles from other CBOR-encoded protocol data units, this document requests a new CBOR Tag Section 3.4 of [RFC8949] from IANA, see IANA Considerations (Section 6), to indicate that the array is indeed the CBOR representation of a BPv7 bundle. Taylor Expires 3 April 2025 [Page 4] Internet-Draft dtn-demux September 2024 The addition of this tag updates Section 4.1 of [RFC9171] in the following way: * An implementation SHOULD prefix the CBOR representation of a BPv7 bundle with the tag defined in this document. Implementations that process bundles MAY use the presence of this tag to determine that the CBOR array encodes a Bundle Protocol version 7 bundle. 4. Bundle Version Detection In order to make the determination of the version of the Bundle Protocol used to encode a particular bundle, or even if a sequence of octets is an encoded bundle at all, the following demultiplexing logic is RECOMMENDED to implementations. The table below (Table 1) describes the range of values of the initial octets of a sequence of octets and the likely data item that the octet stream represents. By matching the initial octets of a protocol data unit to the values in this table the likely format of the encoded bundle can be efficiently determined, avoiding repeated processor-intensive parsing. The ability to make a distinction between the types and representations of data items by examining the initial octets makes the technique suitable for implementation in firmware, however this mechanism does not indicate the correctness of any encoding or data represented, and further parsing and validation MUST be performed. +==========+============+==========+======================+ | Octet[0] | Octet[1] | Octet[2] | Likely data item | +==========+============+==========+======================+ | 0x06 | any | any | BPv6 bundle, encoded | | | | | as per [RFC5050]. | +----------+------------+----------+----------------------+ | 0x9F | 0x88..0x8B | 0x07 | BPv7 bundle, encoded | | | | | as per [RFC9171]. | +----------+------------+----------+----------------------+ | 0xD9 | 0x23 | 0xD3 | Tagged (Section 3) | | | | | BPv7 bundle. | +----------+------------+----------+----------------------+ Table 1: Initial octets and likely data item *Note*: Octet ranges in the table above (Table 1) are inclusive, meaning that for every value V in X..Y, X <= V <= Y. Taylor Expires 3 April 2025 [Page 5] Internet-Draft dtn-demux September 2024 5. Security Considerations This document does not impact or alter the existing security considerations described in Section 8 of [RFC9171]. 6. IANA Considerations IANA is requested to allocate a new entry in the "CBOR Tags" sub- registry of the IANA "Concise Binary Object Representation (CBOR) Tags" registry, with the following values: * Tag: 9171, to correspond with [RFC9171] * Data Item: array * Semantics: "Bundle Protocol version 7 bundle" * Reference: This document 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, . 7.2. Informative References [EPP] "CCSDS Encapsulation Packet Protocol", n.d., . Taylor Expires 3 April 2025 [Page 6] Internet-Draft dtn-demux September 2024 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, DOI 10.17487/RFC5050, November 2007, . [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, DOI 10.17487/RFC5326, September 2008, . [RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)", RFC 7122, DOI 10.17487/RFC7122, March 2014, . [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol", RFC 7242, DOI 10.17487/RFC7242, June 2014, . Acknowledgments Thanks are owed to Brian Sipos for doing similar work on demultiplexing the initial octets of bundles for the UDP-CL update, and Erik Kline for his valuable discussion and early review of this document. Author's Address Rick Taylor Aalyria Technologies Email: rtaylor@aalyria.com Taylor Expires 3 April 2025 [Page 7]