RFC 6260

Compressed Bundle Header Encoding (CBHE)

📅 published May 2011, from ietf

RFC 6260: Compressed Bundle Header Encoding (CBHE) 🎀

Okay bestie, this one is an IRTF doc written by S. Burleigh from the Jet Propulsion Laboratory at the California Institute of Technology, published in May 2011 as an Experimental document with ISSN 2070-1721. Its header doesn't list anything it obsoletes or updates. 🦋

Abstract 💖

This doc is about a trick that Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters can use to shorten endpoint identifiers inside the primary blocks of bundles. It only works if the endpoint IDs follow the structure this convention lays out. 🌸

CBHE compression lives in the convergence layer and bundle processing can't see it, so it can't break interop between different Bundle Protocol implementations. It only affects interop between different convergence-layer adaptation implementations. 🧚

The DTN Research Group wrote this and reviewed it, and no objections to publishing it as an RFC were raised. ✨

Status of This Memo

This isn't an Internet Standards Track spec. It's published so people can look at it, try implementing it, and evaluate it. 🔥

It defines an Experimental Protocol for the Internet community and it's a product of the Internet Research Task Force (IRTF), which shares research and development results. Those results might not be ready for deployment. This RFC reflects the consensus of the DTN Research Group in the IRTF. Documents the IRSG approves for publication can't become any level of Internet Standard, see Section 2 of RFC 5741. 💅

Info about the current status, errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6260. 🍓

Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc. 💜

Table of Contents

1. Introduction ....................................................2
   1.1. Requirements Language ......................................3
2. Compression Convention ..........................................3
   2.1. Constraints ................................................3
   2.2. Method .....................................................6
3. Specification ...................................................7
   3.1. Transmission ...............................................7
   3.2. Reception ..................................................7
4. IANA Considerations .............................................8
5. Security Considerations ........................................10
6. References .....................................................11
   6.1. Normative References ......................................11
   6.2. Informative References ....................................11
Appendix A. Acknowledgments .......................................12

1. Introduction ✨

Okay so this doc describes a convention that lets DTN Bundle Protocol (BP) [RFC5050] "convergence-layer" adapters store endpoint identifiers (EIDs) in a compressed form inside the primary blocks of bundles. The catch is that the EIDs have to match the structure this convention requires. 🎀

Every DTN bundle's primary block has four BP endpoint identifiers: the bundle's source, destination, report-to endpoint, and current custodian. Any two, any three, or even all four of them can be lexically identical. Each EID is a Uniform Record Identifier (URI) as defined by [RFC3986]. More specifically, each BP EID is a URI made of a "scheme name", then ":", then a sequence of characters conforming to URI syntax as defined by RFC 3986. DTN specs have historically called that second part the "scheme-specific part" (SSP). 🦋

The primary block already squeezes things a bit. The scheme names and SSPs of the four endpoints, up to eight NULL-terminated strings, get glued together at the end of the block in a variable-length character array called a "dictionary". Each EID is then just a pair of integers giving the offsets, inside the dictionary, of its scheme name and its SSP. Duplicate strings can be left out of the dictionary, so there might be fewer than eight NULL-terminated strings in it, and two or more of the offsets in the block can point to the same value. The eight offsets are encoded as Self-Delimiting Numeric Values (SDNVs), which shrink to fit the values they hold. If the dictionary is less than 127 bytes long, all eight offsets fit in just eight bytes. 🌸

Still, those tricks don't stop the scheme names and especially the SSPs from being long ASCII text strings. So the primary header can end up being a huge chunk of the whole bundle when the payload is small. That's expected for lots of DTN apps, like space flight operations, and it's always true for bundles carrying BP administrative records. 🚀

That's why CBHE exists: to make DTN transmission more efficient for these apps by cutting the number of bytes convergence-layer adapters use to represent EIDs in the primary blocks of bundles even further. 💖

1.1. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🫶

2. Compression Convention 💅

2.1. Constraints 🔥

The only valid scheme name for BP EIDs identified so far is "dtn". There's no formally defined SSP syntax for URIs in the "dtn" scheme yet, and the syntax people roughly agreed on in practice doesn't work with CBHE's compression steps. So for CBHE's purposes, this doc defines an extra URI scheme called "ipn". As Section 4 notes, IANA has registered this new scheme. 👑

CBHE only works when every endpoint ID in the primary block of a bundle is "CBHE conformant". Two forms count as CBHE conformant: (a) the null endpoint ID "dtn:none", and (b) any endpoint ID formed in the "ipn" scheme. ✨

Every SSP of a URI formed in the "ipn" scheme must have these three parts:

  1. A sequence of ASCII numeric digits representing an integer from 1 to (2^64 - 1). This is called the "node number" of the URI.
  2. An ASCII period ('.') character.
  3. A sequence of ASCII numeric digits representing an integer from 0 to (2^64 - 1). This is called the "service number" of the URI.

The node number is meant to identify a BP node. But CBHE isn't used everywhere in DTN, so you can't assume that every BP node is identified by a node number. 🧚

Negative integers and integers bigger than (2^64 - 1) can't be node numbers, because the SDNVs used to represent scheme name and SSP offsets in bundles' primary blocks can't hold them. That means they couldn't be compressed the way this spec describes later. Node number zero is reserved for the null endpoint ID in the compressed form. Decompressing a compressed null EID must always give back the standard null endpoint ID URI "dtn:none". 🍓

The service number is meant to work as a de-multiplexing token. If the bundle payload is a protocol data unit of a protocol with its own de-multiplexing identifiers, the service number can act a bit like the protocol number in an IP packet, showing which encapsulated protocol it is. Or it can act like the port number in a UDP datagram. Service numbers help route inbound bundles' application data units to the app instances built to process them, so bundle producers and consumers can build real communication relationships. 🦋

A service number must not be negative or bigger than (2^64 - 1), for the same reason a node number can't be. 💜

For example, "ipn:9.37" would be a CBHE-conformant endpoint ID. 🌈

Converting a CBHE-conformant EID to and from a tuple of two integers is easy. Every character in the EID except the node number and service number is constant, as the "ipn" scheme definition sets it, so the two integers in the tuple are just the node number and service number. That easy conversion means an array of integer pairs can do the same job as a dictionary of ASCII string EIDs. ✨

ipn:9.37

Here's the catch, though. CBHE decompression can't faithfully rebuild the dictionary of a compressed primary block from an array of integer pairs, unless you know the order of the scheme names and SSP strings in the dictionary of the original, uncompressed block. (The Bundle Protocol Specification doesn't require the dictionary strings to appear in any particular order, and it doesn't require redundant strings to be left out.) So there's one more precondition for CBHE compression: the strings in the dictionary of the bundle being compressed must be exactly the following, in this order and with nothing added: 💖

  1. The scheme name of the destination endpoint ID.
  2. The scheme-specific part of the destination endpoint ID.
  3. The scheme name of the source endpoint ID, if and only if different from any prior string in the dictionary.
  4. The scheme-specific part of the source endpoint ID, if and only if different from any prior string in the dictionary.
  5. The scheme name of the report-to endpoint ID, if and only if different from any prior string in the dictionary.
  6. The scheme-specific part of the report-to endpoint ID, if and only if different from any prior string in the dictionary.
  7. The scheme name of the current custodian endpoint ID, if and only if different from any prior string in the dictionary.
  8. The scheme-specific part of the current custodian endpoint ID, if and only if different from any prior string in the dictionary.
Heads up: this rule means that a bundle with any extension blocks holding EID-references to endpoint IDs other than the block's destination, source, report-to, and current custodian can't be CBHE compressed. Compressing it would produce a dictionary that doesn't match this structure. 🙈

2.2. Method ✨

Okay bestie, here's the actual trick. 💅 When the constraints from Section 2.1 are all met, the CBHE block compression method can be applied by the convergence-layer adapter (CLA) right when the bundle gets sent over a convergence-layer protocol. 🦋 In a CBHE-compressed primary block, the eight SDNVs that normally hold the EIDs' scheme name and SSP offsets in the dictionary get repurposed to hold eight integer values instead. 🧚 They go in this exact order:

  1. The node number of the destination endpoint ID, or zero if the destination endpoint is the null endpoint.
  2. The service number of the destination endpoint ID, or zero if the destination endpoint is the null endpoint.
  3. The node number of the source endpoint ID, or zero if the source endpoint is the null endpoint.
  4. The service number of the source endpoint ID, or zero if the source endpoint is the null endpoint.
  5. The node number of the report-to endpoint ID, or zero if the report-to endpoint is the null endpoint.
  6. The service number of the report-to endpoint ID, or zero if the report-to endpoint is the null endpoint.
  7. The node number of the current custodian endpoint ID, or zero if the current custodian endpoint is the null endpoint.
  8. The service number of the current custodian endpoint ID, or zero if the current custodian endpoint is the null endpoint.

And then the dictionary just gets dropped entirely from the primary block, and the primary block's dictionary length gets set to zero. 🫶

On the receiving end, the convergence-layer adaptation undoes all of this by reversing the process. 🔥 That way the bundle that reaches the bundle protocol agent has the standard form again, with the dictionary reconstituted. ✨ Iconic.

3. Specification 🌸

CBHE compression is a convergence-layer adaptation, so it's opaque to bundle processing. 🙈 That means it has no impact on how different Bundle Protocol implementations interoperate. It only affects how different convergence-layer adaptation implementations interoperate. Main character energy, but make it layer-specific. 💜

Bundle Protocol convergence-layer adapters that conform to the CBHE specification must implement the following procedures. 🎀

3.1. Transmission 🦋

When and only when the bundle protocol agent asks a CLA to transmit a bundle whose primary block's endpoint IDs satisfy the constraints from Section 2.1, the CLA MAY encode the primary block using the CBHE compression convention from Section 2.2 UNLESS the CLA it's being sent to is known not to be CBHE conformant. 🙅‍♀️ Note that CBHE compression may only be applied if the receiving CLA is known or presumed to be CBHE conformant, meaning it can decode the encoded primary block. 💖 Whether a receiving CLA is (or might be) CBHE conformant can be asserted by node administration, and/or inferred from receiving a CBHE-compressed bundle, as Section 3.2 explains. 🔍

3.2. Reception 🌈

Okay, when a bundle with a dictionary length of zero shows up (and ONLY in this situation 👀), a CBHE-conformant convergence-layer adapter:

  1. MAY infer that the CLA the bundle came from is CBHE conformant.
  2. MUST decode the primary block of the bundle using the CBHE compression convention from Section 2.2 before delivering it to the bundle protocol agent. 🔥
Heads up, this part's a little tea. 💀 If a CLA that is NOT CBHE conformant receives a bundle with dictionary length zero, it has no choice but to pass the bundle to the bundle agent without changing it. Then the bundle protocol agent can't dispatch it, because it can't figure out the destination endpoint, so the bundle gets judged malformed. 😭 How the bundle protocol agent handles that situation is an implementation matter.

4. IANA Considerations 🧚

IANA has registered a provisional registration (per [RFC4395]) for a URI scheme for CBHE, using the string "ipn" as the scheme name. 🎀 Here's the registration:

URI scheme name: "ipn"

Status: provisional

For the URI scheme syntax, this specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], including the core ABNF syntax rule for DIGIT defined by that specification. 🤓 The grammar itself looks like this:

ipn-uri = "ipn:" ipn-hier-part
ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless
node-nbr = 1*DIGIT
nbr-delim = "."
service-nbr = 1*DIGIT

Not a single reserved character from the generic URI syntax gets used as a delimiter inside IPN scheme URIs. 🫶 Super clean.

The semantics are that IPN scheme URIs are used as endpoint identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050], as described in Section 2.1. 🌸 They're encoded exclusively in US-ASCII characters, and that's also the interoperability note. The application and protocol that use this scheme name is the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050]. ✨

Now the security considerations for the registration, which are serious but still giving us a little drama 🎭:

  • Reliability and consistency: none of the BP endpoints identified by IPN scheme URIs are guaranteed to be reachable at any time, and the Bundle Protocol itself never guarantees the identity of the processing entities operating on those endpoints. 😬 Bundle authentication as defined by the Bundle Security Protocol is required for this purpose.
  • Malicious construction: malicious construction of a conformant IPN-scheme URI is limited to picking malicious node numbers and malicious service numbers. 😈 So a maliciously built IPN-scheme URI could direct a bundle to an endpoint that might get damaged by the bundle arriving, or it could declare a false source for a bundle and cause incorrect processing at a node that receives it. In both cases (and honestly in all bundle processing), the node that receives a bundle should verify its authenticity and validity before operating on it in any way. 🛡️
  • Back-end transcoding: the limited expressiveness of IPN scheme URIs basically eliminates the threat from errors in back-end transcoding. 💅
  • Rare IP address formats: not relevant, since IP addresses never show up anywhere in conformant IPN-scheme URIs. 🙃
  • Sensitive information: IPN scheme URIs are only used to represent the identities of Bundle Protocol endpoints, so the risk of disclosing sensitive information through interception of these URIs is minimal. 👀 Still, examining IPN-scheme URIs could support traffic analysis. Where traffic analysis is a plausible danger, bundles should be conveyed by secure convergence-layer protocols that don't expose endpoint IDs. 🔒
  • Semantic attacks: the simplicity of IPN-scheme URI syntax minimizes the chance a human user misinterprets a URI. 🍓

The contact and change controller info is all Scott Burleigh, so here it is exactly as written:

Contact:
   Scott Burleigh
   Jet Propulsion Laboratory,
   California Institute of Technology
   scott.c.burleigh@jpl.nasa.gov
   +1 (800) 393-3353

Author/Change controller:
   Scott Burleigh
   Jet Propulsion Laboratory,
   California Institute of Technology
   scott.c.burleigh@jpl.nasa.gov
   +1 (800) 393-3353

And the reference for this registration is: S. Burleigh, "Compressed Bundle Header Encoding (CBHE)", RFC 6260, May 2011. 🎀

5. Security Considerations 🔥

Okay, this section is the one to read twice, babe. ⚠️ The Bundle Security Protocol (BSP) may, under some conditions, insert extra endpoint ID strings into a bundle's dictionary and reference those strings in BSP extension blocks. Because a bundle that includes any extension blocks with EID-references to endpoint IDs other than the block's destination, source, report-to, and current custodian can't be CBHE compressed, bundles can't be compressed under those conditions. 🚫

Specifically, the specification above means a bundle can't be CBHE compressed when any of these is true:

  • the security-source endpoint for the Bundle Authentication Block (BAB) is noted in the dictionary (typically because there's no other way for the receiving bundle protocol agent to figure out the security-source endpoint);
  • the security-destination endpoint for the BAB is noted in the dictionary (in the rare case that the receiving endpoint isn't the security-destination endpoint);
  • the security-source endpoint for the Payload Integrity Block (PIB), Payload Confidentiality Block (PCB), or Extension Security Block (ESB) isn't the source endpoint; or
  • the security-destination endpoint for the PIB, PCB, or ESB isn't the destination endpoint.

Also, the CBHE-conformance inference mechanism from Section 3.2 opens up a possible denial-of-service attack. 😱 Malicious code could send a CHBE-compressed bundle whose source EID falsely says the bundle came from some node whose CLA isn't CBHE conformant. A CBHE-conformant CLA that receives this bundle might wrongly infer that the CLA at the purported source node is CBHE conformant, and then start CBHE compressing all the bundles it sends to that node. That would stop those bundles from being dispatched by the node's bundle protocol agent. 💀 Nodes can defend against this by requiring Bundle Authentication Blocks and by discarding any inference of CBHE conformance for CLAs at nodes that send inauthentic bundles. 🛡️

These caveats aside, CBHE introduces no new security considerations beyond the ones already discussed in the DTN Bundle Protocol RFC 5050 [RFC5050] and Bundle Security Protocol RFC 6257 [RFC6257] Specifications. 🌈

6. References 📚

6.1. Normative References 💜

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66,
           RFC 3986, January 2005.

[RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
           Specification", RFC 5050, November 2007.

[RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC6257]  Symington, S., Farrell, S., Weiss, H., and P. Lovell,
           "Bundle Security Protocol Specification", RFC 6257,
           May 2011.

6.2. Informative References 🧚

[RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
           Registration Procedures for New URI Schemes", BCP 35,
           RFC 4395, February 2006.

Appendix A. Acknowledgments 🌸

This research was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. Government sponsorship acknowledged. 🚀 Thank you, science teams, you literally made this possible. 🫶

Author's Address ✨

Scott Burleigh
Jet Propulsion Laboratory, California Institute of Technology
4800 Oak Grove Drive, m/s 301-490
Pasadena, CA  91109
USA

Phone: +1 818 393 3353
EMail: Scott.C.Burleigh@jpl.nasa.gov
📦 where this page comes from