RFC 6259

Delay-Tolerant Networking Previous-Hop Insertion Block

📅 published May 2011, from ietf

Part 1 of 3 🎀

okay bestie, let's start at the cover page 🦋 This is RFC 6259, called Delay-Tolerant Networking Previous-Hop Insertion Block. It came from the Internet Research Task Force (IRTF), written by S. Symington at The MITRE Corporation, and it's dated May 2011. The category is Experimental, and the ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so this doc isn't replacing or patching any other RFC 💅

Abstract ✨

okay so this doc defines an extension block for the Delay-Tolerant Networking (DTN) Bundle Protocol 🌸 It's called the Previous-Hop Insertion Block (PHIB), and a forwarding node inserts it to share the endpoint identifier (EID) of an endpoint that the forwarding node belongs to, so the next-hop receiving node can see that EID. Sometimes you need to know the EID of the previous hop to make certain routing protocols work, like flood routing 🧚 If the convergence layer or some other method can't provide that EID, the PHIB gives a way to ship the EID along with the bundle. Each PHIB always gets removed by the receiving node, so it only ever lives for exactly one hop 💜 This doc covers the format and how to process the PHIB. It's a product of the Delay-Tolerant Networking Research Group, and the group reviewed it. No objections to publishing it as an RFC were raised, so it's a whole vibe 🫶

Status of This Memo 🌈

this one is not an Internet Standards Track spec, bestie 🙈 It's published so people can examine it, try it out in experimental implementations, and evaluate it.

It defines an Experimental Protocol for the Internet community, and it's a product of the Internet Research Task Force (IRTF). The IRTF shares results of Internet-related research and development, and those results might not be ready for deployment. This RFC reflects the consensus of the Delay-Tolerant Networking Research Group of the IRTF. Docs approved for publication by the IRSG aren't a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 💅

For info on the current status of this doc, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6259. 🔥

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this doc 🎀

Table of Contents 🍓

1. Introduction ....................................................2
   1.1. Requirements Language ......................................4
2. Previous-Hop Insertion Block Format .............................4
3. Previous-Hop Insertion Block Processing .........................6
   3.1. Bundle Transmission ........................................6
   3.2. Bundle Forwarding ..........................................6
   3.3. Bundle Reception ...........................................7
4. Security Considerations .........................................8
5. IANA Considerations .............................................9
6. References ......................................................9
   6.1. Normative References .......................................9
   6.2. Informative References .....................................9

1. Introduction ✨

okay so this doc defines an extension block for the Bundle Protocol [RFC5050], which lives inside the Delay-Tolerant Networking architecture [RFC4838] 🦋 The DTN Bundle Protocol says the bundle is its protocol data unit, and it uses "bundle blocks" to carry different types of data. This doc defines an optional bundle block called the Previous-Hop Insertion Block (PHIB) 💅

A forwarding node inserts the PHIB into a bundle to share the endpoint identifier (EID) of an endpoint that the forwarding node is a member of, so that this EID can be passed along to the next-hop receiving node. (From here on, an EID of an endpoint that a node is a member of gets called an "M-EID" of that node. A node can have one or more M-EIDs, depending on how many endpoints it belongs to. An EID of a singleton endpoint that a node is a member of gets called a "singleton M-EID" of that node.) If the receiving node needs to figure out the M-EID of a forwarding node, but it can't infer that M-EID through existing mechanisms, then the forwarding node must explicitly provide this M-EID in the bundle 😭 This spec defines how a node can insert an M-EID into a bundle before forwarding it to the next hop 🌸

This previous-hop M-EID info can help with routing protocols in some situations. For example, the PHIB could be really useful for flood routing 🧚 Each receiving node could use the PHIB to figure out which EID to leave off its list of adjacent nodes when it forwards a received bundle, as it does its part in flooding. A node floods the bundle to all of its neighboring nodes except the one it received the bundle from, which the PHIB identifies 💜

The PHIB could also work alongside the Bundle Authentication Block (BAB) of the DTN Bundle Security Protocol [DTNBSP], where it provides the security-source EID for the BAB. The PHIB can carry the BAB's security-source EID instead of passing that EID through a reference in the BAB's EID-reference field, or by including the EID as part of the BAB's key-information parameters 🫶

A lot of the time, a node that receives a bundle can work out the M-EID of the node that forwarded it. Sometimes, though, the receiving node can't infer any M-EID at all. For example, when you tunnel DTN bundles across part of the DTN network, the node at the receiving end of the tunnel can't figure out the M-EID of the node at the sending end from the convergence layer. The receiving end gets an encapsulating bundle from one of its adjacent nodes, and it might be able to identify that adjacent node's M-EID through the convergence-layer protocol. But the node at the sending end of the tunnel probably isn't adjacent to the node at the receiving end, so for the receiving end to learn the M-EID of the sending-end node (the previous-hop node of the tunneled bundle), that M-EID has to be included within the tunneled bundle. In this case, the PHIB is the vehicle that lets the sending-end node give its M-EID to the receiving-end node 🌈

EIDs can be presented in two ways inside the PHIB. If the forwarding node's M-EID is already in the Dictionary field of the bundle's primary bundle block, the PHIB MAY identify this EID using its Block EID-reference count and EID-reference field. Otherwise, the PHIB MUST identify this EID by providing the EID in its block-type-specific data field. Section 3 talks more about these two alternative ways of presenting EIDs in the PHIB 💅

The PHIB's lifetime is always exactly one hop in the DTN. If a bundle with a PHIB arrives, the receiving node is assured that the previous node inserted this PHIB, assuming all nodes are operating correctly. Likewise, the PHIB doesn't stay with the bundle when the bundle is forwarded. If the bundle is forwarded with a PHIB, this PHIB MUST identify an M-EID of the forwarding node 👑

This doc defines the format and processing of the PHIB. The capabilities described here are OPTIONAL for deployment with the Bundle Protocol. Bundle Protocol implementations that claim to support the PHIB MUST be capable of:

  • generating a PHIB and inserting it into a bundle,
  • receiving bundles that contain a PHIB and making the information in this PHIB available for use, e.g., in forwarding decisions, and
  • deleting a PHIB from a bundle

as defined in this 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. Previous-Hop Insertion Block Format ✨

okay so the PHIB is built on the Canonical Bundle Block Format from the Bundle Protocol Specification [RFC5050] 🎀 bestie, that means every field works the same as in all the bundle protocol blocks except the primary bundle block 💅 and SDNV (Self-Delimiting Numeric Value) encoding is also described in that same spec, so go check it out 🧚

Here's the lineup of what the PHIB is made of 🌸

  • Block-type code (one byte) 🍓 The block-type code for the PHIB is 0x05.
  • Block processing control flags (SDNV) 🫶 The following block processing control flag MUST be set:

Discard block if it can't be processed

  • Block EID-reference count and EID-references (optional) 💖 This is a composite field from [RFC5050] with a count of EID-references (as an SDNV), followed by an EID-reference (as a pair of SDNVs).

Whether this field is allowed depends on whether an M-EID of the node inserting the PHIB is already in the Dictionary field of the primary bundle block 👀 For example, that could be when an M-EID of the inserting node is also an M-EID of the bundle's source, current custodian, or report-to endpoint, or when it's the same as some other endpoint in the dictionary that another block in the bundle references 🦋

If an M-EID of the inserting node is already in the dictionary, this field MAY be present in the PHIB 🌈 If it IS present, the EID-reference count MUST be one, meaning the field has exactly one EID-reference, and that reference MUST point to an M-EID of the inserting node 🔥 Its presence MUST be signaled by a set "block contains an EID-reference field" flag in the block processing control flags ✨

If NO M-EID of the inserting node is in the dictionary, this field MUST NOT be present in the PHIB 💀 and the "block contains an EID-reference field" flag MUST be unset in the block processing control flags 🙈

  • Block data length (SDNV) 🌸 If this value is zero, there are no block-type-specific data fields 🧚 In that case, the M-EID of the inserting node must be in the dictionary, and it MUST be referenced in the Block EID-reference count and EID-references field, as described above 🫶
  • Block-type-specific data fields (optional) 💜 These are:
    • Inserting Node's EID Scheme Name 🍓 A null-terminated array of bytes holding the scheme name of an M-EID of the node inserting this PHIB 💅
    • Inserting Node's EID SSP 🌷 A null-terminated array of bytes holding the scheme-specific part (SSP) of an M-EID of the node inserting this PHIB ✨

If the Block EID-reference count and EID-references field is NOT present in the PHIB, the two fields above (EID scheme name and SSP) MUST be present 🎀 If the Block EID-reference count and EID-references field IS present, those two fields MUST NOT be present 🙅‍♀️

Here's what a PHIB looks like, bestie 🦋

PHIB Format:
+----+------------+--------------------------------- -+-------------+
|type|flags (SDNV)|EID-ref count and list (comp) (opt)|length (SDNV)|
+----+------------+-----------------------------------+-------------+
| Inserting Node EID Scheme Name (opt)| Inserting Node EID SSP (opt)|
+-------------------------------------------------------------------+

                             Figure 1

3. Previous-Hop Insertion Block Processing 🌈

okay this part is about the steps a bundle node has to take when it generates, receives, and processes a PHIB 💖

3.1. Bundle Transmission 🚀

When an outbound bundle is created based on the parameters of the bundle transmission request, this bundle MAY include one or more PHIBs 🧚 Whether PHIBs get included is a local bundle agent configuration option, and it might depend on other stuff too, like the routing protocol in use 🌸

3.2. Bundle Forwarding 🦋

Before forwarding a bundle, the node SHALL delete all PHIBs that were in the bundle when it was received (if any) 💅 As the Bundle Protocol Specification explains, the node MAY also delete all strings (scheme names and SSPs) in the bundle's dictionary that no endpoint ID references in the bundle currently refer to (if any) ✨

The node MAY insert one or more PHIBs into the bundle before forwarding it, as local policy dictates 🎀 If there are already strings (scheme names and SSPs) in the bundle's dictionary that denote the M-EID of the inserting node, the PHIB MAY reference those strings, and if it does, it MUST NOT include any block-type-specific data fields 🙈 The inserting node MUST NOT insert strings into the bundle's dictionary just so that only the PHIB can reference them 🚫 If the PHIB doesn't reference any strings from the dictionary, the inserting node MUST include the scheme name and SSP of one of its M-EIDs as the PHIB's block-type-specific data fields 💜

A node inserting a PHIB might be a member of more than one endpoint 👑 The choice of which M-EID to insert into the PIB SHALL be made as follows:

  • If the inserting node is a member of exactly one singleton endpoint, the node MAY insert at most one PHIB into the bundle, and the EID of this singleton endpoint is what MUST be inserted into the PHIB 💖
  • If the inserting node is a member of more than one singleton endpoint, then:

If the inserting node has a priori knowledge of the URI schemes supported by the next-hop node, and it has one or more singleton M-EIDs expressible in one or more of those URI schemes, then the inserting node MAY insert one or more PHIBs into the bundle being forwarded 🌷 The EIDs in the inserted PHIBs MUST be unique, they MUST be singleton M-EIDs of the inserting node, and they MUST be expressed in URI schemes supported by the next-hop node 🫶 Mechanisms for determining which URI schemes particular next-hop neighbors support are not defined here 🤷‍♀️

If the inserting node has one or more singleton M-EIDs expressible in the same URI scheme as the destination of the bundle being forwarded, then the inserting node MAY insert one or more PHIBs into the bundle being forwarded 🦋 The EIDs in the inserted PHIBs MUST be unique, they MUST be singleton M-EIDs of the inserting node, and they MUST be expressed in the destination URI scheme of the bundle 🎀

Else, if the inserting node has neither a singleton M-EID expressible in a URI scheme known to be supported by the next-hop node, nor a singleton M-EID expressible in the same URI scheme as the bundle's destination, then the inserting node MAY insert one or more PHIBs into the bundle being forwarded 🌈 The EIDs in the inserted PHIBs MUST be unique, and they MUST be singleton M-EIDs of the inserting node 💅

3.3. Bundle Reception 🧚

If the bundle includes a PHIB, the EID identified in the PHIB SHALL be made available for use at the receiving node 💖 For example, that's for forwarding decisions, or if the receiving node is the bundle destination, the EID may be made available to the receiving application 🌸 Whether it actually gets handed to the application is an implementation matter 🙈 If the EID is identified BOTH by a reference in the PHIB's block EID-reference count and EID-references field AND by a scheme name and SSP in the block-type-specific fields, the PHIB is NOT considered well-formed 💀 If that happens with a PHIB like this, and the identified EIDs are the same, the receiving node MAY process the PHIB as if it were well-formed 🫶 But if the identified EIDs differ, the receiving node MUST NOT process the PHIB, and it MUST take action on the PHIB as specified by the PHIB's block processing flags 🚨

4. Security Considerations 🔐

okay this one is SERIOUS bestie, so pay attention 😭

The DTN Bundle Security Protocol [DTNBSP] defines security-related blocks that give hop-by-hop bundle authentication and integrity, end-to-end integrity, and end-to-end confidentiality of bundles or parts of bundles 🛡️ It also defines a set of ciphersuites that may be used to calculate the security-results carried in those security blocks 💅

The PHIB will NOT be encrypted when using the PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite with the Payload Confidentiality Block (PCB) for end-to-end confidentiality 🙈 That ciphersuite only allows for payload and Payload Integrity Block (PIB) encryption 💔 If you want the PHIB block encrypted, the Extension Security Block (ESB) could be used for that 🧚

All ciphersuites that use the strict canonicalization algorithm [DTNBSP] to calculate and verify security-results (for example, many hop-by-hop authentication ciphersuites) apply to ALL blocks in the bundle 🌈 So they would apply to bundles that include an optional PHIB, and they would include that block in the calculation of their security-result 🔥 In particular, bundles with the optional PHIB would have their integrity protected in their entirety for a single hop, from a forwarding node to an adjacent receiving node, using the Bundle Authentication Block (BAB) with the BAB-HMAC (Hashed Message Authentication Code) ciphersuite defined in the Bundle Security Protocol Specification 🫶

Ciphersuites that use the mutable canonicalization algorithm to calculate and verify security-results (for example, the PIB-RSA-SHA256 ciphersuite and most end-to-end authentication ciphersuites used with the PIB) will (correctly) OMIT the PHIB from their calculation 🦋 The fact that several different instantiations of this PHIB block may be added to and deleted from the bundle as it transits the network will NOT interfere with end-to-end security protection when using mutable canonicalization ciphersuites 💖

As stated above, the BAB can be used to ensure the integrity of the PHIB ✨ Nodes receiving bundles with PHIBs SHOULD be aware, though, that forwarding nodes inserting PHIBs might lie about the EIDs of endpoints they're members of 👀 Lying like that could be a way to subvert routing strategies that base their routing decisions on the EID information in the PHIB 😈

Note that if a Bundle Protocol implementation doesn't support the PHIB but also doesn't properly implement the "Discard block if it can't be processed" flag, then a PHIB may unexpectedly persist for longer than a single hop 😱

5. IANA Considerations 📋

This specification allocates a codepoint from the "Bundle Block Types" registry defined in [RFC6255] (see Section 2) 🎀

Additional Entry for the Bundle Block Type Codes Registry:
  +-------+----------------------------------------+----------------+
  | Value | Description                            + Reference      |
  +-------+----------------------------------------+----------------+
  |   5   | Previous-Hop Insertion Block           + This document  |
  +-------+----------------------------------------+----------------+

6. References 📚

References list continues in the next part 💕

6.1. Normative References 📚

okay so these are the docs the spec literally can't function without, bestie 💅

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

[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 2011.

6.2. Informative References 🧚

these ones are the extra-helpful reading. the spec is still complete without them, but they give you the backstory, iykyk 🫶

[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.

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

Author's Address 🎀

the lovely person behind this doc, Susan Flynn Symington, from The MITRE Corporation 🦋

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