]> Aalyria Technologies

rtaylor@aalyria.com

Internet Area (int) DTN Working Group DTN BPv7 Bundle Protocol Since the publication of 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 , 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 describes a mechanism by which an implementation can efficiently determine validity and the version of the Bundle Protocol that was used to encode a bundle by examining the initial octets of the encoded data, allowing this document to be used as a normative reference for updates to existing protocols. Additionally, this document updates by defining a CBOR tag that may be used as an explicit indicator that a particular indefinite-length CBOR array is a Bundle Protocol version 7 bundle. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction With the publication of the Bundle Protocol version 6 (BPv6) in , 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 some fifteen years later. Since the publication of BPv7 there has been impetus 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 , and the latter Concise Binary Object Representation (CBOR), see . 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 upgrade every CLA and bundle encapsulation specification published in the era of BPv6 that lack an explicit version indicator, to support BPv7. This document can instead be normatively referenced as a standard demultiplexing mechanism in a simple update to an affected specification.
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.

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)
• Delay-Tolerant Networking TCP Convergence-Layer Protocol (TCP-CLv3)
• Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)
• CCSDS Encapsulation Packet Protocol (EPP)

Other protocols which lack a bundle version indication field may also exist for which this document is relevant.

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 when, and only when, they appear in all capitals, as shown here.

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 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. An implementation MAY match against the first octet only, or up to all four initial octets, depending on the accuracy of determination required. 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. Initial octets and likely data item

Octet[0]	Octet[1]	Octet[2]	Octet[3]	Likely data item
0x06	any	any	any	BPv6 bundle, encoded as per .
0x9F	0x88..0x8B	0x07	0x00..0x1B	BPv7 bundle, encoded as per .
0xD9	0x23	0xD3	0x9F	Tagged BPv7 bundle.
0xD9	0xD9	0xF7	0x9F	BPv7 bundle, encoded as per .

Note: Octet ranges in the table above are inclusive, meaning that for every value V in X..Y, X <= V <= Y.

The BPv7 CBOR Tag type The absence of any standard 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, the presence of a IANA registered tag can provide additional assurance to a decoding implementation that a CBOR-encoded indefinite array is most likely a CBOR-representation of a BPv7 bundle. This document requests a new CBOR Tag from IANA, see IANA Considerations, to indicate that the array is indeed the CBOR representation of a BPv7 bundle. The addition of this CBOR tag increases the overall size of the CBOR representation of a bundle by three octets, and in some resource constrained environments this may be unwanted overhead. However, in environments where speed of processing is more important than the size of encoded bundles, the improvement in accuracy of fast bundle validity and version detection gained by using the tag may be advantageous. The addition of this tag updates in the following way:

• An implementation MAY tag the CBOR representation of the outermost indefinite-length array of blocks 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.

TBD: What about tag(55799)?

Convergence Layer Adaptor configuration Given a CBOR tag can be removed from the CBOR encoding of an array without affecting the content of the array, and this tag, if used, would be the first three octets of any encoded bundle, it is reasonable for this tag to be added or removed from an encoded bundle as it passes hop-by-hop across a DTN. Therefore it is RECOMMENDED that the use of this tag be a per-CLA configuration option, whereby a system administrator can configure a BPv7 BPA to either add or remove the tag on a bundle at both ingress and egress from each available Convergence Layer Adaptor. By default, unless configured otherwise, a BPA SHOULD NOT add a tag if it does not already exist, and SHOULD NOT remove a tag if it does; i.e. the presence or absence of the tag is maintained unless alternate behavior is explicitly configured. The use of the tag can also be powerful with non-traditional CLAs. For example, a CLA which is implemented using a general purpose shared filesystem such as NFS or a portable storage device to distribute bundles could enforce that a tag is used when writing the encoded bundle to the filesystem, and then UNIX tools such as file could confidently verify that the file content was indeed a BPv7 bundle, and the default 'open' verb used by a desktop environment could be associated with a local bundle processing application. TBD: Is it worth registering a MIME/Media type for BPv7?

Security Considerations This document does not impact or alter the existing security considerations described in , however it adds an additional consideration.

Abuse of Tags as a side-channel As permitted in , implementations can follow "Postel's Law" by parsing and silently ignoring any tags, as tags are just type metadata that do not alter the content of the encoded bundle. Given the processing cost of re-encoding bundles hop-by-hop, implementations could decide to forward bundles containing these silently-ignored tags to the next hop unmodified, but that creates an uncontrolled side-channel in the bundle protocol. To mitigate against the creation of a uncontrolled side-channel by the use of silently-ignored tags, is updated in the following way:

• Even if an implementation of the Bundle Protocol accepts a sequence of bytes that does not conform to the protocol format requirements, the implementation MUST NOT transmit a CBOR representation of a bundle that does not conform to the protocol format requirements.

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
• Data Item: array
• Semantics: "Bundle Protocol version 7 bundle"
• Reference: This document

References Normative References This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References n.d. This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community. This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community. This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of the IRTF's DTN Research Group (DTNRG). This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG. The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with the companion External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol.

Are random tags allowed? (To be removed) This behavior is already prohibited by , which states:

• To ensure that blocks are always in canonical representation when they are transmitted and received, the CBOR encodings of the values of all fields in all blocks MUST conform to the core deterministic encoding requirements as specified in [RFC8949], except that indefinite-length items are not prohibited.

sets out the core deterministic encoding requirements, but is a little non-obvious on the correct behavior with respect to tags. however clarifies the situation with the following statement:

• ... the deterministic format would not allow the presence of the tag, based on the "shortest form" principle.

Indicating that tags appearing in an encoding that are not explicitly permitted by the relevant protocol specification, that requires compliance with the core deterministic encoding requirements, means the encoded value is not Well-formed as defined in . Therefore a compliant BPv7 implementation MUST consider any CBOR representation of a bundle that includes tags not specified in or this document, as not Well-formed.

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.