Bundle Protocol Version Demultiplexing
draft-taylor-dtn-demux-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Rick Taylor | ||
| Last updated | 2024-10-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-taylor-dtn-demux-02
DTN Working Group R. Taylor
Internet-Draft Aalyria Technologies
Updates: [9171] (if approved) 1 October 2024
Intended status: Standards Track
Expires: 4 April 2025
Bundle Protocol Version Demultiplexing
draft-taylor-dtn-demux-02
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 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 [RFC9171] by defining a CBOR
[RFC8949] 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
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.
Taylor Expires 4 April 2025 [Page 1]
Internet-Draft dtn-demux October 2024
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 4 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. Bundle version detection . . . . . . . . . . . . . . . . . . 4
4. The BPv7 CBOR Tag type . . . . . . . . . . . . . . . . . . . 6
4.1. Convergence Layer Adaptor configuration . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5.1. Abuse of Tags as a side-channel . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Are random tags allowed? (To be removed) . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
Taylor Expires 4 April 2025 [Page 2]
Internet-Draft dtn-demux October 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 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 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 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.
Taylor Expires 4 April 2025 [Page 3]
Internet-Draft dtn-demux October 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. 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.
Taylor Expires 4 April 2025 [Page 4]
Internet-Draft dtn-demux October 2024
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. 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.
+==========+============+==========+============+================+
| Octet[0] | Octet[1] | Octet[2] | Octet[3] | Likely data |
| | | | | item |
+==========+============+==========+============+================+
| 0x06 | any | any | any | BPv6 bundle, |
| | | | | encoded as per |
| | | | | [RFC5050]. |
+----------+------------+----------+------------+----------------+
| 0x9F | 0x88..0x8B | 0x07 | 0x00..0x1B | BPv7 bundle, |
| | | | | encoded as per |
| | | | | [RFC9171]. |
+----------+------------+----------+------------+----------------+
| 0xD9 | 0x23 | 0xD3 | 0x9F | Tagged |
| | | | | (Section 4) |
| | | | | BPv7 bundle. |
+----------+------------+----------+------------+----------------+
| 0xD9 | 0xD9 | 0xF7 | 0x9F | BPv7 bundle, |
| | | | | encoded as per |
| | | | | Appendix B of |
| | | | | [RFC9171]. |
+----------+------------+----------+------------+----------------+
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 4 April 2025 [Page 5]
Internet-Draft dtn-demux October 2024
4. 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 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.
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 Section 4.1 of [RFC9171] 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)?
4.1. 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.
Taylor Expires 4 April 2025 [Page 6]
Internet-Draft dtn-demux October 2024
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 [RFC7530] 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?
5. Security Considerations
This document does not impact or alter the existing security
considerations described in Section 8 of [RFC9171], however it adds
an additional consideration.
5.1. Abuse of Tags as a side-channel
As permitted in Section 4.1 of [RFC9171], 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, Section 4.1 of [RFC9171] 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.
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:
Taylor Expires 4 April 2025 [Page 7]
Internet-Draft dtn-demux October 2024
* 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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.
7.2. Informative References
[EPP] "CCSDS Encapsulation Packet Protocol", n.d.,
<https://public.ccsds.org/Pubs/133x1b3e1.pdf>.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/rfc/rfc5050>.
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification", RFC 5326,
DOI 10.17487/RFC5326, September 2008,
<https://www.rfc-editor.org/rfc/rfc5326>.
Taylor Expires 4 April 2025 [Page 8]
Internet-Draft dtn-demux October 2024
[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,
<https://www.rfc-editor.org/rfc/rfc7122>.
[RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant
Networking TCP Convergence-Layer Protocol", RFC 7242,
DOI 10.17487/RFC7242, June 2014,
<https://www.rfc-editor.org/rfc/rfc7242>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <https://www.rfc-editor.org/rfc/rfc7530>.
Are random tags allowed? (To be removed)
This behavior is already prohibited by Section 4.1-2 of [RFC9171],
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.
Section 4.2.1 of [RFC8949] sets out the core deterministic encoding
requirements, but is a little non-obvious on the correct behavior
with respect to tags. Section 4.2.2-1 of [RFC8949] 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 Section 1.2 of
[RFC8949]. Therefore a compliant BPv7 implementation MUST consider
any CBOR representation of a bundle that includes tags not specified
in Appendix B of [RFC9171] or this document, as not Well-formed.
Taylor Expires 4 April 2025 [Page 9]
Internet-Draft dtn-demux October 2024
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 4 April 2025 [Page 10]