RFC 6258

Delay-Tolerant Networking Metadata Extension Block

📅 published May 2011, from ietf

RFC 6258: Delay-Tolerant Networking Metadata Extension Block 🎀

Okay bestie, let's get the basics down first 💅. This is an Experimental doc from the Internet Research Task Force (IRTF) 🧚, written by S. Symington of The MITRE Corporation. It's dated May 2011 and has ISSN 2070-1721. The title block doesn't list any RFCs that it obsoletes or updates, so there's nothing to chase down there 🫶.

Abstract

Okay so this doc defines an extension block you can use with the Delay-Tolerant Networking (DTN) Bundle Protocol 📦. It's called the Metadata Extension Block, and it carries extra info that DTN nodes can use to make processing decisions about bundles, like whether to store a bundle or which nodes to forward it to 💖. The metadata inside a metadata block must be formatted according to the metadata type named in the block's metadata type field. One specific type, for carrying URIs as metadata, is defined here, and other types can be defined in separate documents 🌸. This doc is a product of the Delay Tolerant Networking Research Group, and that group reviewed it. No objections to publishing it as an RFC were raised ✨.

Status of This Memo

Not an Internet Standards Track spec, bestie 🙈. This document is published for examination, experimental implementation, and evaluation.

It defines an Experimental Protocol for the Internet community 🔬. It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development activities. These results might not be suitable for deployment 💀. This RFC represents the consensus of the Delay-Tolerant Networking Research Group of the IRTF. Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 📚.

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6258 🦋.

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) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document 🫶.

Table of Contents 📑

   1. Introduction ....................................................2
      1.1. Requirements Language ......................................4
   2. Metadata Block Format ...........................................4
   3. Metadata Block Processing .......................................5
      3.1. Bundle Transmission ........................................6
      3.2. Bundle Forwarding ..........................................6
      3.3. Bundle Reception ...........................................6
   4. Predefined Metadata Types .......................................6
      4.1. URI Metadata Type ..........................................6
      4.2. Private Metadata Types .....................................7
   5. Security Considerations .........................................7
   6. IANA Considerations .............................................8
      6.1. Metadata Type Codes ........................................8
      6.2. Block Type Code for the Metadata Block .....................9
   7. References ......................................................9
      7.1. Normative References .......................................9
      7.2. Informative References .....................................9

1. Introduction ✨

So this extension block is meant to be used with the Bundle Protocol [RFC5050], inside a Delay-Tolerant Networking architecture [RFC4838]. The DTN Bundle Protocol [RFC5050] uses the bundle as its protocol data unit 📦. This doc defines a bundle block called a "metadata block" 💜. It carries extra info that DTN nodes can use to make processing decisions about bundles.

The metadata block is flexible on purpose, so it can support a whole bunch of metadata types and formats 🌈. The only real restriction is that the type and format have to be predefined and registered (if public), so DTN nodes that support that type can parse and process it. Section 4 defines one specific metadata type and talks about other metadata types that might be defined elsewhere 🧚. As mentioned, the metadata in this block is meant to be application-related information. For example, it might be info associated with a bundle's payload. Extra extension blocks could be (and have been) defined for carrying additional network-related information 💅.

The bundle payload can be processed opaquely by DTN nodes, but metadata is meant to give them access to extra info they can use to process the bundle 🔥. Examples include keywords found in the payload, payload provenance information, GPS coordinates (if the payload is a map, for instance), message IDs, and artist, album, and track name (if the payload is a song) 🎶. Even though the metadata is application-related, its purpose is for DTN nodes to make decisions about how to process bundles within the network, like whether a bundle should be stored or which nodes a bundle should be forwarded to 👑. Metadata about a bundle's payload could act as a content-based index of the bundles stored in a DTN cache. So when someone asks for bundles related to a certain subject or to specific GPS coordinates, the metadata of stored bundles can be searched, and every bundle whose metadata matches the search criteria can be retrieved and returned to the requestor 🫶.

This document defines the general format of the metadata block, plus the processing needed to support it 🎀. The actual metadata inserted into a metadata block MUST be formatted according to the metadata type identified in the block's metadata type field. One specific metadata type, for carrying Uniform Resource Identifiers (URIs) [RFC3986] as metadata, is defined in this document 🦋. Other metadata types may be defined in separate documents, along with whatever steps are needed to process records of that type. If other metadata types are defined, they should be registered to ensure global uniqueness (see the IANA Considerations section) 📝.

The capabilities in this document are OPTIONAL for deployment with the Bundle Protocol 🌸. As defined here, Bundle Protocol implementations that claim to support the metadata block MUST be capable of:

  • generating a metadata block and inserting it into a bundle,
  • receiving bundles containing a metadata block and making the information in this metadata block's metadata field available for use, e.g., in bundle storage or forwarding decisions, and
  • deleting a metadata block from a received bundle before forwarding the bundle.

Bundle Protocol implementations that claim to support a specific metadata type must support the metadata block as defined above, and must also be capable of parsing and processing the metadata itself according to the definition of the metadata type in which the metadata is expressed. That metadata type may be the URI metadata type (see the URI metadata type section), or it may be another metadata type defined in a separate document 💖.

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. Metadata Block Format 🧩

The metadata block uses the Canonical Bundle Block Format defined in the Bundle Protocol [RFC5050]. That means it's made up of the following elements, which are defined the same way as in all bundle protocol blocks except the primary bundle block. (Note that Self-Delimiting Numeric Value (SDNV) encoding is described in the Bundle Protocol.) 🤓

  • Block-type code (1 byte): defined as in all bundle protocol blocks except the primary bundle block (as described in the Bundle Protocol). The block-type code for the metadata block is 0x08 🔢.
  • Block processing control flags (SDNV): defined as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol. There are no constraints on the use of the block processing control flags. If a bundle node receives a bundle with a metadata block, and it is capable of supporting the metadata block but it can't parse and process the metadata itself, either because it doesn't support the metadata type being used or because the metadata isn't well-formed according to the metadata type definition, then the bundle node must process the bundle as if it cannot process the metadata block. That means it must operate according to the settings of the block processing control flags, including the "Delete bundle if block can't be processed" flag and the "Discard block if it can't be processed" flag 🚩.
  • Block EID-reference count and EID-references (optional): composite field defined in the Bundle Protocol. It's present if and only if the metadata block references EID elements in the primary block's dictionary. Its presence is indicated by the setting of the "Block contains an EID-reference field" bit of the block processing control flags. If EIDs are referenced in the metadata block, their interpretation is defined by the particular metadata type being used in this metadata block, as indicated in the metadata type field 🗂️.
  • Block data length (SDNV): defined as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol 📏.
  • Block-type-specific data fields, as follows:
    • Metadata Type field (SDNV): indicates which metadata type is used to interpret both the metadata in the metadata field and the EID-references in the optional Block EID-reference count and EID-references field (if present). One metadata type is defined in this document. Other metadata types may be defined in separate documents 🏷️.
    • Metadata field: contains the metadata itself, formatted according to the metadata type specified for this block. One metadata type is defined in Section 4.1. Other metadata types may be defined elsewhere, as discussed in Section 4 💫.

The structure of a metadata block looks like this 👇

   Metadata Block Format:
   +-----+------+--------------------+------+----------+----------|
   |Type |Flags |EID-Reference count |Len   | Metadata | Metadata |
   |     |(SDNV)|  and list (opt)    |(SDNV)|   Type   |          |
   +-----+------+--------------------+------+----------+----------+

                                 Figure 1
Part 1 wraps up here 🧚✨ Part 2 picks up with Section 3, Metadata Block Processing, so stay tuned, bestie 💖

3. Metadata Block Processing ✨

okay so this section is all about what a bundle node is allowed to do with metadata blocks as stuff goes in and out, and honestly it's giving very organized 🎀

3.1. Bundle Transmission 🦋

okay so when an outbound bundle gets created from the parameters of a bundle transmission request, it MAY 💅 (depending on local policy and which metadata type is being used) include one or more metadata blocks defined in this spec. no cap, totally optional vibes.

3.2. Bundle Forwarding 🚀

a node MAY insert one or more metadata blocks into a bundle before forwarding it, and a node MAY delete one or more metadata blocks from a bundle before forwarding it. both of these are dictated by local policy and the metadata type being used. main character energy for the forwarding node 👑

3.3. Bundle Reception 📬

if the bundle has one or more metadata blocks, the metadata information records in those blocks SHALL be made available for use at this node. 🫶 so like, for bundle storage or forwarding decisions, or if the receiving node is the bundle-destination, the records may be handed to the receiving application. this one is a must, bestie, not a maybe 🔥

4. Predefined Metadata Types 🎀

okay so as mentioned in the last section, any number of different metadata types can be defined. they tell you the format of the metadata field, the EID-references in the optional Block EID-reference count and EID-references field (if it's there), and, if needed, how metadata of that type should get processed. literally so much flexibility 🌈

only one metadata type is defined in this document: the URI metadata type (0x01). there's also a range of metadata type values reserved for private use 🧚

4.1. URI Metadata Type 🌸

it's believed that URIs will, in lots of cases, be good enough for encoding metadata, even though URIs may not be the most efficient way to do it. ngl that's an honest take 🙈 because URI encoding is expected to be so useful, metadata type value 0x01 is defined to mean URI. any other metadata type value is used for other metadata types.

the Metadata field for URI metadata (0x01) is an array of bytes made by concatenating one or more null-terminated URIs. unless local policy says otherwise, the specific processing steps that must be done on bundles with URI metadata blocks are expected to be indicated as part of the URI encoding itself. it's envisioned that users might define URI schemes for this purpose 💅

metadata blocks containing URI metadata MUST NOT include a Block EID-reference count and EID-references field. if that field is absent, the "Block contains an EID-reference field" flag in the block processing control flags MUST be set to a value of 0. support for the URI metadata type is OPTIONAL, so you do you 🫶

4.2. Private Metadata Types 🦋

metadata type values 192 through 255 aren't defined in this spec and are free for private and/or experimental use. private metadata types are not required to be registered. every other metadata type value is reserved for future use, and when one gets defined, it SHOULD be registered so it's globally unique (check the IANA Considerations section). local policy decides how private metadata types get handled 💜

5. Security Considerations 🔥

okay this section is SERIOUS, bestie, so buckle up 😭

the DTN Bundle Security Protocol [RFC6257] defines security-related blocks for hop-by-hop authentication, end-to-end authentication, and end-to-end confidentiality of bundles or parts of bundles. it also has an extension security block that gives confidentiality and integrity to extension blocks, plus a set of standard ciphersuites that can calculate the security-results carried in those security blocks.

ciphersuites that use the strict canonicalization algorithm [RFC6257] to calculate and verify security-results (like lots of hop-by-hop authentication ciphersuites) apply to all blocks in the bundle. so they apply to bundles with an optional metadata block too, and that block gets included in the security-result calculation. lowkey this means bundles with the optional metadata block are protected in their entirety for a single hop, from a forwarding node to an adjacent receiving node. they are NOT protected from source to destination over multiple hops. this uses the standard BAB-HMAC (Bundle Authentication Block - Hashed Message Authentication Code) ciphersuite from the Bundle Security Protocol 🔐

ciphersuites that use the mutable canonicalization algorithm (like the mandatory PSH-RSA-SHA256 ciphersuite and most end-to-end authentication ciphersuites) leave the metadata block out of their calculation. so the fact that metadata can change, or that metadata blocks get added or deleted as the bundle moves through the network, won't mess with end-to-end security when you're using mutable canonicalization. iconic 👑

the metadata block will NOT be encrypted by the mandatory CH-RSA-AES-PAYLOAD-PSH end-to-end confidentiality ciphersuite, because that one only does payload and PSH encryption 🙈

if you want the metadata block to have end-to-end confidentiality and authentication separate from whatever is done for the payload or other parts of the bundle, you can use the extension security block to encrypt and authenticate it. a bundle can have multiple metadata extension blocks. sometimes multiple metadata blocks are in one bundle, and each can be encrypted separately from the others and from the payload. that separate encryption would let bundle nodes do content-based searching and routing on the metadata they can decrypt, even if they can't decrypt the payload. genius, honestly 🧚

since forwarding nodes can change metadata, it may eventually be worth supporting auditing changes to metadata at the individual record level. no such capability is provided in this specification as currently written 🥺

6. IANA Considerations 🎀

6.1. Metadata Type Codes 🌈

the metadata block carried in the Metadata Extension Block has a Metadata Type Code field (see Sections 2 and 3). an IANA registry was set up like this:

               Metadata Type Codes Registry

the registration policy for this registry is:

  0-191: Specification Required
  192-255: Private and/or Experimental Use.  No assignment by IANA.

the Value range is unsigned 8-bit integer.

  +---------+---------------------------------+---------------+
  |  Value  | Description                     | Reference     |
  +---------+---------------------------------+---------------+
  |       0 | Reserved                        | This document |
  |       1 | URI                             | This document |
  |   2-191 | Unassigned                      |               |
  | 192-255 | Private and/or experimental use | This document |
  +---------+---------------------------------+---------------+

6.2. Block Type Code for the Metadata Block 💅

this spec allocates a codepoint from the Bundle Block Type Codes registry defined in [RFC6255] (see Section 2 of this document):

  Additional Entry for the Bundle Block Type Codes Registry:
    +-------+----------------------------------------+----------------+
    | Value | Description                            + Reference      |
    +-------+----------------------------------------+----------------+
    |     8 | Metadata Extension Block               + 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, 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.

[RFC6255]  Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle
           Protocol IANA Registries", RFC 6255, May 2010.

7.2. Informative References 🦋

[RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
           R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
           Networking Architecture", RFC 4838, April 2007.

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

Author's Address 💖

   Susan Flynn Symington
   The MITRE Corporation
   7515 Colshire Drive
   McLean, VA  22102
   US

   Phone: +1 (703) 983-7209
   EMail: susan@mitre.org
   URI:   http://mitre.org/
📦 where this page comes from